Bug #257
closed
Default surf crashes
100%
Description
Rev to master in git tree. I've got the update to surf.mk in the build tree and a patch to fix a problem with a DOM update applied since 0.6 to the git tree.
Updated by Hammel almost 11 years ago
- % Done changed from 0 to 50
Updated applied and build tested. Built version has been copied to target and verified working.
Updates pushed upstream.
Now I just need to make sure it ends up in the release build.
Updated by Hammel almost 11 years ago
- Status changed from New to Closed
- % Done changed from 50 to 100
Verified working on both Fedora 19 and CentOS 6.4.
Closing issue.
Updated by Hammel almost 11 years ago
- Status changed from Closed to In Progress
- % Done changed from 100 to 50
Reopening because surf broke with 3.10.x/Buildroot 2013.11. I have no idea what the problem is but suspect its webkitgtk, which also causes midori to crash.
There are no meaningful patches applied to webkitgtk since 2013.11. So although there may be a new Buildroot release (2014.02 is out) I don't think it will make a difference.
Note: I'm building surf off of master so maybe setting an earlier git id, such as one from mid/late January would be preferable.
Updated by Hammel almost 11 years ago
- Target version changed from 0.7.0 to 0.8.0
Updated by Hammel almost 11 years ago
Tried to rev to 1.11.92 from 1.11.5 (which is actually a short jump) but the former requires a gcc 4.7 or later. That means I need to rev Crosstool-NG first. That's a major project. So I can't rev webkit.
This just leaves trying to build surf with webkitgtk 1.11.5 and fixing whatever is causing the crash.
Updated by Hammel almost 11 years ago
I recompiled surf with debugging symbols enabled (see attached modified surf.mk). I then installed the xcc-debug opkg and ran surf under gdb. This is what I got.
(gdb) set args http://localhost:2001 (gdb) run Starting program: /root/surf http://localhost:2001 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [New Thread 0xb2e37340 (LWP 1955)] [New Thread 0xb250f340 (LWP 1956)] [New Thread 0xb1bc6340 (LWP 1957)] [New Thread 0xb0dd6340 (LWP 1958)] Program received signal SIGSEGV, Segmentation fault. 0xb3386c60 in JSC::CodeBlock::bytecodeOffset(JSC::ExecState*, JSC::ReturnAddressPtr) () from /usr/lib/libjavascriptcoregtk-1.0.so.0 (gdb) bt #0 0xb3386c60 in JSC::CodeBlock::bytecodeOffset(JSC::ExecState*, JSC::ReturnAddressPtr) () from /usr/lib/libjavascriptcoregtk-1.0.so.0 #1 0xb34c855c in JSC::jitThrow(JSC::JSGlobalData*, JSC::ExecState*, JSC::JSValue, JSC::ReturnAddressPtr) () from /usr/lib/libjavascriptcoregtk-1.0.so.0 #2 0xb34f3ffc in JITStubThunked_vm_throw () from /usr/lib/libjavascriptcoregtk-1.0.so.0 #3 0xb34e9120 in cti_vm_throw () from /usr/lib/libjavascriptcoregtk-1.0.so.0 #4 0xb34e9120 in cti_vm_throw () from /usr/lib/libjavascriptcoregtk-1.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
It looks like its a javascript problem in webkitgtk. So I think the solution may be to rev the toolchain (to get gcc 4.7+ because webkit 2.x requires it) and and then try to rev webkit to the stable 2.x version, then rebuild surf against that. See RM #172.
Updated by Hammel over 10 years ago
- Priority changed from Immediate to Low
- Target version changed from 0.8.0 to 3.0 - Corrino
- Severity changed from 01 - Critical to 05 - Very Low
I tried webkit 2.0.4 but can't get it to build. I rebuilt with gcc 4.7.3 (non-linaro) and surf behaved slightly better but still crashes. So does midori.
So I'm punting on a native browser for PiBox. There's no point wasting more time on this. I can just enable the settings page for non-local users and then look into an authentication mechamism I can overlay on that.
Moving this to very low priority and will revisit it much later.
Updated by Hammel over 1 year ago
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
Browsers will never be supported on PiBox. That's a design decision I made a while back that I'm sticking to. Browsers are just too heavy weight for PiBox use cases.
Closing issue.