Trying to load the WebAssembly demo at http://webassembly.org/demo/ causes the GTK+ MiniBrowser to crash (on trunk of today: r220223)
Created attachment 317188 [details] GDB backtrace on a Debug build of WebKitGTK+ at r220223
Created attachment 317189 [details] GDB backtrace on a Release build of WebKitGTK+ at r220223
I have attached backtraces of the crash (both in Debug and Release mode). When running in Debug mode it takes a bit longer to crash than on Release (somehow expected). But it seems it crashes on a different part. On Debug https://bugs.webkit.org/attachment.cgi?id=317188 : Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f88b1628fb1 in bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop() (this=0x7f88bdca20f0) at /home/clopez/webkit/webkit/Source/bmalloc/bmalloc/FixedVector.h:101 101 return m_buffer[--m_size]; [Current thread is 1 (Thread 0x7f889f0d2ac0 (LWP 25691))] On Release https://bugs.webkit.org/attachment.cgi?id=317189 : Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f66dac1f51e in WTF::PriorityQueue<JSC::Wasm::Worklist::QueueElement, &JSC::Wasm::Worklist::isHigherPriority, 10ul>::siftUp(unsigned long) () from /home/clopez/webkit/webkit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18 [Current thread is 1 (Thread 0x7f66c9fadac0 (LWP 18001))]
(In reply to Carlos Alberto Lopez Perez from comment #3) > I have attached backtraces of the crash (both in Debug and Release mode). > > When running in Debug mode it takes a bit longer to crash than on Release > (somehow expected). But it seems it crashes on a different part. > > > On Debug https://bugs.webkit.org/attachment.cgi?id=317188 : > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f88b1628fb1 in bmalloc::FixedVector<bmalloc::BumpRange, > 3ul>::pop() (this=0x7f88bdca20f0) at > /home/clopez/webkit/webkit/Source/bmalloc/bmalloc/FixedVector.h:101 > 101 return m_buffer[--m_size]; > [Current thread is 1 (Thread 0x7f889f0d2ac0 (LWP 25691))] > > > On Release https://bugs.webkit.org/attachment.cgi?id=317189 : > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f66dac1f51e in > WTF::PriorityQueue<JSC::Wasm::Worklist::QueueElement, > &JSC::Wasm::Worklist::isHigherPriority, 10ul>::siftUp(unsigned long) () from > /home/clopez/webkit/webkit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0. > so.18 > [Current thread is 1 (Thread 0x7f66c9fadac0 (LWP 18001))]
OK, reproduced.
(In reply to Yusuke Suzuki from comment #5) > OK, reproduced. Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version imcompatibility). Hmm, I can't reproduce it.
(In reply to Yusuke Suzuki from comment #6) > (In reply to Yusuke Suzuki from comment #5) > > OK, reproduced. > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > imcompatibility). Hmm, I can't reproduce it. My build is r220261. WebKitGTK+. Minibrowser. I opened http://webassembly.org/demo/Tanks/. It shows an alert that "Web Audio API is not supported in this browser". Then, I pressed the close button. And it works.
(In reply to Yusuke Suzuki from comment #6) > (In reply to Yusuke Suzuki from comment #5) > > OK, reproduced. > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > imcompatibility). Hmm, I can't reproduce it. Try running with AC disabled: export WEBKIT_DISABLE_COMPOSITING_MODE=1 Tools/Scripts/run-minibrowser --gtk http://webassembly.org/demo Does this helps to avoid the NVIDIA related crash?
(In reply to Yusuke Suzuki from comment #7) > (In reply to Yusuke Suzuki from comment #6) > > (In reply to Yusuke Suzuki from comment #5) > > > OK, reproduced. > > > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > > imcompatibility). Hmm, I can't reproduce it. > > My build is r220261. WebKitGTK+. Minibrowser. > I opened http://webassembly.org/demo/Tanks/. It shows an alert that "Web > Audio API is not supported in this browser". Then, I pressed the close > button. And it works. I will try again with a new build on r220261. Thanks for testing
(In reply to Carlos Alberto Lopez Perez from comment #9) > (In reply to Yusuke Suzuki from comment #7) > > (In reply to Yusuke Suzuki from comment #6) > > > (In reply to Yusuke Suzuki from comment #5) > > > > OK, reproduced. > > > > > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > > > imcompatibility). Hmm, I can't reproduce it. > > > > My build is r220261. WebKitGTK+. Minibrowser. > > I opened http://webassembly.org/demo/Tanks/. It shows an alert that "Web > > Audio API is not supported in this browser". Then, I pressed the close > > button. And it works. > > I will try again with a new build on r220261. > > Thanks for testing Ah, thank you. I've rebooted the machine and now it works. But I cannot reproduce this bug... Task seems working :(
(In reply to Carlos Alberto Lopez Perez from comment #9) > (In reply to Yusuke Suzuki from comment #7) > > (In reply to Yusuke Suzuki from comment #6) > > > (In reply to Yusuke Suzuki from comment #5) > > > > OK, reproduced. > > > > > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > > > imcompatibility). Hmm, I can't reproduce it. > > > > My build is r220261. WebKitGTK+. Minibrowser. > > I opened http://webassembly.org/demo/Tanks/. It shows an alert that "Web > > Audio API is not supported in this browser". Then, I pressed the close > > button. And it works. > > I will try again with a new build on r220261. > > Thanks for testing It crashes for me as well with r220261. I'm currently building with clang-3.8 I will rebuild with GCC to discard a compiler issue.
(In reply to Carlos Alberto Lopez Perez from comment #11) > (In reply to Carlos Alberto Lopez Perez from comment #9) > > (In reply to Yusuke Suzuki from comment #7) > > > (In reply to Yusuke Suzuki from comment #6) > > > > (In reply to Yusuke Suzuki from comment #5) > > > > > OK, reproduced. > > > > > > > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > > > > imcompatibility). Hmm, I can't reproduce it. > > > > > > My build is r220261. WebKitGTK+. Minibrowser. > > > I opened http://webassembly.org/demo/Tanks/. It shows an alert that "Web > > > Audio API is not supported in this browser". Then, I pressed the close > > > button. And it works. > > > > I will try again with a new build on r220261. > > > > Thanks for testing > > It crashes for me as well with r220261. > I'm currently building with clang-3.8 > I will rebuild with GCC to discard a compiler issue. My GCC is 5.4.0, Ubuntu 16.04 :)
(In reply to Carlos Alberto Lopez Perez from comment #11) > (In reply to Carlos Alberto Lopez Perez from comment #9) > > (In reply to Yusuke Suzuki from comment #7) > > > (In reply to Yusuke Suzuki from comment #6) > > > > (In reply to Yusuke Suzuki from comment #5) > > > > > OK, reproduced. > > > > > > > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > > > > imcompatibility). Hmm, I can't reproduce it. > > > > > > My build is r220261. WebKitGTK+. Minibrowser. > > > I opened http://webassembly.org/demo/Tanks/. It shows an alert that "Web > > > Audio API is not supported in this browser". Then, I pressed the close > > > button. And it works. > > > > I will try again with a new build on r220261. > > > > Thanks for testing > > It crashes for me as well with r220261. > I'm currently building with clang-3.8 > I will rebuild with GCC to discard a compiler issue. It is a compiler issue :o It works fine when I rebuild with GCC 6.3 (Debian 9) I will try again with Clang-4.0
(In reply to Carlos Alberto Lopez Perez from comment #13) > (In reply to Carlos Alberto Lopez Perez from comment #11) > > (In reply to Carlos Alberto Lopez Perez from comment #9) > > > (In reply to Yusuke Suzuki from comment #7) > > > > (In reply to Yusuke Suzuki from comment #6) > > > > > (In reply to Yusuke Suzuki from comment #5) > > > > > > OK, reproduced. > > > > > > > > > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > > > > > imcompatibility). Hmm, I can't reproduce it. > > > > > > > > My build is r220261. WebKitGTK+. Minibrowser. > > > > I opened http://webassembly.org/demo/Tanks/. It shows an alert that "Web > > > > Audio API is not supported in this browser". Then, I pressed the close > > > > button. And it works. > > > > > > I will try again with a new build on r220261. > > > > > > Thanks for testing > > > > It crashes for me as well with r220261. > > I'm currently building with clang-3.8 > > I will rebuild with GCC to discard a compiler issue. > > It is a compiler issue :o > > It works fine when I rebuild with GCC 6.3 (Debian 9) > > I will try again with Clang-4.0 It crashes also with Clang 4.0 :\
(In reply to Carlos Alberto Lopez Perez from comment #14) > (In reply to Carlos Alberto Lopez Perez from comment #13) > > (In reply to Carlos Alberto Lopez Perez from comment #11) > > > (In reply to Carlos Alberto Lopez Perez from comment #9) > > > > (In reply to Yusuke Suzuki from comment #7) > > > > > (In reply to Yusuke Suzuki from comment #6) > > > > > > (In reply to Yusuke Suzuki from comment #5) > > > > > > > OK, reproduced. > > > > > > > > > > > > Ah, no. My crash is related to upgraded NVIDIA OpenGL library. (version > > > > > > imcompatibility). Hmm, I can't reproduce it. > > > > > > > > > > My build is r220261. WebKitGTK+. Minibrowser. > > > > > I opened http://webassembly.org/demo/Tanks/. It shows an alert that "Web > > > > > Audio API is not supported in this browser". Then, I pressed the close > > > > > button. And it works. > > > > > > > > I will try again with a new build on r220261. > > > > > > > > Thanks for testing > > > > > > It crashes for me as well with r220261. > > > I'm currently building with clang-3.8 > > > I will rebuild with GCC to discard a compiler issue. > > > > It is a compiler issue :o > > > > It works fine when I rebuild with GCC 6.3 (Debian 9) > > > > I will try again with Clang-4.0 > > It crashes also with Clang 4.0 :\ Ugh, I believe this is due to some of undefined behavior in the code.
Yeah, I've built WebKit with clang-3.9 and reproduced this issue.
Yeah, with clang-3.9, I reproduced the above ones. The problem is that I'm not sure why SEGV happens in debug build. Yeah, bmalloc FixedVector::pop() causes it. But m_buffer and m_size are completely valid. And I can access these values from gdb. My guess is that this SEGV is caused by Wasm (signaling fast memory). And we failed to catch it in signal handlers somehow. I'm now investigating.
(In reply to Yusuke Suzuki from comment #17) > Yeah, with clang-3.9, I reproduced the above ones. > The problem is that I'm not sure why SEGV happens in debug build. > Yeah, bmalloc FixedVector::pop() causes it. But m_buffer and m_size are > completely valid. And I can access these values from gdb. > > My guess is that this SEGV is caused by Wasm (signaling fast memory). > And we failed to catch it in signal handlers somehow. > I'm now investigating. Hm, maybe it's not correct.
Thread 1 "WebKitWebProces" received signal SIGSEGV, Segmentation fault. 0x00007f4dde6ec4f1 in bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop (this=0x7f4debca8860) at ../../../Source/bmalloc/bmalloc/FixedVector.h:101 101 return m_buffer[--m_size]; 0x7f4dde6ec4dd <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+77>: dec %rdx 0x7f4dde6ec4e0 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+80>: mov %rdx,(%rcx) 0x7f4dde6ec4e3 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+83>: mov %rax,%rdi 0x7f4dde6ec4e6 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+86>: mov %rdx,%rsi 0x7f4dde6ec4e9 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+89>: callq 0x7f4ddd512970 <_ZNSt5arrayIN7bmalloc9BumpRangeELm3EEixEm@plt> 0x7f4dde6ec4ee <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+94>: movups (%rax),%xmm0 => 0x7f4dde6ec4f1 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+97>: movaps %xmm0,-0x10(%rbp) 0x7f4dde6ec4f5 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+101>: mov -0x10(%rbp),%rax 0x7f4dde6ec4f9 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+105>: mov -0x8(%rbp),%dx 0x7f4dde6ec4fd <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+109>: add $0x20,%rsp 0x7f4dde6ec501 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+113>: pop %rbp 0x7f4dde6ec502 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+114>: retq rax 0x7f4debca8878 139972645128312 rbx 0x7f4d28647f50 139969366884176 rcx 0x7f4debca8860 139972645128288 rdx 0x1 1 rsi 0x7f4debca8878 139972645128312 rdi 0x7f4debca8868 139972645128296 rbp 0x7ffdbfe22278 0x7ffdbfe22278 rsp 0x7ffdbfe22258 0x7ffdbfe22258 r8 0x7ffdbfe22601 140727822722561 r9 0x7ffdbfe22517 140727822722327 r10 0x477b 18299 r11 0x7f4dde58cef0 139972419571440 r12 0x7f4d3d62c0a0 139969719091360 r13 0x7f4c23700000 139964988784640 r14 0x1af77c 1767292 r15 0x0 0 rip 0x7f4dde6ec4f1 0x7f4dde6ec4f1 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+97> eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 current thread stackbounds => m_origin = 0x7ffdbfe26000, m_bound = 0x7ffdbf629000 $rax is valid value, which is &m_buffer[--m_size] (gdb) p &m_buffer $6 = (std::array<bmalloc::BumpRange, 3> *) 0x7f4debca8868 (gdb) p m_size $7 = 1 (gdb) p &m_buffer[m_size] $8 = (bmalloc::BumpRange *) 0x7f4debca8878 (gdb) p m_buffer $9 = {_M_elems = {{begin = 0x7f4bcf4a4300 "\002", objectCount = 1}, {begin = 0x7f4bcf4a4900 "", objectCount = 1}, {begin = 0x7f4bcf4a4d80 "", objectCount = 1}}} (gdb) p $_siginfo._sifields._sigfault.si_addr $10 = (void *) 0x0 (gdb) p $_siginfo $11 = {si_signo = 11, si_errno = 0, si_code = 128, _sifields = {_pad = {0, 0, 0, 0, 0, 0, -1329485920, 0, 1184582512, 32568, 833711940, 32765, -1329485920, 0, 5863560, 0, 0, 0, 44, 0, 0, 0, -563165967, 0, 30389168, 0, 0, 0}, _kill = {si_pid = 0, si_uid = 0}, _timer = {si_tid = 0, si_overrun = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _rt = {si_pid = 0, si_uid = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _sigchld = {si_pid = 0, si_uid = 0, si_status = 0, si_utime = 0, si_stime = -5710098546892472320}, _sigfault = {si_addr = 0x0, _addr_lsb = 0, _addr_bnd = {_lower = 0x0, _upper = 0xb0c1a7a0}}, _sigpoll = {si_band = 0, si_fd = 0}}} Hmm, so, what raises this SEGV? Carlos, do you have any idea?
Is this bug still valid?
(In reply to Yusuke Suzuki from comment #19) > Thread 1 "WebKitWebProces" received signal SIGSEGV, Segmentation fault. > 0x00007f4dde6ec4f1 in bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop > (this=0x7f4debca8860) at ../../../Source/bmalloc/bmalloc/FixedVector.h:101 > 101 return m_buffer[--m_size]; > > 0x7f4dde6ec4dd <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+77>: > dec %rdx > 0x7f4dde6ec4e0 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+80>: > mov %rdx,(%rcx) > 0x7f4dde6ec4e3 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+83>: > mov %rax,%rdi > 0x7f4dde6ec4e6 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+86>: > mov %rdx,%rsi > 0x7f4dde6ec4e9 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+89>: > callq 0x7f4ddd512970 <_ZNSt5arrayIN7bmalloc9BumpRangeELm3EEixEm@plt> > 0x7f4dde6ec4ee <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+94>: > movups (%rax),%xmm0 > => 0x7f4dde6ec4f1 <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+97>: > movaps %xmm0,-0x10(%rbp) > 0x7f4dde6ec4f5 <bmalloc::FixedVector<bmalloc::BumpRange, > 3ul>::pop()+101>: mov -0x10(%rbp),%rax > 0x7f4dde6ec4f9 <bmalloc::FixedVector<bmalloc::BumpRange, > 3ul>::pop()+105>: mov -0x8(%rbp),%dx > 0x7f4dde6ec4fd <bmalloc::FixedVector<bmalloc::BumpRange, > 3ul>::pop()+109>: add $0x20,%rsp > 0x7f4dde6ec501 <bmalloc::FixedVector<bmalloc::BumpRange, > 3ul>::pop()+113>: pop %rbp > 0x7f4dde6ec502 <bmalloc::FixedVector<bmalloc::BumpRange, > 3ul>::pop()+114>: retq > > rax 0x7f4debca8878 139972645128312 > rbx 0x7f4d28647f50 139969366884176 > rcx 0x7f4debca8860 139972645128288 > rdx 0x1 1 > rsi 0x7f4debca8878 139972645128312 > rdi 0x7f4debca8868 139972645128296 > rbp 0x7ffdbfe22278 0x7ffdbfe22278 > rsp 0x7ffdbfe22258 0x7ffdbfe22258 > r8 0x7ffdbfe22601 140727822722561 > r9 0x7ffdbfe22517 140727822722327 > r10 0x477b 18299 > r11 0x7f4dde58cef0 139972419571440 > r12 0x7f4d3d62c0a0 139969719091360 > r13 0x7f4c23700000 139964988784640 > r14 0x1af77c 1767292 > r15 0x0 0 > rip 0x7f4dde6ec4f1 0x7f4dde6ec4f1 > <bmalloc::FixedVector<bmalloc::BumpRange, 3ul>::pop()+97> > eflags 0x10206 [ PF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x0 0 > gs 0x0 0 > > current thread stackbounds => m_origin = 0x7ffdbfe26000, m_bound = > 0x7ffdbf629000 > > $rax is valid value, which is &m_buffer[--m_size] > > (gdb) p &m_buffer > $6 = (std::array<bmalloc::BumpRange, 3> *) 0x7f4debca8868 > (gdb) p m_size > $7 = 1 > (gdb) p &m_buffer[m_size] > $8 = (bmalloc::BumpRange *) 0x7f4debca8878 > (gdb) p m_buffer > $9 = {_M_elems = {{begin = 0x7f4bcf4a4300 "\002", objectCount = 1}, {begin = > 0x7f4bcf4a4900 "", objectCount = 1}, {begin = 0x7f4bcf4a4d80 "", objectCount > = 1}}} > (gdb) p $_siginfo._sifields._sigfault.si_addr > $10 = (void *) 0x0 > (gdb) p $_siginfo > $11 = {si_signo = 11, si_errno = 0, si_code = 128, _sifields = {_pad = {0, > 0, 0, 0, 0, 0, -1329485920, 0, 1184582512, 32568, 833711940, 32765, > -1329485920, 0, 5863560, 0, 0, 0, 44, 0, 0, 0, -563165967, 0, > 30389168, 0, 0, 0}, _kill = {si_pid = 0, si_uid = 0}, _timer = {si_tid > = 0, si_overrun = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _rt = > {si_pid = 0, si_uid = 0, si_sigval = {sival_int = 0, > sival_ptr = 0x0}}, _sigchld = {si_pid = 0, si_uid = 0, si_status = > 0, si_utime = 0, si_stime = -5710098546892472320}, _sigfault = {si_addr = > 0x0, _addr_lsb = 0, _addr_bnd = {_lower = 0x0, > _upper = 0xb0c1a7a0}}, _sigpoll = {si_band = 0, si_fd = 0}}} > > > Hmm, so, what raises this SEGV? > Carlos, do you have any idea? I think it's still valid. Maybe, my $pc dump needs a bit offset fix to dump the correct code. Once I do work on my hand, I'll check it again.