I just observed a case of $SUBJECT: I typed control-D to end a shell session, and bash replied with "Exit", but the xterm window didn't close as it normally does. What's more, clicking on the red window-close button did nothing, which seemed even more surprising. I looked closer, and found: 1. According to ps, that xterm instance was chewing 100% CPU. Its child process was still there, too, but listed as "(bash)", which I think means it was a zombie. So this suggests a failure to respond to SIGCHLD properly. 2. I tried to attach to the process with gdb to get a stack trace. gdb wouldn't let me (something about an OS/kernel failure). On reflection maybe I should have tried with Activity Monitor, but that didn't occur to me in the heat of the moment. 3. I then tried "kill -ABRT", hoping that would produce a debuggable core dump. It stopped the xterm alright, but I can't find a core. Anyway, this is the first time I've seen anything like this, so it isn't terribly reproducible. Just mentioning it in case anyone has seen the like, or has a better idea about how to gather evidence if it happens again. regards, tom lane
http://xquartz.macosforge.org/trac/ticket/557 On May 27, 2012, at 14:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I just observed a case of $SUBJECT: I typed control-D to end a shell session, and bash replied with "Exit", but the xterm window didn't close as it normally does. What's more, clicking on the red window-close button did nothing, which seemed even more surprising. I looked closer, and found:
1. According to ps, that xterm instance was chewing 100% CPU. Its child process was still there, too, but listed as "(bash)", which I think means it was a zombie. So this suggests a failure to respond to SIGCHLD properly.
2. I tried to attach to the process with gdb to get a stack trace. gdb wouldn't let me (something about an OS/kernel failure). On reflection maybe I should have tried with Activity Monitor, but that didn't occur to me in the heat of the moment.
3. I then tried "kill -ABRT", hoping that would produce a debuggable core dump. It stopped the xterm alright, but I can't find a core.
Anyway, this is the first time I've seen anything like this, so it isn't terribly reproducible. Just mentioning it in case anyone has seen the like, or has a better idea about how to gather evidence if it happens again.
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Jeremy Huddleston <jeremyhu@apple.com> writes:
Hmm, that doesn't look related to me. AFAICT, my xterms are being spawned with no command-line switches. Also, that ticket indicates the behavior is reproducible, which mine isn't ... regards, tom lane
On May 27, 2012, at 14:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I just observed a case of $SUBJECT: I typed control-D to end a shell session, and bash replied with "Exit", but the xterm window didn't close as it normally does. What's more, clicking on the red window-close button did nothing, which seemed even more surprising. I looked closer, and found:
1. According to ps, that xterm instance was chewing 100% CPU. Its child process was still there, too, but listed as "(bash)", which I think means it was a zombie. So this suggests a failure to respond to SIGCHLD properly.
2. I tried to attach to the process with gdb to get a stack trace. gdb wouldn't let me (something about an OS/kernel failure). On reflection maybe I should have tried with Activity Monitor, but that didn't occur to me in the heat of the moment.
3. I then tried "kill -ABRT", hoping that would produce a debuggable core dump. It stopped the xterm alright, but I can't find a core.
Anyway, this is the first time I've seen anything like this, so it isn't terribly reproducible. Just mentioning it in case anyone has seen the like, or has a better idea about how to gather evidence if it happens again.
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
You probably hit some command sequence which put xterm into "hold" mode, which is indicated by your initial paragraph. On May 28, 2012, at 18:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeremy Huddleston <jeremyhu@apple.com> writes:
Hmm, that doesn't look related to me. AFAICT, my xterms are being spawned with no command-line switches. Also, that ticket indicates the behavior is reproducible, which mine isn't ...
regards, tom lane
On May 27, 2012, at 14:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I just observed a case of $SUBJECT: I typed control-D to end a shell session, and bash replied with "Exit", but the xterm window didn't close as it normally does. What's more, clicking on the red window-close button did nothing, which seemed even more surprising. I looked closer, and found:
1. According to ps, that xterm instance was chewing 100% CPU. Its child process was still there, too, but listed as "(bash)", which I think means it was a zombie. So this suggests a failure to respond to SIGCHLD properly.
2. I tried to attach to the process with gdb to get a stack trace. gdb wouldn't let me (something about an OS/kernel failure). On reflection maybe I should have tried with Activity Monitor, but that didn't occur to me in the heat of the moment.
3. I then tried "kill -ABRT", hoping that would produce a debuggable core dump. It stopped the xterm alright, but I can't find a core.
Anyway, this is the first time I've seen anything like this, so it isn't terribly reproducible. Just mentioning it in case anyone has seen the like, or has a better idea about how to gather evidence if it happens again.
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Jeremy Huddleston <jeremyhu@apple.com> writes:
You probably hit some command sequence which put xterm into "hold" mode, which is indicated by your initial paragraph.
Oh, if there's some command-meta-footpedal combination that turns that mode on, then I can believe it. I'm a pretty sloppy typist (and I also think my laptop's keyboard is getting flaky and sometimes producing things I didn't hit...) regards, tom lane
participants (2)
-
Jeremy Huddleston
-
Tom Lane