Bug 683928

Created attachment 483515 [details]
File: backtrace

I wonder whether you could take a few more seconds and differ between relevant details in your "How to reproduce" and irrelevant ones? Also, is it reproducible? Does it needs a specific HTML mail?

The attached backtrace doesn't tell anything about IMAP at all (not even about Claws Mail and only a little bit of libetpan), but is full of WebKit stuff. You also have had the "fancy" plugin loaded, which is a plugin to render HTML mails via WebKit GTK+. Smells much like simply loading and displaying the HTML mail crashes. If you can confirm, perhaps you can attach that mail?

Hi Michael, 

sorry about the vague description. I wasn't really sure what actually happened, since it's not 100% reproducible and (by Murphy's Law) the crash happened just at the time where I had to run out quickly :)

Playing with this a bit more now, I can trigger the crash about 1/10 of the time by jumping into the INBOX folder and clicking the email. Fancy plugin tries to render the HTML and it takes some time. While the email window is still unrendered (empty) I grab the e-mail and drop it into a different IMAP folder on the same account.

One thing I've noticed in situation where claws crashes is that the download/rendering (?) progress bar get stuck in the same position for a while (like if an upstream server was slow to send content) and then the crash. Otherwise if the progress bar sprints from left to right everything is OK and I can move the email from one folder to another. Not sure if this is relevant. 

Anyway, I'm attaching the original email. Let me know if I can add more info to clear things up.

Created attachment 483681 [details]
crasher email

Thank you for the testing. And I still thinks it's a crash in WebKit (webkitgtk), since steps #31 to #0 in the backtrace are within WebKit. The attached HTML mail confirms that remote JavaScript code is involved.

#39 0x00000000004f49e9 in main (argc=1, argv=0x7fff64c9eb88) at main.c:1669
[...]
#34 0x00000031dfc41e33 in g_main_dispatch (context=0x1379620) at gmain.c:2149
[...]
#31 0x000000399c45860a in WebCore::readCallback (source=<value optimized out>, asyncResult=0x5cd38c0, data=0x0) at Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:855
[...]
still in WebKit
[...]
#2  FixedVMPoolAllocator (this=<value optimized out>) at Source/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:281
#1  0x000000399d362213 in reserve (this=<value optimized out>) at Source/JavaScriptCore/wtf/PageReservation.h:101
No locals.
#0  0x000000399d364025 in WTF::OSAllocator::reserveAndCommit (bytes=<value optimized out>, usage=<value optimized out>, writable=<value optimized out>, executable=<value optimized out>) at Source/JavaScriptCore/wtf/OSAllocatorPosix.cpp:85
        protection = <value optimized out>
        result = 0xffffffffffffffff

Can you provide: 

rpm -q webkitgtk

free

output? 

This smells like another case of the wonderfull 648319

Hev Kev, 

rpm -q webkitgtk
webkitgtk-1.3.10-1.fc14.x86_64

(I'm running with the latest & greatest that updates-testing provides on F14 ATM)


$ free
             total       used       free     shared    buffers     cached
Mem:       3987136    3587744     399392          0     326408     934384
-/+ buffers/cache:    2326952    1660184
Swap:            0          0          0


Let me know if you need more info to diagnose this further.

If you do: 

echo 1 > /proc/sys/vm/overcommit_memory

can you no longer get this crash to happen?

Kevin, though the crash is a a bit random, I haven't seen it happen with overcommit_memory set to 1. Setting it back to 0 I'm able to trigger the crash abouth with 1/10 -> 1/15 probability. 

I've added this to sysctl.conf and see in the long run.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

*** Bug 678631 has been marked as a duplicate of this bug. ***

*** Bug 672351 has been marked as a duplicate of this bug. ***

*** Bug 678998 has been marked as a duplicate of this bug. ***

*** Bug 716650 has been marked as a duplicate of this bug. ***

*** Bug 676185 has been marked as a duplicate of this bug. ***

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping