441554 - jemalloc does not handle forking properly and does not clean up its locks

Status: RESOLVED DUPLICATE of bug 460933

(Core :: Memory Allocator, defect)

Description

[Ed Martin]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062201 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062201 Firefox/3.0

if a plugin causes FF3 to fork such as gnash and then the child process uses memory functions it can deadlock the child process (which in this case will deadlock the main FF process because it is write()ing to a pipe connected to the child process). A quick check of the man page for pthread_atfork mentions this problem, basically if one thread calls fork() while another holds a lock the child process will never be able be able to obtain that lock because its waiting on a lock held by a non-existent thread. A quick check of the jemalloc shows that there are no calls to pthread_atfork() in the jemalloc source and without it jemalloc cannot work properly with an application that calls fork()

Reproducible: Always

Steps to Reproduce:
1.Install Gnash
2.Open a Page with flash, if your lucky FF will deadlock (gnash calls fork() and then malloc()s memory, in the main thread gnash writes data to the child process which makes FF wait for the deadlocked process)
Actual Results:  
from the child process:

(gdb) thread apply all bt

Thread 1 (Thread 0x2ae3ccac9370 (LWP 12195)):
#0  0x00002ae3c4b77114 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00002ae3c4b72b74 in _L_lock_1007 () from /lib64/libpthread.so.0
#2  0x00002ae3c4b7299e in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00002ae3c4d8a418 in free () from /usr/lib64/firefox-3.0/libjemalloc.so
#4  0x000000000044eb7b in ?? ()
#5  <signal handler called>
#6  0x00002ae3c4b77114 in __lll_lock_wait () from /lib64/libpthread.so.0
#7  0x00002ae3c4b72b74 in _L_lock_1007 () from /lib64/libpthread.so.0
#8  0x00002ae3c4b7299e in pthread_mutex_lock () from /lib64/libpthread.so.0
#9  0x00002ae3c4d8b624 in arena_malloc () from /usr/lib64/firefox-3.0/libjemalloc.so
#10 0x00002ae3c4d8c203 in malloc () from /usr/lib64/firefox-3.0/libjemalloc.so
#11 0x00002ae3c9db0fbd in operator new () from /usr/lib64/libstdc++.so.6
#12 0x00002aaac550c9f4 in std::vector<std::string, std::allocator<std::string> >::reserve () from /usr/lib64/mozilla/plugins/libgnashplugin.so
#13 0x00002aaac550b544 in nsPluginInstance::startProc () from /usr/lib64/mozilla/plugins/libgnashplugin.so
#14 0x00002aaac550bf43 in nsPluginInstance::NewStream () from /usr/lib64/mozilla/plugins/libgnashplugin.so
#15 0x00002aaac550d39a in NPP_NewStream () from /usr/lib64/mozilla/plugins/libgnashplugin.so
#16 0x00000000006123e9 in ?? ()
#17 0x00000000005fde40 in ?? ()
#18 0x00000000005fec85 in ?? ()
#19 0x00000000004e72c8 in ?? ()
#20 0x00000000004858ab in ?? ()
#21 0x00002ae3c54f772c in ?? () from /usr/lib64/firefox-3.0/libxpcom_core.so
#22 0x00002ae3c550ff35 in ?? () from /usr/lib64/firefox-3.0/libxpcom_core.so
#23 0x00002ae3c54d7809 in NS_ProcessNextEvent_P () from /usr/lib64/firefox-3.0/libxpcom_core.so
#24 0x000000000062e953 in ?? ()
#25 0x0000000000d0f9fe in ?? ()
#26 0x00000000004446f6 in ?? ()
#27 0x000000000043fa83 in ?? ()
#28 0x00002ae3ca4a1164 in __libc_start_main () from /lib64/libc.so.6
#29 0x000000000043f869 in ?? ()
#30 0x00007fffe615a6f8 in ?? ()
#31 0x0000000000000000 in ?? ()
#0  0x00002ae3c4b77114 in __lll_lock_wait () from /lib64/libpthread.so.0

Expected Results:  
Not deadlock

Comment 1

[Ed Martin]

sorry, thats the wrong backtrace (its for bug #441548), the correct one is below (almost the same, but does not require a signal handler to deadlock it)


(gdb) thread apply all bt

Thread 1 (Thread 0x2ae3ccac9370 (LWP 3483)):
#0  0x00002ae3c4b77114 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00002ae3c4b72b74 in _L_lock_1007 () from /lib64/libpthread.so.0
#2  0x00002ae3c4b7299e in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00002ae3c4d8b624 in arena_malloc () from /usr/lib64/firefox-3.0/libjemalloc.so
#4  0x00002ae3c4d8c203 in malloc () from /usr/lib64/firefox-3.0/libjemalloc.so
#5  0x00002ae3c9db0fbd in operator new () from /usr/lib64/libstdc++.so.6
#6  0x00002aaac550c9f4 in std::vector<std::string, std::allocator<std::string> >::reserve () from /usr/lib64/mozilla/plugins/libgnashplugin.so
#7  0x00002aaac550b544 in nsPluginInstance::startProc () from /usr/lib64/mozilla/plugins/libgnashplugin.so
#8  0x00002aaac550bf43 in nsPluginInstance::NewStream () from /usr/lib64/mozilla/plugins/libgnashplugin.so
#9  0x00002aaac550d39a in NPP_NewStream () from /usr/lib64/mozilla/plugins/libgnashplugin.so
#10 0x00000000006123e9 in ?? ()
#11 0x00000000005fde40 in ?? ()
#12 0x00000000005fec85 in ?? ()
#13 0x00000000004e72c8 in ?? ()
#14 0x00000000004ef0a5 in ?? ()
#15 0x00000000004f07db in ?? ()
#16 0x00000000004858ab in ?? ()
#17 0x00002ae3c54f772c in ?? () from /usr/lib64/firefox-3.0/libxpcom_core.so
#18 0x00002ae3c550ff35 in ?? () from /usr/lib64/firefox-3.0/libxpcom_core.so
#19 0x00002ae3c54d7809 in NS_ProcessNextEvent_P () from /usr/lib64/firefox-3.0/libxpcom_core.so
#20 0x000000000062e953 in ?? ()
#21 0x0000000000d0f9fe in ?? ()
#22 0x00000000004446f6 in ?? ()
#23 0x000000000043fa83 in ?? ()
#24 0x00002ae3ca4a1164 in __libc_start_main () from /lib64/libc.so.6
#25 0x000000000043f869 in ?? ()
#26 0x00007fffe615a6f8 in ?? ()
#27 0x0000000000000000 in ?? ()
#0  0x00002ae3c4b77114 in __lll_lock_wait () from /lib64/libpthread.so.0

Comment 2

[Wesley W. Garland]

Does this patch https://bugzilla.mozilla.org/attachment.cgi?id=345107 
from bug 460933 fix this?

Comment 3

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.