Browse crashes consistantly with certain combination of steps.

[legutierr]

Browse will crash if two things are done in order:

1) the window is scrolled down at least once, and
2) the zoom-in button is pressed in View

I have tested this combination of actions in a variety of contexts, with 100% consistant results (it always crashes):

• text files read out of the filesystem
  
• text files read off the web
  
• html files read out of the file system (from the default homepage)
  
• html files read off the web
  
• connected to the internet via WPA2, and not connected to the internet (i.e. empty networks.cfg file at boot)
  
• immediatly after restart, and then also after working with other activities
  
• doing the scroll by: using the (x) button on the minitor en casing, dragging the scroll bar, or clicking the empty scroll space to "page down"

The crash does NOT seem to take place if the window is scrolled all the way back up to the top, however. If the window is top-aligned, then the crash seems not to happen.

[marco]

Can you please provide logs? They are in /home/olpc/.sugar/default/logs

[legutierr]

Some additional information: if there are two instances of Browse open, doing this in one instance will crash both instances.

[marco]

Browse istances are run all in the same process, so that's expected, yeah.

[legutierr]

Replying to marco:

Can you please provide logs? They are in /home/olpc/.sugar/default/logs

Only one line prints out in the org.laptop.WebActivity-1.log file:

python: Python/ceval.c:2626: PyEval_EvalCodeEx: Assertion `tstate != ((void *)0)' failed.

This is printed right before the crash.

[marco]

Thanks. If you could try out build 666 and try to reproduce it there, that would be useful.

[legutierr]

Replying to marco:

Thanks. If you could try out build 666 and try to reproduce it there, that would be useful.

Sorry, no-can-do. I'm running this on a G1G1 XO and want to keep the system on a stable release. Anyway, I don't know how to update my system yet. Maybe someone else?

[marco]

No problem, I'm able to repro this in jhbuild now, thanks.

[marco]

Enabling gobject threads seem to fix it (I have a theory for it but not quite verified yet). I pushed the fix in joyride for testing.

[erikos]

Went into Web-83.xo which i tested as working with the steps provided in this ticket, and i could reproduce the error with the same steps with an older web activity version. Marco has the bundle in it's public rpm repo.

Since this is the only fix in 83 i guess we can use this ticket for getting this into update.1

[jg]

Approved.

[marco]

Simon, approvals should be always requested for a package, not for a single bug, otherwise it becomes really difficult to track requests. This one is already tracked by #5668. Back to erikos to do testing when it lands.