[Freeciv-Dev] Re: autobacktrace (was: concerning the use of assert)

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Fri, Sep 13, 2002 at 12:34:04PM -0500, Jason Short wrote:
> Per I. Mathisen wrote:
> >On Fri, 13 Sep 2002, Reinier Post wrote:
> >
> >>I'm not sure it makes that much of a difference, you can start gdb,
> >>atach it to the pid of a current civserver process, stop it,
> >>print the backtrace, continue, and detach.But I don't really
> >>see what to look for while running, and keeping the debugger attached
> >>all the time may slow the game down too much.I never tried this.
> >
> >
> >We don't need to have it attached all the time. We can freeze the server
> >on an error, launch and attach gdb, print a backtrace to a log, kill gdb
> >and then thaw the server and continue execution. The users will notice a
> >hiccup, but it is much better than a crash.
> 
> Yes.
> 
> >Another option may be to fork() off a clone of the current process, then
> >abort() it so that you generate a core file from that. This should be
> >faster, but I don't know how this will affect our open files and allocated
> >memory.
> 
> For starters, what about the simple function:
> 
>   static void dump_core(void)
>   {
>     pid_t pid = fork();
> 
>     if (pid <= 0 || waitpid(pid, NULL, 0) <= 0)
>       abort();
>   }
> 
> which should work fine for getting core without interrupting the current 
> process.  Fork is pretty nice about not messing with the parent process' 
> resources.
> 
> The extra handling you've been talking about could take place right at 
> the end of this function:
> 
> - Attach gdb to the core file (we must handle the case where gdb doesn't 
> exist, or where cores are disallowed).
> - Get a backtrace, and possibly other information.
> - Save the current game (could be tricky if the save code is not 
> re-entrant).
> - Perhaps get some other data: like the version number, build time, etc.
> - E-mail all the collected data to freeciv-reportbug@xxxxxxxxxxx. 
> (Sending it to freeciv-dev is a bad idea since there could potentially 
> be a *lot* of duplicates and not everyone will want the traffic).  We 
> must handle the case where there is no means to send mail; also do we 
> need to ask the user before doing this?
> 
> Note this would work for both server and client (although the client is 
> less likely to have all of the helper programs present).

Just to confirm that I understand you correctly: you want to replace
the 673 asserts we have now with something which dumps a
core/backtrace (this is easy) AND continue normal afterwards (this is
hard)?

Note that it is also hard to save a game if an assert condition was
triggerd. You just don't know what went wrong. And saving a game
requires some non-small number of functions.

The OS can do the job of preserving the state quite good. This was the
reason why core files were implemented.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "We've all heard that a million monkeys banging on a million typewriters
  will eventually reproduce the entire works of Shakespeare.
  Now, thanks to the Internet, we know this is not true."