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 0x00000008011d438c in thr_kill () from /lib/libc.so.7 #1 0x00000008012722bb in abort () from /lib/libc.so.7 #2 0x00000008011fb70c in malloc_usable_size () from /lib/libc.so.7 #3 0x00000008011fbb95 in malloc_usable_size () from /lib/libc.so.7 #4 0x00000008011fdaea in _malloc_thread_cleanup () from /lib/libc.so.7 #5 0x00000008011fdc86 in _malloc_thread_cleanup () from /lib/libc.so.7 #6 0x00000008011fc8e9 in malloc_usable_size () from /lib/libc.so.7 #7 0x00000008011fccc7 in malloc_usable_size () from /lib/libc.so.7 #8 0x00000008011ffe8f in malloc () from /lib/libc.so.7 #9 0x000000080127374b in memchr () from /lib/libc.so.7 #10 0x000000080125e6e9 in __srget () from /lib/libc.so.7 #11 0x00000008012352dd in vsscanf () from /lib/libc.so.7 #12 0x0000000801220087 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"
