|
|
|
Home » Community » Coffee corner » crush of the program
|
|
| Re: crush of the program [message #8276 is a reply to message #8274] |
Tue, 27 February 2007 23:09   |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
Yes, it's quite common with larger game projects (maybe even with non-game project, but I have mostly experience with computer games).
The reasons may vary horribly.
- compiler error - very very very unlikely, but I did have seen already some. Search everything else 10 times before you start to search for this one.
- usage of uninitialized/corrupted memory - in debug mode you get all kind of those helpers like 0xCCCCCCCC for allocated memory or 0xFDFDFDFD for deleted one, same allocation addresses, etc... in release you get random garbage and never really knows what to expect. Also allocated memory in debug mode has some guardians space which may catch occasional memory overruns, in release it's much easier to corrupt your memory.
If your bug in code works nicely with for example 0xCC.. value, so you don't notice it, it may go crazy in release with the random values it will hit.
- race conditions in multi-threaded apps. (very hard to debug)
- bad definitions of variables (bad usage of volatile variables)
- and many many more...
Do you have some idea which part of code is crashing?
May you publish it here?
Maybe I will have some idea (and maybe not, those bugs are sometimes extremely difficult to catch, depends on overall quality of code and available resources).
Also if you manage to get stack/memory/code dump of crash, it may be worth to compare it with symbol table to see if it does crash always on the same place, and examine the exact reason of crash.
|
|
|
|
| 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)...
|
|
|
|
|
|
| Re: crush of the program [message #8280 is a reply to message #8276] |
Wed, 28 February 2007 09:25 |
 |
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
| mr_ped wrote on Tue, 27 February 2007 17:09 |
- usage of uninitialized/corrupted memory - in debug mode you get all kind of those helpers like 0xCCCCCCCC for allocated memory or 0xFDFDFDFD for deleted one, same allocation addresses, etc... in release you get random garbage and never really knows what to expect. Also allocated memory in debug mode has some guardians space which may catch occasional memory overruns, in release it's much easier to corrupt your memory.
|
BTW, the most troublesome bug is "read past end of buffer". While there is a huge chance that U++ heap allocator catches writes, reads, especially one byte past end, are impossible to catch. Plus, the chance that you read byte in area that causes exception is very very low. Means it crashes once a week or so.
Once I was dealing with mysterious crashes of one of my application for 6 months, before identifying this.
| Quote: |
Also if you manage to get stack/memory/code dump of crash, it may be worth to compare it with symbol table to see if it does crash always on the same place, and examine the exact reason of crash.
|
In U++/Win32 you can call "InstallCrashDump" at the start of program. This will create the core dump that can be later analyzed in "Crash" utility (you should be able to compile it from uppsrc). So if you have any difficulity analyzing, you can try this. Crash will need "*.crash" dump file and map file of executable.
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: crush of the program [message #8746 is a reply to message #8274] |
Wed, 28 March 2007 21:58 |
exolon
Messages: 62
Registered: July 2006
Location: 53'21N 6'18W
|
Member |
|
|
BTW, a quick note which may be of help to those debugging these kind of problems - on linux, you can use a program called valgrind which will give a report like this:
==18964== Conditional jump or move depends on uninitialised value(s)
==18964== at 0x80947F0: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x8094DEB: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x809C7AC: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x809CCF8: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x809A004: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x809A592: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x8098C19: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x804CD68: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x804CDB6: (within /home/oisin/upp/out/GCC32.Gui.Shared/AnimatedHello)
==18964== by 0x4294EA1: __libc_start_main (in /lib/tls/i686/cmov/libc-2.3.6.so)
(many times, then, after a long while... for me, about 3 minutes (!) program appears, I let it run for a moment and quit)
==18964==
==18964== ERROR SUMMARY: 100 errors from 19 contexts (suppressed: 39 from 1)
==18964== malloc/free: in use at exit: 2,144,858 bytes in 30,435 blocks.
==18964== malloc/free: 492,498 allocs, 462,063 frees, 51,400,138 bytes allocated.
==18964== For counts of detected errors, rerun with: -v
==18964== searching for pointers to 30,435 not-freed blocks.
==18964== checked 2,146,892 bytes.
==18964==
==18964== LEAK SUMMARY:
==18964== definitely lost: 697 bytes in 42 blocks.
==18964== possibly lost: 543,752 bytes in 90 blocks.
==18964== still reachable: 1,600,409 bytes in 30,303 blocks.
==18964== suppressed: 0 bytes in 0 blocks.
==18964== Use --leak-check=full to see details of leaked memory.
It takes a huge amount of time though - for me running on a not too fast Celeron 2ghz or so in Ubuntu linux, loading AnimatedHello normally in Shared libs mode took about 10 seconds...
Apparently gcc has a memory debugging library called mudflap, but it seems to generate a lot of spurious errors in C++.
|
|
|
|
| Re: crush of the program [message #8747 is a reply to message #8746] |
Wed, 28 March 2007 22:08 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
| exolon wrote on Wed, 28 March 2007 15:58 |
BTW, a quick note which may be of help to those debugging these kind of problems - on linux, you can use a program called valgrind which will give a report like this:
|
valkyrie (a GUI client for valgrind) makes that report much more readable especially for people who got used to "purify" from Rational Software.
Regards,
Novo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: crush of the program [message #8775 is a reply to message #8768] |
Thu, 29 March 2007 20:24 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
| luzr wrote on Thu, 29 March 2007 11:49 |
| Novo wrote on Thu, 29 March 2007 10:51 |
By default valgrind runs memcheck (valgrind --tool=memcheck).
cachegrind is a part of valgrind starting from version 3.2 I believe.
|
Not sure what "memcheck" does, just wanted to say U++ has quite strong heap checking in debug mode 
All blocks have safety sentinels (overwrite is reported), free blocks memory is filled with specific pattern and tested for writes when allocating again and leaks are not tolerated (error at the program exit).
Mirek
|
| Quote: |
Memcheck can detect if your program:
* Accesses memory it shouldn't (areas not yet allocated, areas that have been freed, areas past the end of heap blocks, inaccessible areas of the stack).
* Uses uninitialised values in dangerous ways.
* Leaks memory.
* Does bad frees of heap blocks (double frees, mismatched frees).
* Passes overlapping source and destination memory blocks to memcpy() and related functions.
|
That can be done in Debug and Release mode.
I recall somebody's messages about spending dozen of hours looking for a bug. 
With valgrind that can be done in few minutes.
Regards,
Novo
[Updated on: Wed, 04 April 2007 03:11] Report message to a moderator |
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 26 22:07:40 CEST 2025
Total time taken to generate the page: 0.01263 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
