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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
