Ticket #5639 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

Browse crashes consistantly with certain combination of steps.

Reported by: legutierr Owned by: erikos
Priority: blocker Milestone: Update.1
Component: browse-activity Version: Build 650
Keywords: Cc: Walter, erikos, legutierr
Action Needed: Verified: yes
Deployments affected: Blocked By:
Blocking:

Description

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.

Change History

follow-up: ↓ 4   Changed 6 years ago by marco

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

  Changed 6 years ago by legutierr

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

  Changed 6 years ago by marco

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

in reply to: ↑ 1   Changed 6 years ago by 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.

follow-up: ↓ 6   Changed 6 years ago by marco

  • keywords Update.1? added

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

in reply to: ↑ 5   Changed 6 years ago by 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?

  Changed 6 years ago by marco

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

  Changed 6 years ago by 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.

  Changed 6 years ago by erikos

  • cc erikos added
  • owner changed from erikos to ApprovalForUpdate

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

  Changed 6 years ago by jg

  • keywords Browse crash Update.1? removed
  • milestone changed from Never Assigned to Update.1

Approved.

  Changed 6 years ago by jg

  • owner changed from ApprovalForUpdate to dgilmore

  Changed 6 years ago by marco

  • owner changed from dgilmore to erikos

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.

  Changed 6 years ago by legutierr

  • cc legutierr added

  Changed 6 years ago by marco

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.