super difficult C++ crashes

advanced
#1

hey,

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  
(gdb)

(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?

#2

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!
zach

#3

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.

#4

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:

#5

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.

#6

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!!
zach

#7

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.