On 8/6/07, Joe Wells <[EMAIL PROTECTED]> wrote: > > "Bradley Arsenault" <[EMAIL PROTECTED]> writes: > > > On 8/6/07, Joe Wells <[EMAIL PROTECTED]> 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. -- Extra cheese comes at a cost. Bradley Arsenault.
_______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
