Summary: | segfault at 8195d040 ip b547d9a1 sp bfc939a4 error 4 in libjavascriptcoregtk-1.0.so.0.13.2[b5191000+3a9000] | ||
---|---|---|---|
Product: | WebKit | Reporter: | Paul Menzel <paulepanter> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | Major | CC: | berto, bugs-noreply, chrischavez |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Attachments: |
Description
Paul Menzel
2012-08-11 05:56:32 PDT
#684583 is the number of the report assigned to this segmentation fault [1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684583 > Crashing inside TCMalloc typically indicates that there is heap corruption.
Yes. If this is reproducible, the next step would be to make it happen under valgrind.
(In reply to comment #2) > > Crashing inside TCMalloc typically indicates that there is heap corruption. > > Yes. If this is reproducible, the next step would be to make it happen under valgrind. I have not tried to reproduce it yet. 1. Is there a Web page giving the options needed for a good report for WebKit? 2. Can I use Valgrind on the core dump somehow? Created attachment 161214 [details]
Log file from `G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log midori`
Alright, the crash happened again today. *Afterward* I tried to run it under valgrind with the following command.
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log midori
Unfortunately Midori was not usable at all and stayed gray all the time, after loading one Web page. `htop` showed that Valgrind was doing something though. In the end I killed the process and I attach the log file. Here is an excerpt from it regarding `libjavascript…`.
==20806== 48 bytes in 1 blocks are possibly lost in loss record 11,590 of 17,587
==20806== at 0x4828868: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==20806== by 0x528147A: sqlite3MemMalloc (sqlite3.c:15397)
==20806== by 0x525D15D: mallocWithAlarm (sqlite3.c:18971)
==20806== by 0x5265246: sqlite3Malloc (sqlite3.c:19004)
==20806== by 0x52652F6: sqlite3DbMallocRaw (sqlite3.c:19340)
==20806== by 0x5265340: sqlite3DbMallocZero (sqlite3.c:19284)
==20806== by 0x526537F: sqlite3ValueNew (sqlite3.c:60233)
==20806== by 0x527AE0A: sqlite3Error (sqlite3.c:21276)
==20806== by 0x52807A0: createCollation (sqlite3.c:115387)
==20806== by 0x52AE637: openDatabase (sqlite3.c:115850)
==20806== by 0x52AEEE1: sqlite3_open16 (sqlite3.c:116029)
==20806== by 0x5BAD70C: WebCore::SQLiteFileSystem::openDatabase(WTF::String const&, sqlite3**, bool) (in /usr/lib/libwebkitgtk-1.0.so.0.1
3.2)
==20806== by 0x5BABDBC: WebCore::SQLiteDatabase::open(WTF::String const&, bool) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==20806== by 0x5A40033: WebCore::IconDatabase::iconDatabaseSyncThread() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==20806== by 0x5A401EA: WebCore::IconDatabase::iconDatabaseSyncThreadStart(void*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==20806== by 0x6CAEEA1: WTF::threadEntryPoint(void*) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==20806== by 0x6CAF00D: WTF::wtfThreadEntryPoint(void*) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==20806== by 0x70E223D: clone (clone.S:130)
I am guessing from »48 bytes in 1 blocks are possibly lost in loss record 11,590 of 17,587« that something is wrong here. Can you figure out what? Or do I need to provide more information?
Hey, does this still happen with a recent build? (In reply to comment #5) > Hey, does this still happen with a recent build? Ping Created attachment 245292 [details] New log file from `G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log midori` (In reply to comment #5) > Hey, does this still happen with a recent build? I believe so. Here is a new logfile from midori 0.5.9 on debian 8 powerpc. |