Hide Forgot
abrt version: 1.1.17 architecture: x86_64 Attached file: backtrace, 39382 bytes cmdline: claws-mail component: claws-mail Attached file: coredump, 173572096 bytes crash_function: WTF::OSAllocator::reserveAndCommit executable: /usr/bin/claws-mail kernel: 2.6.35.11-83.fc14.x86_64 package: claws-mail-3.7.8-6.fc14 rating: 4 reason: Process /usr/bin/claws-mail was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1299776219 uid: 10625 How to reproduce ----- 1. Jump into IMAP inbox 2. Immediately grab HTML mail (mouse) and drag-n-drop into a different IMAP folder 3. Boom!
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