malloc problems in -current malloc_usable_size()

[Mark Atkinson]

Hi,

I updated my kernel/world yesterday and thunderbird 3.0.2 started core
dumping after I completed the upgrade. It continued to do so on
previously good operations after a full re-compile.

I noticed that some jemalloc changes went in and was wondering if anyone
else was noticing SEGV problems in other apps with malloc_usable_size()
or ARENA problems in threaded apps?

0x28eacb14 in malloc_usable_size () from /lib/libc.so.7


(gdb) bt


#0 0x28eacb14 in malloc_usable_size () from /lib/libc.so.7


#1 0x28eadbaa in free () from /lib/libc.so.7


#2 0x2ed9ac22 in gss_release_buffer () from /usr/lib/libgssapi.so.10


#3 0x2ed9a5ea in gss_release_name () from /usr/lib/libgssapi.so.10


#4 0x2ed96ec9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10


#5 0x2ec0aab4 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libauth.so

#6 0x2ec0b5c1 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libauth.so

#7 0x291853ea in nsMsgProtocol::AsyncOpen () from
/usr/local/lib/thunderbird-3.0.2/components/libmail.so

#8 0x29255b30 in nsStopwatch::QueryInterface () from
/usr/local/lib/thunderbird-3.0.2/components/libmail.so

#9 0x29255dc5 in nsStopwatch::QueryInterface () from
/usr/local/lib/thunderbird-3.0.2/components/libmail.so
#10 0x291832ee in nsMsgProtocol::OnDataAvailable () from
/usr/local/lib/thunderbird-3.0.2/components/libmail.so
#11 0x2986ff02 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libnecko.so
#12 0x298700b6 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libnecko.so
#13 0x281f8844 in NS_AsyncCopy () from
/usr/local/lib/thunderbird-3.0.2/libxpcom_core.so
#14 0x28212846 in NS_SetGlobalThreadObserver () from
/usr/local/lib/thunderbird-3.0.2/libxpcom_core.so
#15 0x281d3b7f in NS_ProcessNextEvent_P () from
/usr/local/lib/thunderbird-3.0.2/libxpcom_core.so
#16 0x29a54281 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libwidget_gtk2.so
#17 0x29ba1687 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libtoolkitcomps.so
#18 0x2819967d in XRE_main () from
/usr/local/lib/thunderbird-3.0.2/libxul.so

[John Baldwin]

Post by Mark Atkinson
Hi,
I updated my kernel/world yesterday and thunderbird 3.0.2 started core
dumping after I completed the upgrade. It continued to do so on
previously good operations after a full re-compile.
I noticed that some jemalloc changes went in and was wondering if anyone
else was noticing SEGV problems in other apps with malloc_usable_size()
or ARENA problems in threaded apps?

This may be a bug in gssapi rather than malloc(). Someone else was reporting
segfaults from gss_release_buffer() because it was free()ing a bad pointer
when using gssapi_krb5.

[Mark Atkinson]

Post by John Baldwin

Post by Mark Atkinson
Hi,
I updated my kernel/world yesterday and thunderbird 3.0.2 started core
dumping after I completed the upgrade. It continued to do so on
previously good operations after a full re-compile.
I noticed that some jemalloc changes went in and was wondering if anyone
else was noticing SEGV problems in other apps with malloc_usable_size()
or ARENA problems in threaded apps?

This may be a bug in gssapi rather than malloc(). Someone else was reporting
segfaults from gss_release_buffer() because it was free()ing a bad pointer
when using gssapi_krb5.

Thanks for that tip, I didn't associated that with the LDAP thread until
now. LD_PRELOAD ing a dummy gss_release_buffer() stops the
segfaulting. Curious it only showed up after I updated. I had an Jan
11th kernel/world earlier.

[Mark Atkinson]

Post by Mark Atkinson

Post by John Baldwin

Post by Mark Atkinson
Hi,
I updated my kernel/world yesterday and thunderbird 3.0.2 started core
dumping after I completed the upgrade. It continued to do so on
previously good operations after a full re-compile.
I noticed that some jemalloc changes went in and was wondering if anyone
else was noticing SEGV problems in other apps with malloc_usable_size()
or ARENA problems in threaded apps?

This may be a bug in gssapi rather than malloc(). Someone else was reporting
segfaults from gss_release_buffer() because it was free()ing a bad pointer
when using gssapi_krb5.

Thanks for that tip, I didn't associated that with the LDAP thread until
now. LD_PRELOAD ing a dummy gss_release_buffer() stops the
segfaulting. Curious it only showed up after I updated. I had an Jan
11th kernel/world earlier.

Just a quick note,

I found that using sasl 2 will also avoid the problem

cyrus-sasl-2.1.23 RFC 2222 SASL (Simple Authentication and Security Layer)

LD_PRELOAD=/usr/local/lib/sasl2/libgssapiv2.so.2 thunderbird

[Jason Evans]

Post by Mark Atkinson
I updated my kernel/world yesterday and thunderbird 3.0.2 started core
dumping after I completed the upgrade. It continued to do so on
previously good operations after a full re-compile.
I noticed that some jemalloc changes went in and was wondering if anyone
else was noticing SEGV problems in other apps with malloc_usable_size()
or ARENA problems in threaded apps?
(gdb) bt
#0 0x28eacb14 in malloc_usable_size () from /lib/libc.so.7
#1 0x28eadbaa in free () from /lib/libc.so.7
#2 0x2ed9ac22 in gss_release_buffer () from /usr/lib/libgssapi.so.10

This failure (segfault due to accessing an unmapped region of memory) is
more subtle than I would typically expect of a malloc bug. My approach
to debugging this would be to turn on tracing (see MALLOC_OPTIONS=U
docs) and see if the pointer passed to free() was valid (i.e. returned
by malloc/calloc/realloc, but not yet freed).

Jason