Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

First of all, could we get output of the command

	rpm -q thunderbird

Please also install thunderbird-debuginfo (debuginfo-install is from
yum-utils package).

	debuginfo-install thunderbird

Sometimes (quite rarely these days) this happens to me as well. When this happens to you, could you please run

     gdb --pid=$(/sbin/pidof thunderbird)

That will attach gdb debugger to the running thunderbird running inside of gdb debugger. Run then gdb command

	(gdb) thread apply all backtrace

This produces usually many screens of the text. Copy all of them into a text editor and attach the file to the bug as an uncompressed attachment.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Hi Matej

Please confirm when I should run this command:

gdb --pid=$(/sbin/pidof thunderbird)

Should I run this command as soon as I start thunderbird, or only after I have quit and it exhibits the problem as outlined in this bug report?

Thanks
Chris

Created attachment 369616 [details]
thunderbird-bin backtrace

As requested here is the backtrace. You can see in the terminal I used the pid of thunderbird-bin. Please let me know if this is incorrect or if you need any further debug.

(In reply to comment #2)
> Should I run this command as soon as I start thunderbird, or only after I have
> quit and it exhibits the problem as outlined in this bug report?

When the thunderbird misbehaves ... that's what you've attached as attachment 369616 [details], right? If yes, then it looks interesting.

Passing to developers for further analysis.

Correct, that is what I've attached. Thanks for the attention to this.

Not sure whether this is the same as your case, but my Thunderbird RC2 routinely stalls on quit with this backtrace (in bash???):

Thread 1 (process 3217):
#0  0x0000003f5c4a495e in __libc_waitpid (pid=<value optimized out>, 
    stat_loc=0x7fff74d47fbc, options=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/waitpid.c:32
#1  0x000000000043d986 in waitchld (wpid=<value optimized out>, 
    block=<value optimized out>) at jobs.c:3047
#2  0x000000000043eb9f in wait_for (pid=3221) at jobs.c:2415
#3  0x000000000042f860 in execute_command_internal (command=0x108ebf0, 
    asynchronous=<value optimized out>, pipe_in=-1, 
    pipe_out=<value optimized out>, fds_to_close=<value optimized out>)
    at execute_cmd.c:775
#4  0x0000000000432023 in execute_connection (command=0x108e910, 
    asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x109a880)
    at execute_cmd.c:2184
#5  0x000000000042ef43 in execute_command_internal (command=0x108e910, 
    asynchronous=<value optimized out>, pipe_in=-1, pipe_out=-1, 
    fds_to_close=<value optimized out>) at execute_cmd.c:891
#6  0x000000000042f98e in execute_command (command=0x108e910)
    at execute_cmd.c:373
#7  0x0000000000431fee in execute_connection (command=0x109ad20, 
    asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x109adf0)
    at execute_cmd.c:2182
#8  0x000000000042ef43 in execute_command_internal (command=0x109ad20, 
    asynchronous=<value optimized out>, pipe_in=-1, pipe_out=-1, 
    fds_to_close=<value optimized out>) at execute_cmd.c:891
#9  0x000000000042f385 in execute_command_internal (command=0x109ad50, 
    asynchronous=<value optimized out>, pipe_in=-1, pipe_out=-1, 
    fds_to_close=<value optimized out>) at execute_cmd.c:884
#10 0x0000000000430ac9 in execute_function (var=<value optimized out>, 
    words=<value optimized out>, flags=<value optimized out>, 
    fds_to_close=<value optimized out>, async=<value optimized out>, 
    subshell=<value optimized out>) at execute_cmd.c:4068
#11 0x000000000042e5d1 in execute_builtin_or_function (
    flags=<value optimized out>, fds_to_close=0x109adf0, 
    redirects=<value optimized out>, var=<value optimized out>, builtin=0, 
    words=0x109a760) at execute_cmd.c:4283
#12 execute_simple_command (flags=<value optimized out>, 
    fds_to_close=0x109adf0, redirects=<value optimized out>, 
    var=<value optimized out>, builtin=0, words=0x109a760)
    at execute_cmd.c:3736
#13 0x000000000042efe9 in execute_command_internal (command=0x109b1d0, 
    asynchronous=<value optimized out>, pipe_in=-1, pipe_out=-1, 
    fds_to_close=<value optimized out>) at execute_cmd.c:736
#14 0x000000000042f98e in execute_command (command=0x109b1d0)
    at execute_cmd.c:373
#15 0x000000000042f126 in execute_if_command (if_command=<value optimized out>)
    at execute_cmd.c:3087
#16 execute_command_internal (if_command=<value optimized out>)
    at execute_cmd.c:843
#17 0x000000000042f98e in execute_command (command=0x109b110)
    at execute_cmd.c:373
#18 0x000000000041d2c6 in reader_loop () at eval.c:153
#19 0x000000000041caba in main (argc=3, argv=0x7fff74d48878, 
    env=0x7fff74d48898) at shell.c:751
(gdb)

*** This bug has been marked as a duplicate of bug 538207 ***

Is this *really* a dupe of Bug 538207? 

I don't see how they are connected unless you know something I don't. This is a Thunderbird bug, and quite a specific one, and 538207 is a Firefox bug and related to crashing, not being unable to quit.

(In reply to comment #8)
> Is this *really* a dupe of Bug 538207? 
> 
> I don't see how they are connected unless you know something I don't. This is a
> Thunderbird bug, and quite a specific one, and 538207 is a Firefox bug and
> related to crashing, not being unable to quit.  

I am sorry, my mistake. No we are not on speed (to follow up on your bug 538207 comment 85), but I have like 50+ abrt crashes a day now, so sometimes a mistake happens. Yes, this is very specific.

Thanks Matej :) I had always wondered of the value of the automated abrt crash reports... seems to be a fine way to clog up bugzilla to me.

FWIW this bug still exists. Although I have noticed that *sometimes* thunderbird does now quit gracefully.

(In reply to comment #10)
> Thanks Matej :) I had always wondered of the value of the automated abrt crash
> reports... seems to be a fine way to clog up bugzilla to me.

Actually, I have to defend abrt. I like it a lot ... although it is terrible amount of work to plough through all those duplicates (and abrt developers promise to behave better Very Much Soon™), asking angry reporter to install -debuginfo files by hand and play with firefox -g was not that much either (and we didn't get much backtraces anyway). We have now still growing collection of very real backtraces which our developers can fix.

FWIW this seems to be fixed in Thunderbird 3.0 final as just released to F11. I guess this bug should be closed.

Thank you for letting us know.