>Type "frame 9" and see what it says. If the bug is easily reproducable, try
>reproducing it with a debugging version of libc (buildworld with
>DEBUG_FLAGS=-g)
This crash happened at a production customer site--we have the core and the
matching binary and our logs for the application that crashed but that's all.
We've never seen this particular crash before and cannot reproduce it. The
fscanf() call that failed is repeated on a continual basis as part of a
monitoring thread, so literally thousands of this exact same call have been
made without incident.
The "frame 9" command doesn't show anything useful:
(gdb) frame 9
#9 0x000000080127374b in memchr () from /lib/libc.so.7
That's it. And yes, the stack trace appears to be wrong. Even the trace
starting from the vsscanf call is wrong. It says that __srget() is the next
function in the stack but vsscanf() doesn't call __srget():
int
vsscanf(const char * __restrict str, const char * __restrict fmt,
__va_list ap)
{
FILE f;
f._file = -1;
f._flags = __SRD;
f._bf._base = f._p = (unsigned char *)str;
f._bf._size = f._r = strlen(str);
f._read = eofread;
f._ub._base = NULL;
f._lb._base = NULL;
f._orientation = 0;
memset(&f._mbstate, 0, sizeof(mbstate_t));
return (__svfscanf(&f, fmt, ap));
}
So it seems our application went completely out to lunch. This is concerning.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
