Bug#401995: iceape: hangs on modal dialogs and message boxes

[Wladimir Mutel]

On Thu, Dec 07, 2006 at 10:16:11PM +0100, Mike Hommey wrote:

> > 	I have upgraded from Mozilla 1.7.13-0.3 to iceape 1.0.6.
> > 	I run iceape with the profile left from earlier mozilla.
> > 	And so, when I leave the running browser unattended for several
> > 	hours (for a night, say), and if during that time it shows some
> > 	dialog or message box (like, enter mail server password, or,
> > 	expired certificate, or, domain mismatch in certificate), then
> > 	when I come back to the browser (in the morning), I find it
> > 	hung. I.e. I could not close any dialogs or windows, and they do
> > 	not redraw themselves. I am able to kill the browser by HUP
> > 	signal. I did not try to debug the running process, but this is
> > 	reproducible pretty often. Every night, I'd say. This behaviour
> > 	was not seen with Mozilla 1.7. Hope you'd be able to reproduce
> > 	it. I will provide any debugging information on your request.

> It'd be more helpful with a back trace ;)

	Once I attached to the running iceape-bin by gdb. It behaved very
	stably. Except for a few SIGPIPEs on network send() somewhere
	in SSL innards, which broke into gdb, but then I continued the
	execution, and all worked well.

	After several days, everything was impeccable, but today in the
	morning my system restarted due to mains power loss. After reboot,
	I started iceape again, but forgot to attach gdb to it. And so,
	now, in the evening, I have found iceape hung again. In hurry, I
	attached gdb to it, but it said it failed to read a valid object
	file image from memory, and was not very informative overall :

(gdb) thread apply all bt

Thread 14 (Thread -1225348176 (LWP 6410)):
#0  0xb7f87410 in ?? ()
#1  0xb6f69ce8 in ?? ()
#2  0x00000001 in ?? ()
#3  0x00000000 in ?? ()

Thread 13 (Thread -1257047120 (LWP 6414)):
#0  0xb7f87410 in ?? ()
#1  0xb512f3e8 in ?? ()
#2  0x0000c40d in ?? ()
#3  0x00000000 in ?? ()

Thread 12 (Thread -1265751120 (LWP 6976)):
#0  0xb7f87410 in ?? ()
#1  0xb48e1f68 in ?? ()
#2  0x000000a9 in ?? ()
#3  0x00000000 in ?? ()

Thread 11 (Thread -1248654416 (LWP 7174)):
#0  0xb7f87410 in ?? ()
#1  0xb593036c in ?? ()
#2  0x000113b3 in ?? ()
#3  0x00000000 in ?? ()

Thread 10 (Thread -1282536528 (LWP 8080)):
#0  0xb7f87410 in ?? ()
#1  0xb38e036c in ?? ()
#2  0x0001092f in ?? ()
#3  0x00000000 in ?? ()

Thread 9 (Thread -1356145744 (LWP 8085)):
#0  0xb7f87410 in ?? ()
#1  0xaf2ad36c in ?? ()
#2  0x0001091d in ?? ()
#3  0x00000000 in ?? ()

Thread 8 (Thread -1295230032 (LWP 8197)):
#0  0xb7f87410 in ?? ()
#1  0xb2cc536c in ?? ()
#2  0x000104ff in ?? ()
#3  0x00000000 in ?? ()

Thread 7 (Thread -1347753040 (LWP 8200)):
#0  0xb7f87410 in ?? ()
#1  0xafaae36c in ?? ()
#2  0x00010439 in ?? ()
#3  0x00000000 in ?? ()

Thread 6 (Thread -1322542160 (LWP 8202)):
#0  0xb7f87410 in ?? ()
#1  0xb12b936c in ?? ()
#2  0x0001042f in ?? ()
#3  0x00000000 in ?? ()

Thread 5 (Thread -1364538448 (LWP 8228)):
#0  0xb7f87410 in ?? ()
#1  0xaeaac36c in ?? ()
#2  0x0000fdb3 in ?? ()
#3  0x00000000 in ?? ()

Thread 4 (Thread -1339360336 (LWP 8229)):
#0  0xb7f87410 in ?? ()
#1  0xb02af36c in ?? ()
#2  0x0000fdb3 in ?? ()
#3  0x00000000 in ?? ()

Thread 3 (Thread -1372931152 (LWP 8235)):
#0  0xb7f87410 in ?? ()
#1  0xae2ab058 in ?? ()
#2  0x00000001 in ?? ()
#3  0x00000000 in ?? ()

Thread 2 (Thread -1381323856 (LWP 8236)):
#0  0xb7f87410 in ?? ()
#1  0xadaaa058 in ?? ()
#2  0x00000001 in ?? ()
#3  0x00000000 in ?? ()

Thread 1 (Thread -1220286784 (LWP 6404)):
#0  0xb7f87410 in ?? ()
#1  0xbff2a63c in ?? ()
#2  0x00000011 in ?? ()
#3  0x00000000 in ?? ()
(gdb)


	strace -p 6404 showed that the process is blocked on futex
	syscall :

futex(0x9c85a88, FUTEX_WAIT, 17, NULL ...

	Don't know what to do with these data next.

	It seems iceape behaves dependently on whether it is ptraced or
	not. Now I am restarting iceape and attaching gdb ot it in
	advance, before it hangs, and let's see what will happen next.

	Btw, there is program trafshow in package netdiag that hangs on
	futex() as well. It seems to have something related to DNS
	queries, but I did not explore the problem in depth.