Firefox/Thunderbird and SSL not working with libthread_xu
jgordeev at dir.bg
Sat Apr 12 10:30:53 PDT 2008
Matthew Dillon wrote:
:Simon "corecode" Schubert reported XXX some months ago an issue with
:Firefox/Thunderbird and SSL when using libthread_xu as the threading
:I started looking into the issue and found something that seems like a
:bug to me.
:I traced an execution of firefox with ktrace and observed something
:strange. Below is a commented extract from the 'kdump -T' output.
:// thread #4 calls umtx_sleep on 0x2a92f664
:// thread #4 never returns from this syscall, according to the kdump output
:75875:4 firefox-bin 1207996217.713757 CALL umtx_sleep(0x2a92f664,0,0)
:// thread #1 attempts to wake up thread #4
:75875:1 firefox-bin 1207996244.646643 CALL
:// I terminate the process
:75875:5 firefox-bin 1207996413.782573 PSIG SIGQUIT SIG_DFL
:The expected behaviour is for thread #4 to wake up when thread #1 calls
:I'd appreciate any feedback on the issue.
:If you need information about my environment, I'd be happy to provide it.
Could you paste all the ofktrace output between those two points? It
definitely should have woken up thread 4.
<dillon at backplane.com>
There are about 2 million lines of kdump output between these two
points, which include the output of some debugging printfs and likely
information read from/written to my personal profile. The only mentions
of 0x2a92f664 in the kdump output are the lines pasted above. And, as I
said, no return from umtx_sleep for thread 4 is noticed by ktrace.
Before I terminated the process I ran 'ps -axHl' which resulted in the
following line, among others:
UID PID TID PPID CPU PRI NI VSZ RSS WCHAN STAT TT
1001 75875 4 74331 79 200 0 54880 43764 umtxsl IL+ p6
Notice the 'I' in 'IL+'.
The issue is very easy to reproduce - just run 'ktrace -i firefox' and
try to open an SSL site. If opening the site fails, then close the
window, wait for some time, then terminate the process. If opening the
SSL site succeeds, just try again.
I've reproduced the issue with thunderbird too, where the thread than
never woke up happened to be thread #5. I'm running DragonFly 1.12.1
with UP kernel.
I ask anybody who doesn't trust my results to try and reproduce the issue.
More information about the Bugs