Fri Mar 18 16:41:27 UTC 2005
Vernon Schryver wrote: >>From: Vincent Schonau > > >>The following appears in my webserver error-log: >> >>sh: line 1: 3817 Segmentation fault /var/dcc/libexec/dccsight -QG >>"89d70f46 05f383e6 dfa0738e 3877f7d9" [ ...] > That looks like something odd with logging. > > System call traces are rarely very useful for finding such problems. > Stack traces have far more information, even when the application > was not built with -g. Is there a core file? If so, > what does the "bt" command given to `gdb /var/dcc/libexec/dccsight corefile` > say about the stack trace? > > To build the DCC with line number information and so make the stack traces > really useful, try `/var/dcc/libexec/updatedcc -eDBGFLAGS=-g` There wasn't a corefile, as Linux refuses to dump core when the setuid program is run by a normal user (apparently; I've not looked into this deeper) The below was generated from a corefile that created by running a similar dccsight invocation but by root. Core was generated by `/var/dcc/libexec/dccsight -QG 14603910 533bc8c7 7e075830 b3bffb0e'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 0x00701940 in rawmemchr () from /lib/tls/libc.so.6 (gdb) bt #0 0x00701940 in rawmemchr () from /lib/tls/libc.so.6 #1 0x006f6c85 in _IO_str_init_static_internal () from /lib/tls/libc.so.6 #2 0x006ebedd in vsscanf () from /lib/tls/libc.so.6 #3 0x006e72bb in sscanf () from /lib/tls/libc.so.6 #4 0x0804a0e0 in do_grey () at dccsight.c:259 #5 0x08049d60 in main (argc=0, argv=0xbfeed6c0) at dccsight.c:165 Thanks, Vince.
More information about the DCC