super difficult C++ crashes


i’m having some weird crashes on startup running XCode (3.1, OSX 10.5, GCC 4.0). they’re to do with using arrays defined within classes. basically, if i declare an array of ints like this:

	int colouroffs_r[8];  
	int colouroffs_g[8];  
	int colouroffs_b[8];  

i get a crash on init with a stack trace that looks like this:

(gdb) bt  
#0  0x95b437d8 in small_malloc_from_free_list ()  
#1  0x95b3b4c6 in szone_malloc ()  
#2  0x95b3b2f8 in malloc_zone_malloc ()  
#3  0x906660ba in _CFPropertyListCreateFromXMLData ()  
#4  0x9066662b in CFPropertyListCreateFromXMLData ()  
#5  0x95d5320e in _NSParseObjectFromASCIIPropertyListOrSerialization ()  
#6  0x95d53096 in +[NSDictionary(NSDictionary) newWithContentsOf:immutable:] ()  
#7  0x906e161f in -[__NSPlaceholderDictionary initWithContentsOfFile:] ()  
#8  0x95d52fd8 in +[NSDictionary(NSDictionary) dictionaryWithContentsOfFile:] ()  
#9  0x90ea2a22 in -[NSInputManager initWithName:host:] ()  
#10 0x909fbb95 in +[NSInputManager initialize] ()  
#11 0x92d0d8b8 in _class_initialize ()  
#12 0x92d0c239 in _class_lookupMethodAndLoadCache ()  
#13 0x92d1c6d6 in objc_msgSend ()  
#14 0x3e011c01 in -[GLUTApplication run] ()  
#15 0x3e023313 in glutMainLoop ()  
#16 0x00018c73 in ofUT::MainLoop () at /code/of0.05/apps/vis/damotron/../../../../of0.05_iphone/libs/openFrameworks/app/ofUTGlut.cpp:257  
#17 0x00003291 in ofRunApp (OFSA=0x83b000) at /code/of0.05/apps/vis/damotron/../../../libs/openFrameworks/app/ofAppRunner.cpp:162  
#18 0x00002709 in main () at /code/of0.05/apps/vis/damotron/src/main.cpp:12  

(there’s a couple of wtfs in there: namely, CFPropertyListCreateFromXMLData ? what XML data? huh?)

the strange thing is that i already have a float[] array that i’m declaring inside the class as well, and that’s not causing any problems…

the workaround is to declare the arrays as pointers, and then call new[] on construction. but this is not always ideal, and besides it’s just plain bugging me that things are broken like this.

so. any thoughts? anyone else noticed this problem?

I’ve had this problem when asking for ALOT of memory off the heap (edit, I mean stack), like

unsigned char megapixels[100000000]

and had to use new - it doesn’t look like a lot in your example, but maybe you have alot of the class that has the allocation?

that’s my first guess -

second guess is a memory problem somewhere else (un-initialized variable, off by one, etc) that this allocation is pushing to the front.

take care!

i forgot to mention - this is all happening on the stack: class testApp declares an array of 48 of my TronSlot object, and each TronSlot is declaring three int blahblah[8] arrays. that should only be 4*3*8*48=4608 bytes of memory, which really oughtn’t be enough to cause a stack overflow.

if it’s possible - can you upload a simple version of the thing that crashes? it would be interesting to take a look… - zach

ps, TronSlot is intriguing :slight_smile:

did some further testing - it seems to be a stack overflow issue after all. if i reduce the amount requested so it’s less than 4096 bytes, there’s no problem any more… perhaps this is running inside an MPTask, which according to this Apple-Technical-Q&A have a stack size of 4k…?

in any case you can get it from here: damotron.tgz. (it is to be a visualiser for the Damotron which is more or less a live-sampling Mellotron built in Pd.)

hopefully this limit only applies during startup, and not during normal running time. still bloody weird.

cool – will take a look - thanks!

that’s very strange, and I’d be interested to understand it more. I definitely haven’t seen problems with such a small size.

take care!!

so turns out this was a stupid bug.

hint: don’t try and call setup() on 96 objects a 48 object array. it’s not clever.