Browse segfaults on start on XO-1.75 until reboot

[carrott]

XO-1.75. 12.1.0 build 18. Browse 140.

Booted XO, started browse, browse appears briefly, then dissappears. Segfault in thelog (see attached). I've seen this several times on different laptops on Build 12.1.0 build 18 on XO-1.75. This happens on every attempt to start browse until the laptop is rebooted.

Caught with gdb by attaching during startup with

gdb python ps -ef |grep webactivity | grep -v grep | cut -c 11-14 | tee gdb-session.txt

see attached for backtrace and logs.

[carrott]

browse log with segfault

[carrott]

gdb session with backtrace of segfaulted browse

[dsd]

This could be ​https://bugs.webkit.org/show_bug.cgi?id=90957

[dsd]

replacement /usr/bin/sugar-session

[dsd]

I uploaded a /usr/bin/sugar-session which can be used to hopefully reproduce this issue. It starts browse automatically when sugar starts, waits a while, and if Browse has quit/crashed then it leaves the system running. Otherwise it automatically reboots and the cycle repeats.

[greenfeld]

Prior to the segfaults occurring, was Browse used to visit any website?

Newer versions of Sugar restart the last Journal entry for Browse by default unless you choose to start a new session from the right-click menu.

Browse tries to open the last accessed URL when started from a Journal entry. So unless you tried to start a new instance each time, Browse kept going back to a page which potentially crashed it.

[dsd]

We can reproduce this by opening browse on google.com/search?q=test or just by running /usr/libexec/webkitgtk3/GtkLauncher (which loads the google homepage).

This can be reproduced on:

• webkit-1.8.1 with OLPC patches (shipped in 12.1.0 build 20)
• webkit-1.8.1 from F17
• webkit-1.8.1 on F18

Can't reproduce with:

• webkit-1.9.3 on F18
• webkit-1.9.5 on F18

more detailed trace with debuginfo: ​http://dev.laptop.org/~dsd/20120822/3776bt.txt

full trace: ​http://dev.laptop.org/~dsd/20120822/3776btfull.txt

It's not related to the above webkit bug (#90957) because webkitgtk doesn't use parallel GC in the 1.8 series. It might be related to ​https://bugs.webkit.org/show_bug.cgi?id=56115 - but the code is so different from the bits changed in the fix its hard to say.

Next steps are to build 1.8.3 in case its fixed there (in progress), and also to build with debugging assertions enabled in case that gives clues. As each build takes more than 10 hours this will take a while.

[dsd]

1.8.3 is still affected.

This is fixed in ​http://trac.webkit.org/changeset/109059

[dsd]

This scratch build should include the fix: ​http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1086528

It still has a good few hours left on the build before its ready. I won't be back until Monday afternoon to act on the results.

[greenfeld]

The scratch build solves the Google resume case, and does not seem to have ill effects in casual usage.

If this continues to work we will also need a x86 build.

[dsd]

The patch won't affect x86 (where the JIT is used) and the original bug was against XO-1.75. Do you have any reason to believe that we see this issue on x86?

[greenfeld]

There have been rare cases when I have gotten the XO-1.5 web browser to crash. This often takes 15-30 minutes of Web browsing to cause and I have not come up with a reproducible approach to it yet.

If this codepath is not hit on x86 then we do not have to worry about it then.

[dsd]

OK. This is fixed in webkit-1.9 and proposed for inclusion in webkitgtk-1.8.4. The fix will be included in the upcoming OLPC 12.1.0 build 21.

[greenfeld]

Fixed in OLPC 12.1.0 os21. Tested by attempting to resume to a Google search result page.