Hello.
I am attempting to compile and run my code on OS X 10.3.9 but
it’s crashing somewhere. At some point, something seems to
overwrite the function parameters on the stack and things go
awry. I have combed through the code and I am 99% certain that
the crash isn’t my fault! Here’s a backtrace:
Hardware watchpoint 2: tex
Old value = (struct txm_texture ) 0xcf40
New value = (struct txm_texture ) 0x378060
0x3100ae94 in saveFP ()
(gdb) bt
#0 0x3100ae94 in saveFP ()
#1 0x310032d4 in IMG_LoadPNG_RW ()
#2 0x000057e4 in load_single_texture (tex=0x378060, ind=3637056) at txm.c:403
#3 0x00005a94 in load_textures () at txm.c:465
#4 0x00005d2c in txm_load () at txm.c:512
#5 0x00003128 in init_gl () at test_txm01.c:39
#6 0x00006248 in SDL_main (argc=1, argv=0xbffffca4) at entry.c:98
#7 0x00003e24 in -[SDLMain applicationDidFinishLaunching:]
(self=0x3780e0, _cmd=0x0, note=0x3e8) at macosx/SDLMain.m:243
#8 0x90a27aec in _nsnote_callback ()
#9 0x901da4a8 in __CFXNotificationPost ()
#10 0x901deeb8 in _CFXNotificationPostNotification ()
#11 0x90a25938 in -[NSNotificationCenter
postNotificationName:object:userInfo:] ()
#12 0x92f93380 in -[NSApplication _postDidFinishNotification] ()
#13 0x92f9326c in -[NSApplication _sendFinishLaunchingNotification] ()
#14 0x92f9349c in -[NSApplication(NSAppleEventHandling)
_handleCoreEvent:withReplyEvent:] ()
#15 0x90a7af70 in -[NSAppleEventManager
dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
#16 0x90a81808 in _NSAppleEventManagerGenericHandler ()
#17 0x9272ba10 in aeDispatchAppleEvent(AEDesc const, AEDesc,
unsigned long, unsigned char*) ()
#18 0x9272e858 in dispatchEventAndSendReply(AEDesc const*, AEDesc*) ()
#19 0x9272bc50 in aeProcessAppleEvent ()
#20 0x92975224 in AEProcessAppleEvent ()
#21 0x92e82484 in _DPSNextEvent ()
#22 0x92e98d2c in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#23 0x92ead0ac in -[NSApplication run] ()
#24 0x00003db4 in CustomApplicationMain (argc=3637472, argv=0) at
macosx/SDLMain.m:221
#25 0x00003fe8 in main (argc=1, argv=0xbffffca4) at macosx/SDLMain.m:315
load_single_texture() is my function. Upon entering the function, the
struct txm_texture *tex is 0xcf40 and then a few lines in (after a call to
IMG_Load), it is overwritten and the program crashes.
I am linking my program with the following command line:
cc -g3 -o test_txm01 test_txm01.o /sw/lib/libSDLmain.a -framework SDL
-framework SDL_image -framework SDL_Mixer -framework Cocoa
-framework OpenGL ${1+"$@"}
I am using libsdl-1.2.8, sdl-image-1.2.3-2 and sdl-mixer-1.2.6-12
(installed via Fink).
Any help would be appreciated.
a1
(gdb) bt
#0 0x3100ae94 in saveFP ()
My guess is you are on a G3 and SDL_image was built with -faltivec.
libpng likes to use setjmp(), which causes GCC to emit code to save the
Altivec registers when built with -faltivec…unfortunately, this means
that G3 systems will crash as soon as they call the function with the
setjmp() in it. I got bit by this right before shipping a game, when I
added some optimizations and tested on a G3 right before kicking it out
the door. -faltivec doesn’t suggest this sort of subtle nasty in the
documentation.
The cheapest solution: don’t build SDL_image with -faltivec, since
there’s probably no Altivec code in it at all, but you have to make sure
there’s no Altivec code that might execute between the setjmp and
longjmp calls.
Getting rid of setjmp is another solution, and libpng has hooks for
this, but this is probably a pain.
Then again, my original premise could be wrong.
–ryan.
I’m actually on a G4.
I’ll give SDL_image a try without -faltivec anyway though!
a1On 2/1/06, Ryan C. Gordon wrote:
(gdb) bt
#0 0x3100ae94 in saveFP ()
My guess is you are on a G3 and SDL_image was built with -faltivec.
libpng likes to use setjmp(), which causes GCC to emit code to save the
Altivec registers when built with -faltivec…unfortunately, this means
that G3 systems will crash as soon as they call the function with the
setjmp() in it. I got bit by this right before shipping a game, when I
added some optimizations and tested on a G3 right before kicking it out
the door. -faltivec doesn’t suggest this sort of subtle nasty in the
documentation.
The cheapest solution: don’t build SDL_image with -faltivec, since
there’s probably no Altivec code in it at all, but you have to make sure
there’s no Altivec code that might execute between the setjmp and
longjmp calls.
Getting rid of setjmp is another solution, and libpng has hooks for
this, but this is probably a pain.
Then again, my original premise could be wrong.
–ryan.
I’m actually on a G4.
I’ll give SDL_image a try without -faltivec anyway though!
a1
Hello. I’ve just got round to recompiling SDL_image from source
but I don’t know how to create a Framework to test. Is it automated
in any way or do I have to do it by hand?
a1
I’m actually on a G4.
I’ll give SDL_image a try without -faltivec anyway though!
a1
Hello. I’ve just got round to recompiling SDL_image from source
but I don’t know how to create a Framework to test. Is it automated
in any way or do I have to do it by hand?
a1
Only the Xcode projects are setup to build frameworks. If you are
using the official SDL_image framework, I don’t think -faltivec was
used.
Since you seem to be crashing on a png, one other possibilty is that
the version of libpng we statically linked to is buggy. I noticed it
was a pretty old version, part of the 1.0.x branch and not the 1.2.x
branch. As part of the hundreds of changes I’m making as part of the
Universal update, updating libpng to a current version was one of
those. If you can wait a little bit longer, I should be passing
everything off to Sam soon so everybody can get their hands on this
stuff.
-Eric
Since you seem to be crashing on a png, one other possibilty is that
the version of libpng we statically linked to is buggy. I noticed it
was a pretty old version, part of the 1.0.x branch and not the 1.2.x
branch. As part of the hundreds of changes I’m making as part of the
Universal update, updating libpng to a current version was one of
those. If you can wait a little bit longer, I should be passing
everything off to Sam soon so everybody can get their hands on this
stuff.
-Eric
Ok, I don’t mind waiting. This is all test code so it’s not as if I have a big
public release due anytime soon!
cheers,
a1