Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#627 closed bug (fixed)

Cannot open another copy of the Terminal program

Reported by: ajsmale@… Owned by: bonefish
Priority: normal Milestone: R1
Component: Applications Version:
Keywords: Cc: diver, Niels.Reedijk@…, bonefish
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by jackburton)

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

Attachments (1)

terminal.png (25.3 KB) - added by jackburton 13 years ago.
debug output

Download all attachments as: .zip

Change History (32)

comment:1 Changed 13 years ago by diver

Cc: diver added

comment:2 Changed 13 years ago by 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.

comment:3 Changed 13 years ago by jackburton

Seems to be gone. Can you confirm ?

comment:4 Changed 13 years ago by ajsmale@…

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

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by diver

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

comment:7 Changed 13 years ago by shaka@…

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

comment:8 Changed 13 years ago by 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.

comment:9 Changed 13 years ago by jackburton

Owner: changed from sikosis to axeld

comment:10 Changed 13 years ago by jackburton

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

Changed 13 years ago by jackburton

Attachment: terminal.png added

debug output

comment:11 Changed 13 years ago by 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.

comment:12 Changed 13 years ago by Niels.Reedijk@…

Cc: Niels.Reedijk@… added

comment:13 Changed 13 years ago by mthayes

Platform: All

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.

comment:14 in reply to:  13 ; Changed 13 years ago by 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.

comment:15 in reply to:  14 Changed 13 years ago by jackburton

Description: modified (diff)

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.

comment:16 Changed 12 years ago by 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).

comment:17 Changed 12 years ago by jackburton

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

comment:18 Changed 12 years ago by diver

I still have this problem with hrev19863.

comment:19 Changed 12 years ago by wkornewald

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

comment:20 in reply to:  19 ; Changed 12 years ago by 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.

comment:21 in reply to:  20 Changed 12 years ago by 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.

comment:22 Changed 12 years ago by 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);

}

comment:23 Changed 12 years ago by korli

Resolution: fixed
Status: newclosed

Applied in revision 20014 (to be reviewed).

comment:24 in reply to:  23 ; Changed 12 years ago by wkornewald

Resolution: fixed
Status: closedreopened

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.

comment:25 in reply to:  24 Changed 12 years ago by 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 ;)

comment:26 Changed 12 years ago by manette

Still hapening in hrev20146. Regards.

comment:27 Changed 12 years ago by bonefish

Cc: bonefish added

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.

comment:28 Changed 12 years ago by bonefish

Owner: changed from axeld to bonefish
Status: reopenednew

comment:29 Changed 12 years ago by bonefish

Resolution: fixed
Status: newclosed

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

comment:30 Changed 12 years ago by jackburton

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

comment:31 in reply to:  30 Changed 12 years ago by 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.

Note: See TracTickets for help on using tickets.