Checkin [81632289] on the forum-v2 branch changed a call to exit(1) in 
fossil_panic() to call abort() instead, which causes SIGABRT on POSIX type 
systems, which in turn causes Fossil to dump core if that’s configured on the 
system.  I’m a developer, so core dumps are enabled on my private Fossil 
servers.  (Not on public ones to avoid an easy disk-filling DoS attack.)

I suspect that dumping core is so rarely helpful in most of the 112 cases where 
fossil_panic() is currently called in src/* that attaching a debugger is a 
better plan in those rare cases where something like a backtrace is needed.

I discovered this when running “fossil init” without arguments to get a help 
message.  This makes me wonder how many of those 111 other code paths are going 
to drop cores for insufficient cause.

I think it’s appropriate for a function called “panic” to drop core.  What I’m 
questioning is that Fossil really has 112 cases where dropping core on exit is 
the best plan.  If all of these can’t move to fossil_fatal() calls, then I 
guess we need a third “scream and die” function that splits the difference 
between these two.
fossil-users mailing list

Reply via email to