Opened 10 years ago

Closed 10 years ago

#4917 closed bug (fixed)

BeZilla does not relaunch properly

Reported by: mmadia Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This is reproducible, but not 100%. However Alexandre and Rene experience it as well. BeZilla's first launch after boot seems to work all the time. Any relaunch after that isn't guaranteed. First noticed in hrev33789 (or hrev33861). hrev33770 seems to work. hrev33777 exhibits the issue. Possibly due to the work on ports in 33771~33777?

Change History (8)

comment:1 by axeld, 10 years ago

Unlikely, but who knows. I've seen this problem as well, btw. Sometimes it even comes up again, but most of the time, once this happens you're struck. I didn't look into it yet, though.

comment:2 by bbjimmy, 10 years ago

seems to be associated with having NetSurf and BezillaBrowser both installed. I changed the build environment to exclude NetSurf and now hrev33943 doesn't appear to have the issue.

in reply to:  2 comment:3 by mmadia, 10 years ago

Replying to bbjimmy:

seems to be associated with having NetSurf and BezillaBrowser both installed. I changed the build environment to exclude NetSurf and now hrev33943 doesn't appear to have the issue.

You may be thinking of an issue with displaying images. Either way, NetSurf isn't involved as I don't install it.

comment:4 by bbjimmy, 10 years ago

I am aware of the image issue. BeZillaBrowser would show in the Deskbar and never open a Window. Now that I have removed NetSurf from the build this doesn't appear to happen. With NetSurf installed it would happen consistently. This may not be the cause but may have some influence on the issue and help to resolve it.

comment:5 by bbjimmy, 10 years ago

How to reproduce the error.

Download and install the QT4 demo pack http://downloads.beosfrance.com/Qt4HaikuDemoPack_a1.zip

run both the BeZillaBrowser and the Demo Browser.

quit the demo browser

Quit BeZillaBrowser

re-launch BezillaBrowser

in reply to:  1 comment:6 by anevilyak, 10 years ago

Replying to axeld:

Unlikely, but who knows. I've seen this problem as well, btw. Sometimes it even comes up again, but most of the time, once this happens you're struck. I didn't look into it yet, though.

I can confirm the same here, prior to the ports subsystem rewrite I'd never seen this behavior before, now I can reproduce it trivially. If the rewrite isn't directly at fault, it's at least caused a behavior change somewhere that results in this bug being uncovered, whatever it might be. Looking at the thread states unfortunately doesn't seem to yield much of a hint, the main app thread is waiting in read_port() via BLooper and the other mozilla worker threads are waiting on NSPR condition variables (currently implemented via semaphores), so I really don't see what else might be responsible.

comment:7 by myob, 10 years ago

I can confirm this, but its appearing as Bezilla often refusing to launch at all, and never relaunching in a boot session; with any revision I've tried since hrev33770.

I've a dual core PC if that any bearing at all.

comment:8 by axeld, 10 years ago

Resolution: fixed
Status: newclosed
Version: R1/alpha1R1/Development

The actual culprit was hrev33773 - Firefox scans the semaphore list in order to decide whether or not to create a new event port, but this could easily fail, since get_next_sem_info() only worked for monotonically increasing semaphore IDs - but while that works for ports, it does not work for semaphores; they increase their IDs in a smarter way.

Anyway, fixed in hrev34074.

Note: See TracTickets for help on using tickets.