"Bradley Arsenault" <address@hidden> writes:
> On 8/6/07, Joe Wells <address@hidden> wrote:
>
> Using the source in a .tar.gz file from today, I just saw glob2 die
> with this message:
>
> Fatal signal: Segmentation Fault (SDL Parachute Deployed)
>
> However, there is no core dump file! I checked, not just in what was
> the current directory when I ran glob2, but across the whole disk. I
> also checked that I am not limiting core dump size.
>
> Is glob2 doing chdir to some directory in which it doesn't have write
> privileges? I can't think of anything else that would completely
> prevent core dump files like this.
>
> This is a segmentation fault, there is no core dump file because the program
> has crashed. Core dump files are only when the program still has its own
> control flow, and it only occurs when playing online and the two players
> desynchronize. Plus, the core dump file only contains the same information that
> is saved in the save files, it doesn't have other data structures.
Many of the above statements are simply not true.
• First, core dump files contain complete memory images, which contain
*lots* of information that is not in any save file. The claim that
"it doesn't have other data structures" is simply not true. For
debugging purposes what is most important is that a core dump file
includes the entire stack, including all of the procedure activation
frames. Hence, it is possible to get a nice listing of all active
function calls and their parameters (a "backtrace"). Also, one
immediately knows exactly which machine instruction caused the
crash.
• Second, it is normal and standard behavior for a core dump file to
be generated when a fatal signal is received. SIGSEGV (the
segmentation violation signal) is a fatal signal. (A "segmentation
violation" generally happens when an invalid memory address is
used.) Therefore, when a segmentation violation occurs, a normal
program aborts and leaves a core dump file. It is strange and
unusual not to get a core dump file when a segmentation violation
occurs.
Investigation reveals that there are no core dump files for SIGSEGV
with glob2 because libSDL deliberately traps this signal (and
several others) and exits normally when this signal is raised,
thereby preventing the normal core dump mechanism from working.
To prevent libSDL from disabling the core dump mechanism, it would
be necessary to change the line in ./libgag/src/GraphicContext.cpp
that contains the function call
SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO|SDL_INIT_TIMER)
to instead contain this function call:
SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO|SDL_INIT_TIMER|SDL_INIT_NOPARACHUTE)
> Like we have said a million times, use gdb to debug.
It's a _lot_ easier to use gdb with a core dump file ...
> gdb would be allot more
> usefull than a core dump even if the core dump wrote out exact variable names,
> addresses and values for every variable, it would be practically useless
> because we don't know what code caused the crash.
The above sentence is simply not true. With a core dump file, one
knows *exactly* which code caused the crash.
> Run the game in gdb as in gdb glob2 (like it describes on the various wiki
> pages), at the gdb terminal, type run to play glob2. Wen the crash occurs, use
> bt at the gdb terminal to get the back trace of the program, which is far, far
> more usefull than anything a full memory dump would give us.
The procedure you suggest simply will not work, because there will be
no "crash", because libSDL intercepts the SIGSEGV signal and exits
normally.
--
Joe
*our* core dumps (as in our mechanism for dumping game state) do not work like that, and I've never seen glob2 do a full memory dump, with or without SDL "parachutes". I'm not sure how to do it. I've never seen my own programs make full memory dumps without some internal mechanism, and I know glob2 has no such internal mechanism. If you know of a way, feel free to persue it youself.
Secondly, as the developer who will actually be fixing the bug, *I* get to say what would make it easier for me. And I know from personal experience that gdb costs nothing, you could have used it in less time then writing that email, it gives me a backtrace and if nesseccarry values of variables i need. It will be allot easier than trying to work arround and get an obfuscated memory dump for what is likely a simple error.