Re: Very suspicious stack trace
Peter Steele pste...@maxiscale.com wrote: what would lead malloc() into calling abort()? Everything seems to be in order. Something may have trashed its internal data structures. I'd suggest a close look for things like buffer overflows. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Very suspicious stack trace
I've moved this to freebsd-hackers... -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Peter Steele Sent: Thursday, March 25, 2010 9:54 PM To: freebsd-questions@freebsd.org Subject: Very suspicious stack trace We had an app crash and the resulting core dump produced a very suspicious/confusing stack trace: #0 0x0008011d438c in thr_kill () from /lib/libc.so.7 #1 0x0008012722bb in abort () from /lib/libc.so.7 #2 0x0008011fb70c in malloc_usable_size () from /lib/libc.so.7 #3 0x0008011fbb95 in malloc_usable_size () from /lib/libc.so.7 #4 0x0008011fdaea in _malloc_thread_cleanup () from /lib/libc.so.7 #5 0x0008011fdc86 in _malloc_thread_cleanup () from /lib/libc.so.7 #6 0x0008011fc8e9 in malloc_usable_size () from /lib/libc.so.7 #7 0x0008011fccc7 in malloc_usable_size () from /lib/libc.so.7 #8 0x0008011ffe8f in malloc () from /lib/libc.so.7 #9 0x00080127374b in memchr () from /lib/libc.so.7 #10 0x00080125e6e9 in __srget () from /lib/libc.so.7 #11 0x0008012352dd in vsscanf () from /lib/libc.so.7 #12 0x000801220087 in fscanf () from /lib/libc.so.7 This trace resulted from a call to fscanf, as follows: char sensor[21]; fscanf(in, %20s, sensor); We've verified that the data being read was correct, and clearly the buffer in which fscanf is storing the string it reads is valid (i.e., it's not NULL). So what would lead malloc() into calling abort()? Everything seems to be in order. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Very suspicious stack trace
We had an app crash and the resulting core dump produced a very suspicious/confusing stack trace: #0 0x0008011d438c in thr_kill () from /lib/libc.so.7 #1 0x0008012722bb in abort () from /lib/libc.so.7 #2 0x0008011fb70c in malloc_usable_size () from /lib/libc.so.7 #3 0x0008011fbb95 in malloc_usable_size () from /lib/libc.so.7 #4 0x0008011fdaea in _malloc_thread_cleanup () from /lib/libc.so.7 #5 0x0008011fdc86 in _malloc_thread_cleanup () from /lib/libc.so.7 #6 0x0008011fc8e9 in malloc_usable_size () from /lib/libc.so.7 #7 0x0008011fccc7 in malloc_usable_size () from /lib/libc.so.7 #8 0x0008011ffe8f in malloc () from /lib/libc.so.7 #9 0x00080127374b in memchr () from /lib/libc.so.7 #10 0x00080125e6e9 in __srget () from /lib/libc.so.7 #11 0x0008012352dd in vsscanf () from /lib/libc.so.7 #12 0x000801220087 in fscanf () from /lib/libc.so.7 This trace resulted from a call to fscanf, as follows: char sensor[21]; fscanf(in, %20s, sensor); We've verified that the data being read was correct, and clearly the buffer in which fscanf is storing the string it reads is valid (i.e., it's not NULL). So what would lead malloc() into calling abort()? Everything seems to be in order. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
