> From: Petar Bogdanovic <[email protected]> > I just noticed the following irregularity since we replaced 1.3.103 with > 1.3.105 on a NetBSD 4.0 machine (no virtualization): > > Jun 4 16:10:14 dccifd: restart after signal 6 > Jun 4 16:10:14 dccifd: 1.3.105 listening to /var/dcc/dccifd (...) > Jun 4 16:10:14 spamd: dcc: dccifd -> check skipped: failed to read header > (...) > ...
> According to kill(1) on NetBSD, signal 6 is ``ABRT (abort)''. What > could that be? It certainly never occured when we used 1.3.103. Signal 6 generally comes from the abort() library function. That ought to be associated with a system log complaint about a major problem. There should also be a core file in the DCC home directory. That core file might be useful with gdb if dccifd has been built with debugging information. To rebuild the DCC software with debugging information, run .../libexec/updatedcc -e DBGFLAGS=-g If the core file is for version of dccifd built with -g, then the following will get the stack trace on NetBSD with the DCC home and libexec directories set to the defaults: % gdb /var/dcc/libexec/dccifd /var/dcc/dccifd.core bt exit } From: MrC <[email protected]> } I had the same experience, and didn't have time to track the issue. I } reverted to dccproc for the time being. I'd be curious about the } situation too. Is that also with NetBSD? Vernon Schryver [email protected] _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
