Re: [glob2-devel] new crash: “Segmentation Fault (SDL Parachute Deployed)” (no core dump file!)

[Joe Wells]

"Bradley Arsenault" <address@hidden> writes:

> On 8/6/07, Joe Wells <address@hidden> wrote:
>
>     "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.
>
> *our* core dumps (as in our mechanism for dumping game state)

“core dumps” (http://en.wikipedia.org/wiki/Core_dump) are what are
provided by the operating system when a program dies due to a signal
instead of by invoking the “exit” function.

> 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.

I'm not sure why you say you've never seen it.  I've put a number of
bugs into the bug tracker that include core dump files.

All of the major operating systems (all UNIX variants (including MacOS
X), Windows, etc.) have a core dump facility.  There is no need for
the program to provide such a mechanism, because the operating system
does all the work.

(However, Microsoft Windows makes things difficult.  You have to run
“Autodump Plus” to get “application crash dumps” (Windows does not use
the name “core dump”) automatically when programs crash.  And if you
don't configure things correctly you may get incomplete dumps.)

> 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.

This is simply not true in this case.  gdb would not have been able to
give me a backtrace following the procedure you recommended, for the
simple reason that libSDL intercepts the SIGSEGV signal and then
_EXITS NORMALLY_!  gdb does not give backtraces following a normal
exit.

> It will be
> allot easier than trying to work arround and get an obfuscated memory dump for
> what is likely a simple error.

Why would you think a core dump file would be “obfuscated”?

-- 
Joe