POV-Ray : Newsgroups : povray.programming : Possible problem in Mac source Server Time
28 Jul 2024 22:19:56 EDT (-0400)
  Possible problem in Mac source (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
From: Thorsten Froehlich
Subject: Re: Possible problem in Mac source
Date: 13 Nov 1999 17:50:22
Message: <382deb2e@news.povray.org>
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

From: Chris Huff
Subject: Re: Possible problem in Mac source
Date: 13 Nov 1999 18:08:40
Message: <382DF023.AB40492E@compuserve.com>
>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

From: Chris Huff
Subject: Re: Possible problem in Mac source
Date: 13 Nov 1999 18:20:01
Message: <382DF2CC.44834D7@compuserve.com>
>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

From: Chris Huff
Subject: Re: Possible problem in Mac source
Date: 13 Nov 1999 18:28:56
Message: <382DF4E3.1A8FC9@compuserve.com>
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

From: Thorsten Froehlich
Subject: Re: Possible problem in Mac source
Date: 13 Nov 1999 23:41:04
Message: <382e3d60@news.povray.org>
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

From: Thorsten Froehlich
Subject: Re: Possible problem in Mac source
Date: 14 Nov 1999 01:20:39
Message: <382e54b7@news.povray.org>
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

From: Chris Huff
Subject: Re: Possible problem in Mac source
Date: 14 Nov 1999 02:04:03
Message: <382E5F8E.5F9884A9@compuserve.com>
>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

From: Jon A  Cruz
Subject: Re: Possible problem in Mac source
Date: 14 Nov 1999 02:24:08
Message: <382E63E2.44D8BD9E@geocities.com>
Thorsten Froehlich wrote:

> 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.
>

NO NONO NONONONONONONNO!!!!!!!!
aaaaaaaaaaaaaahhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!

(sorry, but I sometimes panic at potentially dangerous code)  :-)

Wouldn't it be safer to change it to something like

[taking a wild guess without having the mac sources around]

char povVers[ sizeof(POV_RAY_VERSION) + 1 ];
or
char *povVers = (char *)malloc( sizeof(POV_RAY_VERSION) + 1 );

?

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Possible problem in Mac source
Date: 14 Nov 1999 11:02:29
Message: <382edd15@news.povray.org>
In article <382E63E2.44D8BD9E@geocities.com> , "Jon A. Cruz" 
<jon### [at] geocitiescom> wrote:

> NO NONO NONONONONONONNO!!!!!!!!
> aaaaaaaaaaaaaahhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!
>
> (sorry, but I sometimes panic at potentially dangerous code)  :-)

Yes!!!!!!!

> Wouldn't it be safer to change it to something like
>
> [taking a wild guess without having the mac sources around]
>
> char povVers[ sizeof(POV_RAY_VERSION) + 1 ];
> or
> char *povVers = (char *)malloc( sizeof(POV_RAY_VERSION) + 1 );

Yes, that would have been better a long time ago, but keep two things in
mind:
First, that usually this string is a version number which shouldn't be that
long after all, i.e. "3.1g.r1" is only 10 bytes so 16 is safe for all
official cases.
Second, the Mac 3.1 code will be replaced completely with 3.5, so it makes
no sense to fix something that will never be used again, nor to invest even
a few seconds into it if those can be spend better on 3.5 :-)


      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

From: Thorsten Froehlich
Subject: Re: Possible problem in Mac source
Date: 14 Nov 1999 11:13:06
Message: <382edf92@news.povray.org>
In article <382edd15@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Second, the Mac 3.1 code will be replaced completely with 3.5, so it makes
> no sense to fix something that will never be used again, nor to invest even
> a few seconds into it if those can be spend better on 3.5 :-)

BTW, of course I made sure there won't be a problem in the Mac 3.5, and it
was already fixed in there :-)

pascal OSErr MacPOVRay_GetInfo(StringPtr versionstr, StringPtr
distributionstr)
{
 strncpy((char *)(versionstr + 1), POV_RAY_VERSION, 254);
 versionstr[0] = strlen((char *)(versionstr + 1));

 strncpy((char *)(distributionstr + 1), DISTRIBUTION_MESSAGE_1, 84);
 strncat((char *)(distributionstr + 1), DISTRIBUTION_MESSAGE_2, 84);
 strncat((char *)(distributionstr + 1), DISTRIBUTION_MESSAGE_3, 84);
 distributionstr[0] = strlen((char *)(distributionstr + 1));

 return noErr;
}

(Note that StringPtr points to pascal string buffers, each 256 bytes in
size).


    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

<<< Previous 3 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.