Summary: | [EFL] EWebLauncher comes to crash | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Gyuyoung Kim <gyuyoung.kim> | ||||||||
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | barbieri, joone, lucas.de.marchi, tonikitoo | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | PC | ||||||||||
OS: | Linux | ||||||||||
Attachments: |
|
Description
Gyuyoung Kim
2010-06-18 04:24:22 PDT
What revision are you using? I remember this was occurring a long time ago with -O3 and when NDEBUG was defined (the default in Release mode). I'm not sure which revision fixed this, but it's working on latest revision. Valgrind/memcheck logs would help much more than gdb backtraces. If you can provide those, it will help a lot! :-) There is still crash on latest EFLWebkit. If I can get the memcheck by valgrind, I will report it to here. Created attachment 59239 [details]
Memcheck log
I am not sure if this log is you want or not. Anyway, it seems changes regarding HTML5 influence on this crash.
==24760==
==24760== Process terminating with default action of signal 11 (SIGSEGV)
==24760== Access not within mapped region at address 0x8
==24760== at 0x43DD450: WebCore::inlineTagList() (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x43DE045: WebCore::HTMLElement::inEitherTagList(WebCore::Node const*) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x43DB4EE: WebCore::HTMLElement::childAllowed(WebCore::Node*) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x4AAF9A8: WebCore::ContainerNode::addChild(WTF::PassRefPtr<WebCore::Node>) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x4408087: WebCore::LegacyHTMLTreeConstructor::insertNode(WebCore::Node*, bool) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x44089A5: WebCore::LegacyHTMLTreeConstructor::parseToken(WebCore::Token*) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x4DA41A0: WebCore::HTML5TreeBuilder::passTokenToLegacyParser(WebCore::HTML5Token&) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x4DA4DEF: WebCore::HTML5TreeBuilder::constructTreeFromToken(WebCore::HTML5Token&) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x4D9FFEB: WebCore::HTML5DocumentParser::pumpLexer(WebCore::HTML5DocumentParser::SynchronousMode) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x4DA082A: WebCore::HTML5DocumentParser::write(WebCore::SegmentedString const&, bool) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x44867DA: WebCore::DocumentWriter::addData(char const*, int, bool) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== by 0x4489307: WebCore::FrameLoader::addData(char const*, int) (in /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so)
==24760== If you believe this happened as a result of a stack
==24760== overflow in your program's main thread (unlikely but
==24760== possible), you can try to increase the size of the
==24760== main thread stack using the --main-stacksize= flag.
==24760== The main thread stack size used in this run was 8388608.
==24760==
==24760== HEAP SUMMARY:
==24760== in use at exit: 2,721,885 bytes in 11,192 blocks
==24760== total heap usage: 19,657 allocs, 8,465 frees, 5,358,396 bytes allocated
==24760==
==24760== LEAK SUMMARY:
==24760== definitely lost: 120 bytes in 1 blocks
==24760== indirectly lost: 0 bytes in 0 blocks
==24760== possibly lost: 135,940 bytes in 801 blocks
==24760== still reachable: 2,585,825 bytes in 10,390 blocks
==24760== suppressed: 0 bytes in 0 blocks
==24760== Rerun with --leak-check=full to see details of leaked memory
==24760==
==24760== For counts of detected and suppressed errors, rerun with: -v
==24760== Use --track-origins=yes to see where uninitialised values come from
==24760== ERROR SUMMARY: 22 errors from 22 contexts (suppressed: 273 from 56)
Killed
I got the same error, we need to fix it. (In reply to comment #5) > I got the same error, we need to fix it. This seems to occur only on debian based systems. I don't know yet what is causing it but in Gentoo and Archlinux they do not occur. Since some months ago I also had this problem and after updating my system the problem was gone, I guess it's a problem with compiler/linker/libc. Would you answer the following questions? 1) Do you use 64 bits? 2) Are you compiling with build type Release? If yes, try compiling in Debug mode and tell me if it works. 3) What are your versions of gcc, glibc and ld? 4) Are you enabling / disabling any feature? 5) Do you have any changes or you are compiling the latest svn revision? (In reply to comment #6) > (In reply to comment #5) > > I got the same error, we need to fix it. > > This seems to occur only on debian based systems. I don't know yet what is causing it but in Gentoo and Archlinux they do not occur. Since some months ago I also had this problem and after updating my system the problem was gone, I guess it's a problem with compiler/linker/libc. Would you answer the following questions? > > 1) Do you use 64 bits? > 2) Are you compiling with build type Release? If yes, try compiling in Debug mode and tell me if it works. > 3) What are your versions of gcc, glibc and ld? > 4) Are you enabling / disabling any feature? > 5) Do you have any changes or you are compiling the latest svn revision? Sorry for my late response. I had urgent works. > 1) Do you use 64 bits? => I am using 32bit Linux PC with Ubuntu 9.10 > 2) Are you compiling with build type Release? If yes, try compiling in Debug mode and tell me if it works. => Ok, I am building webkit with Release. I will try to compile in Debug, then I will let you know the result. > 3) What are your versions of gcc, glibc and ld? => gcc version = 4.4.1 , glibc = 2.10.1, ld = 2.20 > 4) Are you enabling / disabling any feature? => I am building webkit in default option. > 5) Do you have any changes or you are compiling the latest svn revision? => There are no changes when I built webkit trunk. EWebLauncher still comes to crash. My colleague(Joone) also meet same crash on his linux box. EWebLauncher doesn't crash on Debug build. However, recently, I have network problem in my office. So, I can only test specific websites with EWebLauncher. I will report this in my home again. Created attachment 60628 [details]
Backtrace of EWebLauncher Crash on Release build
EWebLauncher still comes to crash on Release build. However, doesn't crash on Debug build.
Please find attachment.
(un)fortunately I'm not getting this same error thus I can investigate what is happening. Problem is how to investigate this beast. It seems like an optimization or compiler bug, triggering read of uninitialized values. I asked othermaciej at IRC as people said he should know, but he does not. Trying to investigate it exposed other problems, like my gcc-4.4.3 having internal-compiler-errors with some files :-/ Sorry, I meant "noW", not "not" in the previous message. :-) I have gcc 4.5 on my system. I've installed the 4.4.4 version in parallel and with this version I have the same crash of yours. So, Gustavo has crashes with 4.4.3 and I have with 4.4.4. GCC 4.5, however compiles fine. Could you install gcc 4.5 and test as well? I think there's no problem with gcc 4.2 either. (In reply to comment #12) > I have gcc 4.5 on my system. I've installed the 4.4.4 version in parallel and with this version I have the same crash of yours. > > So, Gustavo has crashes with 4.4.3 and I have with 4.4.4. GCC 4.5, however compiles fine. > > Could you install gcc 4.5 and test as well? I think there's no problem with gcc 4.2 either. Sure, I am going to test this with gcc 4.5. Recompiled it with GCC 4.3.4 and it does work. It really, really feels like a compiler bug and not webkit, definitely it is not related to EFL port as it does not touch port-dependent code on crash backtrace. Please downgrade to 4.3.4 or upgrade to 4.5. Note that the 4.5 is quite new and comes with some known bugs as well, related to gperf-generated inline functions, you'll need a patched gperf or to wait some pending patches in webkit that modifies the generated code. Hello Gustavo, WebKit EFL is working well on GCC 4.3.5. As you said, this crash comes from gcc version. But, I think WebKit EFL can work on gcc 4.4.1 as well. Anyway, at last, I can work with EWebLauncher on latest source. Thank you. (In reply to comment #15) > Hello Gustavo, > > WebKit EFL is working well on GCC 4.3.5. As you said, this crash comes from gcc version. But, I think WebKit EFL can work on gcc 4.4.1 as well. Anyway, at last, I can work with EWebLauncher on latest source. Thank you. There seems to be enough evidence that this bug is not a WebKit bug, but a compiler bug. The procedure is usually close it as INVALID, and file a bug against the compiler. Lets do it that ways guys, please. (In reply to comment #16) > (In reply to comment #15) > > Hello Gustavo, > > > > WebKit EFL is working well on GCC 4.3.5. As you said, this crash comes from gcc version. But, I think WebKit EFL can work on gcc 4.4.1 as well. Anyway, at last, I can work with EWebLauncher on latest source. Thank you. > > There seems to be enough evidence that this bug is not a WebKit bug, but a compiler bug. The procedure is usually close it as INVALID, and file a bug against the compiler. Lets do it that ways guys, please. Hello Gustavo, As Antinio Gomes said, could you please close this bug ? I can't change this bug's status with INVALID. Reopening as several distros are shipping gcc 4.4.x and will likely to ship them in the next versions. We must figure the right flags out in order not to fail the build. Created attachment 68475 [details]
Patch
Comment on attachment 68475 [details] Patch Clearing flags on attachment: 68475 Committed r68106: <http://trac.webkit.org/changeset/68106> All reviewed patches have been landed. Closing bug. |