>As stated in a earlier message. This may help get the information you need.
>Just more of a automated approach to compiling these.
Thanks for the script; I'll definitely archive it. Unfortunately, our window
for investigating this problem further is over as this customer is upgrading
their sys
>Also, you should see if
>__svfscanf() calls __srget(). The __svfscanf() call frame may not show up in
>gdb if the compiler re-used the callframe from vsscanf for __svfscanf() as an
>optimization.
I just checked--it does not call __srget()...
___
fr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 26 Mar 2010 10:52, Peter Steele wrote:
Are you absolutely sure the machine you ran gdb on has the exact same libc etc.
as the customer's machine?
I just connected to the customer's box and generated the stack trace directly
on their bo
On Friday 26 March 2010 9:32:46 am Peter Steele wrote:
> >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 th
>Are you absolutely sure the machine you ran gdb on has the exact same libc
>etc. as the customer's machine?
I just connected to the customer's box and generated the stack trace directly
on their box. It looks identical to the one I posted in my original message.
Something's not right here...
Peter Steele writes:
> 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.
Are you absolutely sure the machine you ran gdb on has the exact same
libc etc. as the customer's machine?
DES
--
>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 crash
Peter Steele writes:
> #8 0x0008011ffe8f in malloc () from /lib/libc.so.7
>
> #9 0x00080127374b in memchr () from /lib/libc.so.7
The stack trace is clearly incorrect:
void *
memchr(const void *s, int c, size_t n)
{
if (n != 0) {
const unsigned char *p = s;
8 matches
Mail list logo
