Puzzling stack trace

[Peter Steele]

>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.