U++ forum: Welcome to the forum

Re: crush of the program [message #8278 is a reply to message #8276]

Wed, 28 February 2007 01:48

exolon
Messages: 62
Registered: July 2006
Location: 53'21N 6'18W

Member

mr_ped wrote on Tue, 27 February 2007 22:09

- race conditions in multi-threaded apps. (very hard to debug)

Yes... I had a very frustrating bug when working on a cryptography assignment done in U++ last week (btw, I got 90%... surely thanks to the GUI, so thank you U++... DrawingDraw and Timer made things really nice).

I noticed that after adding more and more stuff to my main window (TopWindow subclass), the program would crash on startup before the window was displayed.

It got to the stage where adding another Label to the class's member variables caused the program to crash, but commenting out that Label declaration didn't. Which was quite mysterious - even gdb crashed when I tried to debug the error, so I thought maybe the code was running out of stack and maybe the objects created by U++ were huge or something.

Eventually, I realised that the extra class member initialisations were taking long enough that the TopWindow subclass was preempted before it executed its constructor (!) and one of the member variable objects started running instead, which accessed a shared global variable (ack!) that wasn't initialised yet - I intended to increment this shared variable with a timer callback and use it to coordinate graphics operations.

Anyway... long story long, I'd check shared variables and code that might crash if it runs before other code you expect would normally run first. I found the problem by putting PromptOk() almost everywhere, but it's tougher for you since it makes the problem go away! Have you tried moving that line earlier and later to see if it can at least help pinpoint better (ie: here it crashes, here it doesn't crash)...

Report message to a moderator