I have been trying to compile a Mac version of UVPov, but the compile
crashes immediately on startup. The crash does not occur when I compile
for the POV.PPC-dbg target, but does happen for the POV.PPC target. I
have not tested any others.
Here is some info from a MacsBug StdLog:

PowerPC unmapped memory exception at 0C92D298 p2w_NewWindow+001AC

And a short chunk of the calling chain:
   03AEA488    03AEA480    PPC   0C90F9D0 main+0000C
   03AEA478    03AEA470    PPC   00216570 NewRoutineDescriptor+00030
   03AEA474    03AEA470    68K   FFC3C71E _DateToSeconds+00F06
   03AEA464                PPC   002165E0 NewRoutineDescriptor+000A0
   03AEA448    03AEA440    PPC   0C90FAA4 InitializeApp+00084
   03AEA3F8    03AEA3F0    PPC   0E258278 RegisterAppearanceClient+000C4

   03AEA3E8    03AEA3E0    PPC   0C91FF50 InitMoreAppStuff+00248
   03AEA3C4                68K   001E0ECE 'scod BFAF 0002'+05ACE
   03AEA3A8    03AEA3A0    PPC   0C92CDF0 p2w_Init+00058
   03AEA388    03AEA380    PPC   0C92132C ForceRectOnScreen+00160
   03AEA368    03AEA360    PPC   FFD57168 NewHandle+00028
   03AEA358    03AEA350    PPC   0C92D280 p2w_NewWindow+00194

It is obviously in the p2w_NewWindow() function in the file
Printf2Window.c, I think toward the end. I don't know much about ToolBox
programming, though, and can't narrow it down further. :-(
Since this is in the Mac specific source, I suspect there is a bug there
which only shows up when using the UVPov source for some reason. Maybe
this should go to the Macintosh group?

Also, in order to get it to compile, I had to comment out some lines in
photons.c because I kept getting this error:
    Error   : struct/union/enum/class tag 'byte_xyz' redefined
    photons.c line 2103   struct byte_xyz {
These are the lines I commented out:
/*typedef struct byte_xyz BYTE_XYZ;

struct byte_xyz {
  unsigned char x, y, z;
};*/

I have downloaded and installed the upgrades to the latest version of
CodeWarrior and the Universal Interfaces.

Post a reply to this message

In article <382DD8EA.259EDEF8@compuserve.com> , Chris Huff 
<Chr### [at] compuservecom>  wrote:

> It is obviously in the p2w_NewWindow() function in the file
> Printf2Window.c, I think toward the end. I don't know much about ToolBox
> programming, though, and can't narrow it down further. :-(
> Since this is in the Mac specific source, I suspect there is a bug there
> which only shows up when using the UVPov source for some reason.

Well, this code has been in there for eigth years now and gets called every
time, and it looks OK but might have problems when it runs out of memory.
Also, if your heap gets corrupted, a program gets unpredictable, which
explains why you can't find the porblem in debug mode.


First you should check if

p2wWPtr = (p2w_WindowPtr_t)NewPtr(sizeof(p2w_WindowRecord_t));

in p2w_NewWindow returns a valid pointer. Also make sure your heap is still
intact.


You can check if the heap is still intact if you type "hc" as soon as you
drop into MacsBug.


>    Error   : struct/union/enum/class tag 'byte_xyz' redefined
>    photons.c line 2103   struct byte_xyz {
>These are the lines I commented out:
>/*typedef struct byte_xyz BYTE_XYZ;
>
>struct byte_xyz {
>  unsigned char x, y, z;
>};*/

The error message says it all, just search all the other include files to
see where it is defined.

>Maybe this should go to the Macintosh group?

I think this group is just fine.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

>First you should check if

p2wWPtr = (p2w_WindowPtr_t)NewPtr(sizeof(p2w_WindowRecord_t));

in p2w_NewWindow returns a valid pointer. Also make sure your heap is
still intact.<

Are you talking about checking for NULL pointers, or about something
with MacsBug? I only know a very small portion of the MacsBug features.


>You can check if the heap is still intact if you type "hc" as soon as
you drop into MacsBug.<

I did that, the heap is ok. I even did "hc all", everything is ok.


>The error message says it all, just search all the other include files
to see where it is defined.<

Not even any need to do that, there is a comment right above them
explaining that they are from the radiosity files. :-)
I only mentioned that part to warn others of the potential problem.

Thanks for the response.

Post a reply to this message

In article <382DE8C7.CE208C4D@compuserve.com> , Chris Huff 
<Chr### [at] compuservecom>  wrote:

>Are you talking about checking for NULL pointers, or about something
>with MacsBug? I only know a very small portion of the MacsBug features.

No, do something like:

if(p2wWPtr == NULL)
{
    SysBeep(5);
    SysBeep(5);
    SysBeep(5);
}

(Note that it might not beep with only one beep or you might hear the beep
only after you left MacsBug.)

>>The error message says it all, just search all the other include files
> to see where it is defined.<
>
> Not even any need to do that, there is a comment right above them
> explaining that they are from the radiosity files. :-)

No, not that one!  Of course you need to find the first definition ... that
is why it says "redefined"!  Also make sure the new include files in UVPOV
are properly protected from being included twice by using a preprocessor
flag.


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

>No, do something like:

if(p2wWPtr == NULL)
{
    SysBeep(5);
    SysBeep(5);
    SysBeep(5);
}

(Note that it might not beep with only one beep or you might hear the
beep only after you left MacsBug.)<

Ok, I will try that.


>No, not that one!  Of course you need to find the first definition ...
that is why it says "redefined"!  Also make sure the new include files
in UVPOV are properly protected from being included twice by using a
preprocessor flag.<

Ok, I misunderstood what you meant: The second one, which causes the
"redefined" error, is the one I commented out, not the original. I
thought you wanted to know where the originals were for some reason.
Shesh, I only intended this as a warning to others to watch out for
this! I had solved the problem, I know what is happening and how to fix
it, I wanted to make sure everyone else does. :-)

Post a reply to this message

>if(p2wWPtr == NULL)
{
    SysBeep(5);
    SysBeep(5);
    SysBeep(5);
}<

Ok, I added this code in right after this line:
p2wWPtr = (p2w_WindowPtr_t)NewPtr(sizeof(p2w_WindowRecord_t));
The result: No beep, neither before crashing into MacsBug nor after
using ES to get out. I even increased it to 6 calls of SysBeep, just in
case.

Post a reply to this message

More data: The call to the function SetWTitle(aWindow, windTitle) around
line 439 is causing the crash, the crash does not occur if this call is
commented out. If I call SysBeep before it, the beep is heard, if it is
after it the beep is not heard.
Perhaps a problem between the code and the resources?
Here is the code in that area:

 if (!*anError)
 {
  // now its OK to call CloseWindow later..
  p2wWPtr->p2wOpenedOK = true;

  SetPort(aWindow);

  /* Set its title to what the user passed in, if non-null */
  /* Do this only if getting from resources - already done (above)
otherwise */
  if (windID > 0)
   if (windTitle)       // not a NULL pointer?
    if (*windTitle)      // not an empty string?
     SetWTitle(aWindow, windTitle); // then do it!

Post a reply to this message

In article <382### [at] compuservecom> , Chris Huff 
<Chr### [at] compuservecom>  wrote:

> More data: The call to the function SetWTitle(aWindow, windTitle) around
> line 439 is causing the crash, the crash does not occur if this call is
> commented out. If I call SysBeep before it, the beep is heard, if it is
> after it the beep is not heard.

As you know SetWTitle is a system function ... your heap is definetly
corrupted somewhere long before the crash. Did you try to use heap
scrambling (MacsBug "hs" command)?


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <382DD8EA.259EDEF8@compuserve.com> , Chris Huff 
<Chr### [at] compuservecom>  wrote:

> I have been trying to compile a Mac version of UVPov, but the compile
> crashes immediately on startup. The crash does not occur when I compile
> for the POV.PPC-dbg target, but does happen for the POV.PPC target. I
> have not tested any others.

The problem is the too long version string macro POV_RAY_VERSION which is
copied into just 16 bytes of memory in function CreateSplashScreen in
SplashScreen.c. Just change the size of povVers to 32.

BTW, you can get the same crash in debug mode: Just make sure both,
"POV.PPC" and "POV.PPC-dbg", use the same compiler settings. To do so make
sure the settings in the "PPC Processor" and "Global Optimisations" tabs in
the target settings are the same.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

>The problem is the too long version string macro POV_RAY_VERSION which
is copied into just 16 bytes of memory in function CreateSplashScreen in
SplashScreen.c. Just change the size of povVers to 32.<

Ah, it works now! Thanks for the help. :-)

Post a reply to this message