Bug 40826 – [EFL] EWebLauncher comes to crash

• Component: New Bugs
• Status: RESOLVED FIXED

[Gyuyoung Kim]

EWebLauncher comes to crash after starting to load webpage.

- SUT
  * Ubuntu 9.10

= Backtrace =

#0  0x004cbbbb in WebCore::inlineTagList() () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#1  0x004cc6b6 in WebCore::HTMLElement::inEitherTagList(WebCore::Node const*) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#2  0x004c9d6f in WebCore::HTMLElement::childAllowed(WebCore::Node*) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#3  0x00b9ad29 in WebCore::ContainerNode::addChild(WTF::PassRefPtr<WebCore::Node>) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#4  0x004f6528 in WebCore::LegacyHTMLTreeConstructor::insertNode(WebCore::Node*, bool) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#5  0x004f6e46 in WebCore::LegacyHTMLTreeConstructor::parseToken(WebCore::Token*) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#6  0x00e90891 in WebCore::HTML5TreeBuilder::passTokenToLegacyParser(WebCore::HTML5Token&) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#7  0x00e914d0 in WebCore::HTML5TreeBuilder::constructTreeFromToken(WebCore::HTML5Token&) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#8  0x00e8c7ec in WebCore::HTML5DocumentParser::pumpLexer(WebCore::HTML5DocumentParser::SynchronousMode) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#9  0x00e8d02b in WebCore::HTML5DocumentParser::write(WebCore::SegmentedString const&, bool) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#10 0x00572a5b in WebCore::DocumentWriter::addData(char const*, int, bool) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#11 0x00575378 in WebCore::FrameLoader::addData(char const*, int) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#12 0x00288470 in WebCore::FrameLoaderClientEfl::committedLoad(WebCore::DocumentLoader*, char const*, int) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#13 0x00574657 in WebCore::FrameLoader::committedLoad(WebCore::DocumentLoader*, char const*, int) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#14 0x0056ba5e in WebCore::DocumentLoader::commitLoad(char const*, int) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#15 0x005751db in WebCore::FrameLoader::receivedData(char const*, int) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#16 0x00590d29 in WebCore::MainResourceLoader::addData(char const*, int, bool) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#17 0x005a2188 in WebCore::ResourceLoader::didReceiveData(char const*, int, long long, bool) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#18 0x00590cb0 in WebCore::MainResourceLoader::didReceiveData(char const*, int, long long, bool) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#19 0x005a1d9f in WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle*, char const*, int, int) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#20 0x00a9f41c in WebCore::gotChunkCallback(_SoupMessage*, SoupBuffer*, void*) () from /home/gyuyoung/webkit/WebKit-EWebLauncher/build/WebKit/libewebkit.so
#21 0x01386068 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-2.0.so.0
#22 0x01379072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#23 0x0138e7a8 in ?? () from /usr/lib/libgobject-2.0.so.0
#24 0x0138fb2d in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#25 0x0138ffb6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#26 0x013d2a56 in soup_message_got_chunk (msg=0x80e9c10, chunk=0x807eeb0) at soup-message.c:900
#27 0x013d8544 in read_body_chunk (msg=<value optimized out>) at soup-message-io.c:461
#28 0x013d8c5f in io_read (sock=0x80ecc60, msg=0x80e9c10) at soup-message-io.c:958
#29 0x013869fc in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
#30 0x01379072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#31 0x0138e7a8 in ?? () from /usr/lib/libgobject-2.0.so.0
#32 0x0138fb2d in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#33 0x0138ffb6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#34 0x013e51bd in socket_read_watch (chan=0x80cf858, cond=<value optimized out>, user_data=0x80ecc60) at soup-socket.c:1245
#35 0x01326dab in ?? () from /lib/libglib-2.0.so.0
#36 0x012efe88 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#37 0x0128893b in _ecore_glib_select__locked (ecore_fds=9, rfds=0xbfffd108, wfds=0xbfffd088, efds=0xbfffd008, ecore_timeout=0xbfffd188) at ecore_glib.c:157
#38 _ecore_glib_select (ecore_fds=9, rfds=0xbfffd108, wfds=0xbfffd088, efds=0xbfffd008, ecore_timeout=0xbfffd188) at ecore_glib.c:187
#39 0x0128206c in _ecore_main_select (timeout=0.086713075637817383) at ecore_main.c:476
#40 0x0128262d in _ecore_main_loop_iterate_internal (once_only=<value optimized out>) at ecore_main.c:753
#41 0x01282687 in ecore_main_loop_begin () at ecore_main.c:114
#42 0x0804b6a6 in main ()

[Lucas De Marchi]

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.

[Gustavo Sverzut Barbieri]

Valgrind/memcheck logs would help much more than gdb backtraces. If you can provide those, it will help a lot! :-)

[Gyuyoung Kim]

There is still crash on latest EFLWebkit. If I can get the memcheck by valgrind, I will report it to here.

[Gyuyoung Kim]

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

[Joone Hur]

I got the same error, we need to fix it.

[Lucas De Marchi]

(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?

[Gyuyoung Kim]

(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.

[Gyuyoung Kim]

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.

[Gyuyoung Kim]

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.

[Gustavo Sverzut Barbieri]

(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 :-/

[Gustavo Sverzut Barbieri]

Sorry, I meant "noW", not "not" in the previous message. :-)

[Lucas De Marchi]

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.

[Gyuyoung Kim]

(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.

[Gustavo Sverzut Barbieri]

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.

[Gyuyoung Kim]

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.

[Antonio Gomes]

(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.

[Gyuyoung Kim]

(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.

[Lucas De Marchi]

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.

[Lucas De Marchi]

Created attachment 68475 [details]
Patch

[Lucas De Marchi]

Comment on attachment 68475 [details]
Patch

Clearing flags on attachment: 68475

Committed r68106: <http://trac.webkit.org/changeset/68106>

[Lucas De Marchi]

All reviewed patches have been landed.  Closing bug.