Processed: Re: Bug#673469: libwebkitgtk-1.0-0: segfaults all the time on armel, javascript related

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # restore version from original bugreport
> found 673469 webkit/1.8.1-2
Bug #673469 [libwebkitgtk-3.0-0] libwebkitgtk-1.0-0: segfaults all the time on 
armel, javascript related
Marked as found in versions webkit/1.8.1-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
673469: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673469
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673469: libwebkitgtk-1.0-0: segfaults all the time on armel,

[shawn]

Ohhh shit, this is webkit, not gecko.

v8 works on armel, if there is an option to use v8, that might work.
-- 
-Shawn Landden





-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673469: libwebkitgtk-1.0-0: segfaults all the time on armel,

[shawn]

>Others have reported that compiling with JIT disabled fixes the issue.
Might it be an idea to alter the standard Debian package to patch
Webkit/Source/JavaScriptCore/wtf/Platform.h so that
ENABLE_CLASSIC_INTERPRETER is always set to 1? Then users encountering
crashes can set JavaScriptCoreUseJIT=0 as an environment variable to
fall back to the interpreter. This makes it much easier to verify a
crash actually is related to the JIT. (See JSGlobalData.cpp for the
code that checks JavascriptCoreUseJIT).


I had success with iceweasel 3.5 after turning off the JIT

ACK this change
-- 
-Shawn Landden




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673469: libwebkitgtk-1.0-0: segfaults all the time on armel, javascript related

[Alex Bradbury]

Others have reported that compiling with JIT disabled fixes the issue.
Might it be an idea to alter the standard Debian package to patch
Webkit/Source/JavaScriptCore/wtf/Platform.h so that
ENABLE_CLASSIC_INTERPRETER is always set to 1? Then users encountering
crashes can set JavaScriptCoreUseJIT=0 as an environment variable to
fall back to the interpreter. This makes it much easier to verify a
crash actually is related to the JIT. (See JSGlobalData.cpp for the
code that checks JavascriptCoreUseJIT).

Alex



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673469: libwebkitgtk-1.0-0: segfaults all the time on armel, javascript related

[Alex Bradbury]

It looks like this is the relevant upstream bug (though it's not
totally clear if the original reporter is on armel or armhf)

https://bugs.webkit.org/show_bug.cgi?id=85076

Alex



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673469: libwebkitgtk-1.0-0: segfaults all the time on armel, javascript related

[Timo Juhani Lindfors]

Package: libwebkitgtk-1.0-0
Version: 1.8.1-2
Severity: grave
Justification: renders package unusable

Steps to reproduce:
1) /usr/lib/webkitgtk-1.0-0/libexec/GtkLauncher
2) enter www.google.com as the address
3) search for "debian bts"

Expected results:
3) search results are shown

Actual results:
3) GtkLauncher segfaults almost instantly. You can see the rendered web
   site for a few seconds.

More info:
1) This happens on openmoko and on marvel development boards (mv78100).
2) This makes midori completely unusable :( Midori used to work just
   fine last year, I have not tried to find out which upgrade actually
   broke it.
3) Detailed information from debugger follows. It seems to try to read
   memory from virtual address "0x9" so there's probably a NULL pointer
   to some struct:

(sid)mv78100:~$ gdb --args /usr/lib/webkitgtk-1.0-0/libexec/GtkLauncher 
http://www.google.com/
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
For bug reporting instructions, please see:
...
Reading symbols from /usr/lib/webkitgtk-1.0-0/libexec/GtkLauncher...(no 
debugging symbols found)...done.
(gdb) run
Starting program: /usr/lib/webkitgtk-1.0-0/libexec/GtkLauncher 
http://www.google.com/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
Xlib:  extension "RANDR" missing on display ":4".
[New Thread 0x44af22a0 (LWP 1078)]
[New Thread 0x454122a0 (LWP 1079)]
[New Thread 0x45c332a0 (LWP 1080)]
[New Thread 0x464332a0 (LWP 1082)]
[Thread 0x454122a0 (LWP 1079) exited]
[New Thread 0x454122a0 (LWP 1083)]
[New Thread 0x4a8f92a0 (LWP 1084)]
[New Thread 0x4b2c72a0 (LWP 1085)]
[Thread 0x4a8f92a0 (LWP 1084) exited]
[New Thread 0x4a8f92a0 (LWP 1086)]
[New Thread 0x4bfea2a0 (LWP 1087)]
[Thread 0x4bfea2a0 (LWP 1087) exited]
[Thread 0x4a8f92a0 (LWP 1086) exited]
[New Thread 0x4a8f92a0 (LWP 1088)]
[New Thread 0x4bfea2a0 (LWP 1089)]
[New Thread 0x4c9c62a0 (LWP 1090)]
[New Thread 0x4d1c62a0 (LWP 1091)]
[New Thread 0x4d9c62a0 (LWP 1092)]
[Thread 0x4c9c62a0 (LWP 1090) exited]
[Thread 0x4bfea2a0 (LWP 1089) exited]
[Thread 0x4d1c62a0 (LWP 1091) exited]
[Thread 0x4a8f92a0 (LWP 1088) exited]
[Thread 0x4d9c62a0 (LWP 1092) exited]

Program received signal SIGSEGV, Segmentation fault.
0x41ac3320 in JSC::JSValue::get(JSC::ExecState*, JSC::Identifier const&, 
JSC::PropertySlot&) const () from /usr/lib/libjavascriptcoregtk-1.0.so.0
(gdb) info register
r0 0xbee361d8   3202572760
r1 0xfffb   4294967291
r2 0x4b2c85e0   1261209056
r3 0x4c17fcbc   1276640444
r4 0xbee361e0   3202572768
r5 0x9  9
r6 0x9  9
r7 0xfffb   4294967291
r8 0x14a330
r9 0x44b5e400   1152771072
r100x44b4b06c   1152692332
r110xbee361d8   3202572760
r120xbee36210   3202572816
sp 0xbee36170   0xbee36170
lr 0x41af9604   1102026244
pc 0x41ac3320   0x41ac3320 
cpsr   0x6010   1610612752
(gdb) bt
#0  0x41ac3320 in JSC::JSValue::get(JSC::ExecState*, JSC::Identifier const&, 
JSC::PropertySlot&) const () from /usr/lib/libjavascriptcoregtk-1.0.so.0
#1  0x41af9604 in JITStubThunked_op_get_by_id_self_fail () from 
/usr/lib/libjavascriptcoregtk-1.0.so.0
#2  0x41af69e0 in cti_op_get_by_id_self_fail () from 
/usr/lib/libjavascriptcoregtk-1.0.so.0
#3  0x41af69e0 in cti_op_get_by_id_self_fail () from 
/usr/lib/libjavascriptcoregtk-1.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) x/4i $pc
=> 0x41ac3320 
<_ZNK3JSC7JSValue3getEPNS_9ExecStateERKNS_10IdentifierERNS_12PropertySlotE+44>: 
  ldr r6, [r5, #4]
   0x41ac3324 
<_ZNK3JSC7JSValue3getEPNS_9ExecStateERKNS_10IdentifierERNS_12PropertySlotE+48>: 
  mov r9, r4
   0x41ac3328 
<_ZNK3JSC7JSValue3getEPNS_9ExecStateERKNS_10IdentifierERNS_12PropertySlotE+52>: 
  ldrbr3, [r6, #9]
   0x41ac332c 
<_ZNK3JSC7JSValue3getEPNS_9ExecStateERKNS_10IdentifierERNS_12PropertySlotE+56>: 
  tst r3, #32
(gdb) thread apply all bt full

Thread 8 (Thread 0x4b2c72a0 (LWP 1085)):
#0  0x4188cb4c in __pthread_cond_timedwait (cond=0x44b5fa30, mutex=, abstime=0x4b2c6b98) at pthread_cond_timedwait.c:168
_a1 = -516
_nr = 0
_a1tmp = 1152776756
_a3 = 5
_a2 = 128
_a4 = 1261202280
__ret = 
rt = {tv_sec = 0, tv_nsec = 86550}
futex_val = 5
buffer = {__routine = 0x4188c768 <__condvar_cleanup>, __arg = 
0x4b2c6b48, __canceltype = 1104407981, __prev = 0x