Cannot open another copy of the Terminal program

[ajsmale@…]

Test description:

1. Click on the leaf in the Deskbar.
2. Select Applications -> Terminal.

The Terminal window you have just requested does not appear.

Note: This seems to only fail periodically if it's the first action performed after starting up Haiku. From my tests I would estimate you can reproduce it 90% of the time.

After this failure I could get another Terminal window by typing "Terminal" in the original Terminal window that Haiku starts by default, but I could not get one from Deskbar or Tracker.

Test setup: VMWare image rev17582 on XP

[jackburton]

Happens here too. When I launch Terminal from deskbar, a "Terminal" item appears for half a second or so in the deskbar team list, then it disappears, and the Terminal window never shows up.

[jackburton]

Seems to be gone. Can you confirm ?

[ajsmale@…]

Rechecked on the rev17637 image and it still happens intermittently. :-(

[bbjimmy@…]

(In reply to comment #0)

From the latest (06-04-2006) Buildfactory image... click Terminal from the Be menu or double-click the icon in /boot/beos/apps and the Terminal window never shows. ... type Terminal from the open window, and a new Terminal window opens ... select Start New Terminal from the Terminal menu and the new window opens ... If I close the Terminal that opens when the system boots, I have to re-boot to open a Terminal window.

[diver]

It seems, that you could launch Terminal from processcontroller's replicant.

[shaka@…]

Used to happen here, but as of @ 6/20/06 seems fixed.

[umccullough@…]

Confirmed in hrev17923 in VMWare that closing the auto-launched Terminal and attempting to restart it from the deskbar fails as described in this bug.

[jackburton]

Reassigning to axel, as this might be a pipefs bug.

[jackburton]

debug output

[jackburton]

More info:

if started from Terminal, the above loop does this: read returns, handshake.status is PTY_WS, write is called and returns, read returns and handshake.status is PTY_OK. The loop exits. If started from Tracker, read returns, handshake.status is PTY_WS, write is called but never returns.

[mthayes]

I think I may have found a baby-step of a solution. Somehow, the terminal depends on the filetype "application/x-vnd.Be-SHEL" (from R5) being there. I added it using FileTypes and haven't had a lick of trouble starting Terminal since. I am using 19070 and was having the same startup problems with Terminal.

[mthayes]

Correction to that last post: That file type addition had absolutely NOTHING to do with it... I restarted Haiku and the crashes started again. However, I can successfully start a Terminal window via the ProcessController. Can anyone confirm this?

Replying to mthayes:

I think I may have found a baby-step of a solution. Somehow, the terminal depends on the filetype "application/x-vnd.Be-SHEL" (from R5) being there. I added it using FileTypes and haven't had a lick of trouble starting Terminal since. I am using 19070 and was having the same startup problems with Terminal.

[jackburton]

Replying to mthayes:

Correction to that last post: That file type addition had absolutely NOTHING to do with it... I restarted Haiku and the crashes started again. However, I can successfully start a Terminal window via the ProcessController. Can anyone confirm this?

Yes. Starting Terminal via ProcessController works 100% of the times, just like starting from Terminal itself. Starting from Tracker, though, only sometimes works.

[wkornewald]

I have the same problem. I did a ping and pressed CTRL+C. The whole Terminal closed (instead of only killing ping) and after that I couldn't open the Terminal, anymore (from Tracker, at least).

[jackburton]

Interestingly, this seem to be fixed (I tried rebooting thrice, could always launch a new terminal from tracker). Could have been hrev19857 again ?

[diver]

I still have this problem with hrev19863.

[wkornewald]

Yup, still reproducible with hrev19864 and VMware (ping google.com and then CTRL+C).

[jackburton]

Replying to wkornewald:

Yup, still reproducible with hrev19864 and VMware (ping google.com and then CTRL+C).

That's a different problem (and there's already a bug opened for that one). I was just talking about the inability to launch Terminal.

[wkornewald]

Replying to jackburton:

Replying to wkornewald:

Yup, still reproducible with hrev19864 and VMware (ping google.com and then CTRL+C).

That's a different problem (and there's already a bug opened for that one). I was just talking about the inability to launch Terminal.

No, after that I can't launch Terminal, anymore.

[korli]

To reproduce the problem, I press Alt+N several times. Terminal tries to find which number it should put in its window title. It asks the running instances of Terminal and gets some not yet running apps which can't answer requests. Here is a patch which fixes the problem, please comment

Index: src/servers/registrar/TRoster.cpp =================================================================== --- src/servers/registrar/TRoster.cpp (révision 20011) +++ src/servers/registrar/TRoster.cpp (copie de travail) @@ -705,6 +705,8 @@

for (AppInfoList::Iterator it(fRegisteredApps.It());

RosterAppInfo *info = *it; ++it) {

+ if (info->state != APP_STATE_REGISTERED) + continue;

if (!signature

!strcasecmp(signature, info->signature))

reply.AddInt32("teams", info->team);

}

[korli]

Applied in revision 20014 (to be reviewed).

[wkornewald]

Replying to korli:

Applied in revision 20014 (to be reviewed).

Please write hrev20014 instead of "revision", so your changeset gets linked to svnview, automatically.

Anyway, I've tested it with hrev20015 on VMware and I still can reproduce both bugs.

[korli]

Replying to wkornewald:

Replying to korli:

Applied in revision 20014 (to be reviewed).

Please write hrev20014 instead of "revision", so your changeset gets linked to svnview, automatically.

Thanks for the education :)

Anyway, I've tested it with hrev20015 on VMware and I still can reproduce both bugs.

Then it seems I solved another bug testcase, good for me ;)

[manette]

Still hapening in hrev20146. Regards.

[bonefish]

The problem still persists in hrev20387. 100% reproducible in VMWare.

To elaborate a little more on Jack's earlier analysis: The program is terminated in spawn_shell(). fork() succeeds and the parent runs into the handshake loop. It receives PTY_WS and sends a reply. The child runs successfully till the point where it tries to finish the handshake protocol by sending PTY_OK. The write() to cp_pipe[1] never returns. It somehow causes the child to be terminated as well as the parent.

This bug is particularly annoying in combination with bug #113, which closes your first Terminal.

[bonefish]

Fixed in hrev20393. Seemingly related bugs #113 and #928 still persist.

[jackburton]

Isn't a bit scary that (from the commit log of hrev20393) applications started from Tracker don't have a valid stderr ?

[bonefish]

Replying to jackburton:

Isn't a bit scary that (from the commit log of hrev20393) applications started from Tracker don't have a valid stderr ?

Definitely! It's on my ToDo list to fix it. Well, if it still persists, that is. Since Tracker and Deskbar are started by a shell (via fork() + exec()), this might just as well have been a symptom of the CoW bug.