BeZilla does not relaunch properly

[mmadia]

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?

[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.

[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.

[mmadia]

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.

[bbjimmy]

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.

[bbjimmy]

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

[anevilyak]

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.

[myob]

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.

[axeld]

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.