12:04 a.m.
I am running crash in a shell window of JOVE. JOVE is an EMACS-subset
editor.
crash isn't really happy. Here is an example:
crash> task
WARNING: terminal is not fully functional
- (press RETURN)
==> It does not say in what way the terminal is not fully functional. That seems like
a bug.
==> Worse: while it is awaiting my RETURN, it is burning 100% of the CPU!
Here is what "ps laxgwf" says about the crash process and its child.
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 0 4426 4406 25 0 416812 332764 - R+ pts/5 80:36 |
| \_ crash --readnow /usr/lib/debug/lib/modules/2.6.21-1.3228.fc7/vmlinux
/var/crash/2007-07-02-13:42/vmcore
0 0 4989 4426 18 0 73976 740 - S+ pts/5 0:00 |
| \_ /usr/bin/less -E -X -Ps -- MORE -- forward\: <SPACE>,
<ENTER> or j backward\: b or k quit\: q
strace of the crash process shows an infinite sequence of:
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
This is very wasteful.
There are other ways to get into this state. Other places less is
being used and is waiting. Probably wherever less is used even if it
isn't waiting.
I just tested: this problem exists when using a normal xterm.
8:23 a.m.
D. Hugh Redelmeier wrote:
I am running crash in a shell window of JOVE. JOVE is an
EMACS-subset
editor.
crash isn't really happy. Here is an example:
crash> task
WARNING: terminal is not fully functional
- (press RETURN)
==> It does not say in what way the terminal is not fully functional. That seems like
a bug.
Sorry, but I have no idea where that WARNING message is coming from,
i.e., it's not coming from the crash/gdb code base, nor does the
string "functional" show up in any of the external libraries. There
is a crash function that prints "WARNING:" before a passed-in message,
but no instances of it issue that "functional" message. And the
"(press RETURN)" is most certainly not associated with the crash/gdb
code base.
So I don't know what the "It" is.
==> Worse: while it is awaiting my RETURN, it is burning 100% of the CPU!
Here is what "ps laxgwf" says about the crash process and its child.
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 0 4426 4406 25 0 416812 332764 - R+ pts/5 80:36 |
| \_ crash --readnow
/usr/lib/debug/lib/modules/2.6.21-1.3228.fc7/vmlinux /var/crash/2007-07-02-13:42/vmcore
0 0 4989 4426 18 0 73976 740 - S+ pts/5 0:00 |
| \_ /usr/bin/less -E -X -Ps -- MORE -- forward\: <SPACE>,
<ENTER> or j backward\: b or k quit\: q
strace of the crash process shows an infinite sequence of:
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
This is very wasteful.
There are other ways to get into this state. Other places less is
being used and is waiting. Probably wherever less is used even if it
isn't waiting.
I just tested: this problem exists when using a normal xterm.
Yeah, I have seen this on occasions, but I have never been able
to reproduce it on demand. There was a patch suggestion a while ago,
but I deferred it until I could reliably reproduce it for testing
before taking it in.
Dave
9:50 a.m.
New subject: paging command [was Re: crash CPU bound waiting for user response]
| From: Dave Anderson <anderson(a)redhat.com>
| > ==> It does not say in what way the terminal is not fully functional. That
| > seems like a bug.
|
| Sorry, but I have no idea where that WARNING message is coming from,
| i.e., it's not coming from the crash/gdb code base, nor does the
| string "functional" show up in any of the external libraries. There
| is a crash function that prints "WARNING:" before a passed-in message,
| but no instances of it issue that "functional" message. And the
| "(press RETURN)" is most certainly not associated with the crash/gdb
| code base.
|
| So I don't know what the "It" is.
Right.
It seems to be coming from /usr/bin/less.
So I tried to suppress by setting the PAGER environment variable to
/bin/cat. No luck.
The code in main.c:setup_environment ought to use the PAGER
environment variable if it is defined. This would require changing
scroll_command field, probably from an int to a string containing the
command's path. (It is probable that a copy of the string need not be
created since environment variable values are stable.) I would be
willing to propose a patch if you (Dave) would be willing to consider
it.
It turns out that the crash command
set scroll off
does what I need. The crash(8) man page did not even hint at this
capability.
10:19 a.m.
New subject: paging command [was Re: crash CPU bound waiting for user response]
D. Hugh Redelmeier wrote:
| From: Dave Anderson <anderson(a)redhat.com>
| > ==> It does not say in what way the terminal is not fully functional. That
| > seems like a bug.
|
| Sorry, but I have no idea where that WARNING message is coming from,
| i.e., it's not coming from the crash/gdb code base, nor does the
| string "functional" show up in any of the external libraries. There
| is a crash function that prints "WARNING:" before a passed-in message,
| but no instances of it issue that "functional" message. And the
| "(press RETURN)" is most certainly not associated with the crash/gdb
| code base.
|
| So I don't know what the "It" is.
Right.
It seems to be coming from /usr/bin/less.
Based upon running within that emacs/Jove environment I guess?
So I tried to suppress by setting the PAGER environment variable to
/bin/cat. No luck.
The code in main.c:setup_environment ought to use the PAGER
environment variable if it is defined. This would require changing
scroll_command field, probably from an int to a string containing the
command's path. (It is probable that a copy of the string need not be
created since environment variable values are stable.) I would be
willing to propose a patch if you (Dave) would be willing to consider
it.
I prefer not to change the default behaviour based upon the
user's PAGER variable. I'm not sure what you'd want to change
it to, but if you come up with a scheme to do it based upon
a .crashrc entry, or runtime "set" command, or whatever, I'll
certainly consider it. I just don't want to upset everybody
else's applecart.
It turns out that the crash command
set scroll off
does what I need. The crash(8) man page did not even hint at this
capability.
Yeah, the man page is pretty simple-minded. As you can see, I didn't
write it, preferring to keep crash usage documentation self-contained
within the utility itself.
The "help" command shows this:
crash> help
* files mod runq union
alias foreach mount search vm
ascii fuser net set vtop
bt gdb p sig waitq
btop help ps struct whatis
dev irq pte swap wr
dis kmem ptob sym q
eval list ptov sys
exit log rd task
extend mach repeat timer
crash version: 4.0-4.3 gdb version: 6.1
For help on any command above, enter "help <command>".
For help on input options, enter "help input".
For help on output options, enter "help output".
crash>
And "help output" shows this:
crash> help output
By default, crash command output is piped to "/usr/bin/less -E -X" along
with a prompt line. This behavior can be turned off in two ways:
1. During runtime, enter "set scroll off" or the alias "sf".
2. Enter "set scroll off" in a .crashrc file, which can be located either
in the current directory or in your home directory.
To restore the scrolling behavior during runtime, enter "set scroll on"
or the alias: "sn"
...
Dave
10:54 p.m.
New subject: paging command [was Re: crash CPU bound waiting for user response]
[I hope that you don't mind my jumping in with both feet. I think
that fresh eyes are valuable. After a short time one gets used to
things and no longer notices what would newbies stumble over.]
| From: Dave Anderson <anderson(a)redhat.com>
| D. Hugh Redelmeier wrote:
| > | > ==> It does not say in what way the terminal is not fully functional.
| > It seems to be coming from /usr/bin/less.
| Based upon running within that emacs/Jove environment I guess?
Based on $TERM ("vanilla") and the corresponding termcap or terminfo
entry. To see this, try:
TERM=vanilla less /etc/fstab
| > The code in main.c:setup_environment ought to use the PAGER
| > environment variable if it is defined.
| I prefer not to change the default behaviour based upon the
| user's PAGER variable.
The PAGER variable is a UNIX/Linux convention. Not too well
documented, but real. Kind of like EDITOR and VISUAL.
Now that I know how to avoid the problem, I don't care much for my own
sake.
| Yeah, the man page is pretty simple-minded. As you can see, I didn't
| write it, preferring to keep crash usage documentation self-contained
| within the utility itself.
Man pages are another good and longstanding UNIX/Linux tradition.
At a minimum, the man page should say that it is incomplete and that
the definitive documentation is the help command. It should also have
a FILES section to point out ~/.crashrc.
BTW, I tried
set edit emacs
and got
set: cannot change editing mode during runtime
I don't think that it would be hard to fix this:
- in cmdline.c:readline_init, change all calls to rl_bind_key to be
calls to rl_bind_key_in_map using the vi_movement_keymap keymap.
This way the emacs map won't get damaged.
Move these binding commands out of the "if" -- they need to be
executed unconditionally.
- each time where you would print the error message "cannot change
editing mode...", just do change it (i.e. change rl_editing_mode and
pc->editing_mode).
Is there a reason to have a pc->editing_mode? Could rl_editing_mode
suffice?
Note: I have not tested this and I've never programmed any readline
calls, so I might well be missing something.
8:28 a.m.
New subject: paging command [was Re: crash CPU bound waiting for user response]
D. Hugh Redelmeier wrote:
[I hope that you don't mind my jumping in with both feet. I
think
that fresh eyes are valuable. After a short time one gets used to
things and no longer notices what would newbies stumble over.]
| From: Dave Anderson <anderson(a)redhat.com>
| D. Hugh Redelmeier wrote:
| > | > ==> It does not say in what way the terminal is not fully functional.
| > It seems to be coming from /usr/bin/less.
| Based upon running within that emacs/Jove environment I guess?
Based on $TERM ("vanilla") and the corresponding termcap or terminfo
entry. To see this, try:
TERM=vanilla less /etc/fstab
| > The code in main.c:setup_environment ought to use the PAGER
| > environment variable if it is defined.
| I prefer not to change the default behaviour based upon the
| user's PAGER variable.
The PAGER variable is a UNIX/Linux convention. Not too well
documented, but real. Kind of like EDITOR and VISUAL.
Now that I know how to avoid the problem, I don't care much for my own
sake.
Good...
| Yeah, the man page is pretty simple-minded. As you can see, I
didn't
| write it, preferring to keep crash usage documentation self-contained
| within the utility itself.
Man pages are another good and longstanding UNIX/Linux tradition.
Thanks for the lecture. I understand PAGER, and what man pages are as
I worked solely in the UNIX world since 1981 until I was forced into
the Linux domain... ;-)
At a minimum, the man page should say that it is incomplete and that
the definitive documentation is the help command. It should also have
a FILES section to point out ~/.crashrc.
Nobody's complained until you did -- please send a patch with what you'd
like to see.
BTW, I tried
set edit emacs
and got
set: cannot change editing mode during runtime
I don't think that it would be hard to fix this:
- in cmdline.c:readline_init, change all calls to rl_bind_key to be
calls to rl_bind_key_in_map using the vi_movement_keymap keymap.
This way the emacs map won't get damaged.
Move these binding commands out of the "if" -- they need to be
executed unconditionally.
- each time where you would print the error message "cannot change
editing mode...", just do change it (i.e. change rl_editing_mode and
pc->editing_mode).
Is there a reason to have a pc->editing_mode? Could rl_editing_mode
suffice?
Note: I have not tested this and I've never programmed any readline
calls, so I might well be missing something.
It's been way too long, I'm sure I don't remember. If you've
not figured it out by now, I'm not an emacs user...
When you've tested it out, please send us a patch.
Thanks,
Dave
11:17 p.m.
| From: Dave Anderson <anderson(a)redhat.com>
| D. Hugh Redelmeier wrote:
| > ==> Worse: while it is awaiting my RETURN, it is burning 100% of the CPU!
| >
| > Here is what "ps laxgwf" says about the crash process and its child.
| >
| > F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
| > 4 0 4426 4406 25 0 416812 332764 - R+ pts/5 80:36
| > | | \_ crash --readnow
| > /usr/lib/debug/lib/modules/2.6.21-1.3228.fc7/vmlinux
| > /var/crash/2007-07-02-13:42/vmcore
| > 0 0 4989 4426 18 0 73976 740 - S+ pts/5 0:00
| > | | \_ /usr/bin/less -E -X -Ps -- MORE --
| > forward\: <SPACE>, <ENTER> or j backward\: b or k quit\: q
| >
| > strace of the crash process shows an infinite sequence of:
| > wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
| > wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
| > wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
| > wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
| >
| > This is very wasteful.
| >
| > There are other ways to get into this state. Other places less is
| > being used and is waiting. Probably wherever less is used even if it
| > isn't waiting.
| >
| > I just tested: this problem exists when using a normal xterm.
|
| Yeah, I have seen this on occasions, but I have never been able
| to reproduce it on demand. There was a patch suggestion a while ago,
| but I deferred it until I could reliably reproduce it for testing
| before taking it in.
I've put gdb on the case. The CPU burning that I'm currently experiencing is
in cmdline.c:restore_sanity. The actuall code in question is:
while (!waitpid(pc->stdpipe_pid, &waitstatus, WNOHANG))
;
That sure looks like a busy-wait.
If you execute this code, you should get a busy-wait too.
If you replaced WNOHANG with 0, I think that the wait would have the
same result but not be busy. You would then want to loop in the case
where waitpid returns a -1 with errno == EINTR.
Here's what I'd try (UNTESTED!):
do ; while (waitpid(pc->stdpipe_pid, &waitstatus, 0) == -1 && errno ==
EINTR);
All the uses of WNOHANG in that function look suspicious.
8:48 a.m.
D. Hugh Redelmeier wrote:
| From: Dave Anderson <anderson(a)redhat.com>
| D. Hugh Redelmeier wrote:
| > ==> Worse: while it is awaiting my RETURN, it is burning 100% of the CPU!
| >
| > Here is what "ps laxgwf" says about the crash process and its child.
| >
| > F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
| > 4 0 4426 4406 25 0 416812 332764 - R+ pts/5 80:36
| > | | \_ crash --readnow
| > /usr/lib/debug/lib/modules/2.6.21-1.3228.fc7/vmlinux
| > /var/crash/2007-07-02-13:42/vmcore
| > 0 0 4989 4426 18 0 73976 740 - S+ pts/5 0:00
| > | | \_ /usr/bin/less -E -X -Ps -- MORE --
| > forward\: <SPACE>, <ENTER> or j backward\: b or k quit\: q
| >
| > strace of the crash process shows an infinite sequence of:
| > wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
| > wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
| > wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
| > wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
| >
| > This is very wasteful.
| >
| > There are other ways to get into this state. Other places less is
| > being used and is waiting. Probably wherever less is used even if it
| > isn't waiting.
| >
| > I just tested: this problem exists when using a normal xterm.
|
Again, what exactly do you do to reproduce it? I just cannot get the 100%
cpu-time waiting on the "less" sub-shell.
| Yeah, I have seen this on occasions, but I have never been able
| to reproduce it on demand. There was a patch suggestion a while ago,
| but I deferred it until I could reliably reproduce it for testing
| before taking it in.
I've put gdb on the case. The CPU burning that I'm currently experiencing is
in cmdline.c:restore_sanity. The actuall code in question is:
while (!waitpid(pc->stdpipe_pid, &waitstatus, WNOHANG))
;
That sure looks like a busy-wait.
If you execute this code, you should get a busy-wait too.
If you replaced WNOHANG with 0, I think that the wait would have the
same result but not be busy. You would then want to loop in the case
where waitpid returns a -1 with errno == EINTR.
Here's what I'd try (UNTESTED!):
do ; while (waitpid(pc->stdpipe_pid, &waitstatus, 0) == -1 && errno ==
EINTR);
All the uses of WNOHANG in that function look suspicious.
I understand. I also remember that the WNOHANG's were originally added
there on purpose because of hangs I was seeing. But that's not to say
it's the best way of doing things.
As I mentioned before, there was a patch posted by someone (as I recall
who preferred using gdb and gdb scripts with kdump vmcores), but going
back a year and a half into the archives, I can't find it.
Anyway, I'm going to have to be able to reproduce it and test any
changes thoroughly before potentially re-introducing the hangs I
used to see.
Thanks,
Dave
11:54 a.m.
On Thu, 5 Jul 2007, Dave Anderson wrote:
| From: Dave Anderson <anderson(a)redhat.com>
| D. Hugh Redelmeier wrote:
| > | From: Dave Anderson <anderson(a)redhat.com>
| >
| > | D. Hugh Redelmeier wrote:
| >
| > | > ==> Worse: while it is awaiting my RETURN, it is burning 100% of the
| > | > CPU!
| Again, what exactly do you do to reproduce it? I just cannot get the 100%
| cpu-time waiting on the "less" sub-shell.
The simplest example, in a 24-line xterm:
$ su
# crash
crash> help set
(I think that he su is necessary because crash is examining the live
kernel.)
This behaviour comes up whenever crash is using more for more than a page.
Except "crash --help" which seems to be different.
This machine is an Athlon X2 running an up-to-date x86_64 Fedora 7.
Mind you, only one core is enabled (because of a kernel bug that is
the motivation for using crash).
The CPU goes to 100%. I presume that most of it is in the kernel,
handling the waitpid.
This seems really easy for me to reproduce. What happens when you try
this? In what environment?
| Anyway, I'm going to have to be able to reproduce it and test any
| changes thoroughly before potentially re-introducing the hangs I
| used to see.
Sure. And my suggestion was not tested even by me. It was only part
of an argument showing that the current code is wrong.
If you have a version of crash waiting for the pager to finish (as in my
example), put a gdb on it to find out just where in crash it is
waiting. (I've told you where mine is waiting.)
I suspect that your crash would not be in a waitpid loop because that
would be a busy wait and you say you don't see a busy wait.
1:25 p.m.
D. Hugh Redelmeier wrote:
On Thu, 5 Jul 2007, Dave Anderson wrote:
| From: Dave Anderson <anderson(a)redhat.com>
| D. Hugh Redelmeier wrote:
| > | From: Dave Anderson <anderson(a)redhat.com>
| >
| > | D. Hugh Redelmeier wrote:
| >
| > | > ==> Worse: while it is awaiting my RETURN, it is burning 100% of the
| > | > CPU!
| Again, what exactly do you do to reproduce it? I just cannot get the 100%
| cpu-time waiting on the "less" sub-shell.
The simplest example, in a 24-line xterm:
$ su
# crash
crash> help set
(I think that he su is necessary because crash is examining the live
kernel.)
This behaviour comes up whenever crash is using more for more than a page.
Except "crash --help" which seems to be different.
Interesting, yeah, I can see it with "help set", although not necessarily
with most other help commands that use more than a page. Strange...
This machine is an Athlon X2 running an up-to-date x86_64 Fedora 7.
Mind you, only one core is enabled (because of a kernel bug that is
the motivation for using crash).
The CPU goes to 100%. I presume that most of it is in the kernel,
handling the waitpid.
Right -- it's essentially becomes an alternate idle loop for that cpu...
Harmless, but annoying.
This seems really easy for me to reproduce. What happens when you
try
this? In what environment?
| Anyway, I'm going to have to be able to reproduce it and test any
| changes thoroughly before potentially re-introducing the hangs I
| used to see.
Sure. And my suggestion was not tested even by me. It was only part
of an argument showing that the current code is wrong.
If you have a version of crash waiting for the pager to finish (as in my
example), put a gdb on it to find out just where in crash it is
waiting. (I've told you where mine is waiting.)
I suspect that your crash would not be in a waitpid loop because that
would be a busy wait and you say you don't see a busy wait.
I wasn't able to reproduce the 99% cpu usage (until now).
But yes, it's in the same place in restore_sanity() that
you were seeing.
Dave
1:45 p.m.
D. Hugh Redelmeier wrote:
> | Anyway, I'm going to have to be able to reproduce it and
test any
> | changes thoroughly before potentially re-introducing the hangs I
> | used to see.
>
> Sure. And my suggestion was not tested even by me. It was only part
> of an argument showing that the current code is wrong.
Yeah, but I'm still paranoid about re-introducing the hang I used
to see.
I think I'll just put a "stall(1000);" call after each waitpid().
Works for me...
Dave
3:22 p.m.
| From: Dave Anderson <anderson(a)redhat.com>
| Yeah, but I'm still paranoid about re-introducing the hang I used
| to see.
|
| I think I'll just put a "stall(1000);" call after each waitpid().
| Works for me...
I take that as a challenge. I think that I've eliminated this
busy-wait and simplified the code. I admit that wait_for_children is
slightly more complicated.
In light testing this worked fine. I'd really like to find out how
this is going to hang. I promise to attempt to debug any hang that I
can duplicate.
===================================================================
RCS file: RCS/cmdline.c,v
retrieving revision 1.1
diff -u -r1.1 cmdline.c
--- cmdline.c 2007/07/10 19:30:01 1.1
+++ cmdline.c 2007/07/10 20:16:57
@@ -31,6 +31,7 @@
static void set_my_tty(void);
static char *signame(int);
static int setup_stdpipe(void);
+static void wait_for_child(pid_t *);
static void wait_for_children(ulong);
#define ZOMBIES_ONLY (1)
#define ALL_CHILDREN (2)
@@ -878,25 +879,15 @@
if (pc->stdpipe) {
close(fileno(pc->stdpipe));
pc->stdpipe = NULL;
- if (pc->stdpipe_pid && PID_ALIVE(pc->stdpipe_pid)) {
- while (!waitpid(pc->stdpipe_pid, &waitstatus, WNOHANG))
- ;
- }
- pc->stdpipe_pid = 0;
+ wait_for_child(&pc->stdpipe_pid);
}
if (pc->pipe) {
close(fileno(pc->pipe));
pc->pipe = NULL;
console("wait for redirect %d->%d to finish...\n",
pc->pipe_shell_pid, pc->pipe_pid);
- if (pc->pipe_pid)
- while (PID_ALIVE(pc->pipe_pid))
- waitpid(pc->pipe_pid, &waitstatus, WNOHANG);
- if (pc->pipe_shell_pid)
- while (PID_ALIVE(pc->pipe_shell_pid))
- waitpid(pc->pipe_shell_pid,
- &waitstatus, WNOHANG);
- pc->pipe_pid = 0;
+ wait_for_child(&pc->pipe_pid);
+ wait_for_child(&pc->pipe_shell_pid);
}
if (pc->ifile_pipe) {
fflush(pc->ifile_pipe);
@@ -907,12 +898,8 @@
(FROM_INPUT_FILE|REDIRECT_TO_PIPE|REDIRECT_PID_KNOWN))) {
console("wait for redirect %d->%d to finish...\n",
pc->pipe_shell_pid, pc->pipe_pid);
- while (PID_ALIVE(pc->pipe_pid))
- waitpid(pc->pipe_pid, &waitstatus, WNOHANG);
- if (pc->pipe_shell_pid)
- while (PID_ALIVE(pc->pipe_shell_pid))
- waitpid(pc->pipe_shell_pid,
- &waitstatus, WNOHANG);
+ wait_for_child(&pc->pipe_pid);
+ wait_for_child(&pc->pipe_shell_pid);
if (pc->redirect & (REDIRECT_MULTI_PIPE))
wait_for_children(ALL_CHILDREN);
}
@@ -1967,7 +1954,7 @@
if (CRASHDEBUG(2))
console("pipe: %lx\n", pc->stdpipe);
- return TRUE;;
+ return TRUE;
} else {
close(pc->pipefd[1]); /* child closes write end */
@@ -1998,13 +1985,26 @@
}
}
+static void
+wait_for_child(pid_t *chp)
+{
+ if (*chp != 0)
+ {
+ int waitstatus;
+
+ do ; while (waitpid(*chp, &waitstatus, 0) == -1 && errno == EINTR);
+ *chp = 0;
+ }
+}
+
static void
wait_for_children(ulong waitflag)
{
- int status, pid;
-
while (TRUE) {
- switch (pid = waitpid(-1, &status, WNOHANG))
+ int status;
+ pid_t pid = waitpid(-1, &status, waitflag==ZOMBIES_ONLY? WNOHANG : 0);
+
+ switch (pid)
{
case 0:
if (CRASHDEBUG(2))
@@ -2014,6 +2014,8 @@
break;
case -1:
+ if (errno == EINTR)
+ continue;
if (CRASHDEBUG(2))
console("wait_for_children: no children alive\n");
return;
================ end ================
3:37 p.m.
D. Hugh Redelmeier wrote:
| From: Dave Anderson <anderson(a)redhat.com>
| Yeah, but I'm still paranoid about re-introducing the hang I used
| to see.
|
| I think I'll just put a "stall(1000);" call after each waitpid().
| Works for me...
I take that as a challenge. I think that I've eliminated this
busy-wait and simplified the code. I admit that wait_for_children is
slightly more complicated.
In light testing this worked fine. I'd really like to find out how
this is going to hang. I promise to attempt to debug any hang that I
can duplicate.
I didn't mean it as a challenge. I appreciate the effort, but
at this point I'm really not particularly interested in re-working
this area, especially since it can be so simply avoided with a stall.
Thanks,
Dave
===================================================================
RCS file: RCS/cmdline.c,v
retrieving revision 1.1
diff -u -r1.1 cmdline.c
--- cmdline.c 2007/07/10 19:30:01 1.1
+++ cmdline.c 2007/07/10 20:16:57
@@ -31,6 +31,7 @@
static void set_my_tty(void);
static char *signame(int);
static int setup_stdpipe(void);
+static void wait_for_child(pid_t *);
static void wait_for_children(ulong);
#define ZOMBIES_ONLY (1)
#define ALL_CHILDREN (2)
@@ -878,25 +879,15 @@
if (pc->stdpipe) {
close(fileno(pc->stdpipe));
pc->stdpipe = NULL;
- if (pc->stdpipe_pid && PID_ALIVE(pc->stdpipe_pid)) {
- while (!waitpid(pc->stdpipe_pid, &waitstatus, WNOHANG))
- ;
- }
- pc->stdpipe_pid = 0;
+ wait_for_child(&pc->stdpipe_pid);
}
if (pc->pipe) {
close(fileno(pc->pipe));
pc->pipe = NULL;
console("wait for redirect %d->%d to finish...\n",
pc->pipe_shell_pid, pc->pipe_pid);
- if (pc->pipe_pid)
- while (PID_ALIVE(pc->pipe_pid))
- waitpid(pc->pipe_pid, &waitstatus, WNOHANG);
- if (pc->pipe_shell_pid)
- while (PID_ALIVE(pc->pipe_shell_pid))
- waitpid(pc->pipe_shell_pid,
- &waitstatus, WNOHANG);
- pc->pipe_pid = 0;
+ wait_for_child(&pc->pipe_pid);
+ wait_for_child(&pc->pipe_shell_pid);
}
if (pc->ifile_pipe) {
fflush(pc->ifile_pipe);
@@ -907,12 +898,8 @@
(FROM_INPUT_FILE|REDIRECT_TO_PIPE|REDIRECT_PID_KNOWN))) {
console("wait for redirect %d->%d to finish...\n",
pc->pipe_shell_pid, pc->pipe_pid);
- while (PID_ALIVE(pc->pipe_pid))
- waitpid(pc->pipe_pid, &waitstatus, WNOHANG);
- if (pc->pipe_shell_pid)
- while (PID_ALIVE(pc->pipe_shell_pid))
- waitpid(pc->pipe_shell_pid,
- &waitstatus, WNOHANG);
+ wait_for_child(&pc->pipe_pid);
+ wait_for_child(&pc->pipe_shell_pid);
if (pc->redirect & (REDIRECT_MULTI_PIPE))
wait_for_children(ALL_CHILDREN);
}
@@ -1967,7 +1954,7 @@
if (CRASHDEBUG(2))
console("pipe: %lx\n", pc->stdpipe);
- return TRUE;;
+ return TRUE;
} else {
close(pc->pipefd[1]); /* child closes write end */
@@ -1998,13 +1985,26 @@
}
}
+static void
+wait_for_child(pid_t *chp)
+{
+ if (*chp != 0)
+ {
+ int waitstatus;
+
+ do ; while (waitpid(*chp, &waitstatus, 0) == -1 && errno == EINTR);
+ *chp = 0;
+ }
+}
+
static void
wait_for_children(ulong waitflag)
{
- int status, pid;
-
while (TRUE) {
- switch (pid = waitpid(-1, &status, WNOHANG))
+ int status;
+ pid_t pid = waitpid(-1, &status, waitflag==ZOMBIES_ONLY? WNOHANG : 0);
+
+ switch (pid)
{
case 0:
if (CRASHDEBUG(2))
@@ -2014,6 +2014,8 @@
break;
case -1:
+ if (errno == EINTR)
+ continue;
if (CRASHDEBUG(2))
console("wait_for_children: no children alive\n");
return;
================ end ================
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
9:39 a.m.
On Tue, 3 Jul 2007, D. Hugh Redelmeier wrote:
==> It does not say in what way the terminal is not fully
functional. That seems like a bug.
Well, the issue is that the emacs terminal emulator does not fully
support the [n]curses escape sequences needed to position the cursor
for your pager (e.g. less). An amusing thing is that the emacs
terminal emulation isn't powerful enough to run a recursive emacs: try
"M-x shell" and then run "emacs -nw" at the shell prompt. You'll
get
the same message.
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
9:49 a.m.
Chip Coldwell wrote:
On Tue, 3 Jul 2007, D. Hugh Redelmeier wrote:
>==> It does not say in what way the terminal is not fully
>functional. That seems like a bug.
Well, the issue is that the emacs terminal emulator does not fully
support the [n]curses escape sequences needed to position the cursor
for your pager (e.g. less). An amusing thing is that the emacs
terminal emulation isn't powerful enough to run a recursive emacs: try
"M-x shell" and then run "emacs -nw" at the shell prompt. You'll
get
the same message.
Chip
I would think the easiest way to deal with this issue would be
to not allow crash to use "less" if the TERM type is "vanilla".
And if it is vanilla, fall back to using "more", which is what
is done now if "less" doesn't exist on the host system.
Dave
1:22 p.m.
New subject: less(1) TERM requirements; man page update [was Re: crash CPU bound waiting for user response]
| From: Dave Anderson <anderson(a)redhat.com>
|
| Chip Coldwell wrote:
| > On Tue, 3 Jul 2007, D. Hugh Redelmeier wrote:
| > >==> It does not say in what way the terminal is not fully
| > >functional. That seems like a bug.
| > Well, the issue is that the emacs terminal emulator does not fully
| > support the [n]curses escape sequences needed to position the cursor
| > for your pager (e.g. less).
The whole point of termcap/terminfo is to tame the whacky world of
terminal diversity. There is nothing "wrong" with a terminal that
does not have features needed by less(1).
In fact less(1) would almost never be useful within an emacs/jove
terminal window even if it did work: emacs/jove has more appropriate
facilities built in.
The same goes for readline within an emacs/jove terminal.
| I would think the easiest way to deal with this issue would be
| to not allow crash to use "less" if the TERM type is "vanilla".
| And if it is vanilla, fall back to using "more", which is what
| is done now if "less" doesn't exist on the host system.
The name of an entry in termcap/terminfo is not supposed to be
material. One is supposed to make decisions based on the declared
attributes.
Unfortunately, less(1) does not document what capabilities it
requires: neither in the man page nor in the warning messages. I
don't care enough to read the source code, and in any case anything
learned there would be provisional since it isn't part of the
"contract".
Getting crash entagled with termcap/terminfo on behalf of less(1) is
probably a bad idea. Mind you, I expect crash already is involved
with termca/terminfo through using readline (I've not checked).
I suspect that the current situation is probably better than trying to
fix it. A simple "set scroll off" cures the problem for a run.
Making this clear in documentation would be a modest improvement.
Is there a simple way of turning off readline? To make the problem
harder: I want to do it some times (i.e. when running crash under jove)
but not at others (i.e. when running crash directly in an xterm).
Here is a proposed patch to the man page.
===================================================================
RCS file: RCS/crash.8,v
retrieving revision 1.1
diff -u -r1.1 crash.8
--- crash.8 2007/07/09 15:41:55 1.1
+++ crash.8 2007/07/09 18:16:56
@@ -5,7 +5,7 @@
.TH CRASH 8
.SH NAME
crash \- Analyze Linux crash data or a live system
-.SH SYNAPSIS
+.SH SYNOPSIS
.B crash
[
.B -h
@@ -44,7 +44,7 @@
core dump has been created by the Red Hat
.I netdump
facility. It is loosely based on the SVR4 UNIX crash
-command, but has been signficantly enhanced
+command, but has been significantly enhanced
by completely merging it with the
.I gdb
debugger. The marriage of the two effectively combines the
@@ -207,11 +207,11 @@
.I dis
disassembles memory, either entire kernel functions, from a
location for a specified number of instructions, or from the start of a
-fuction up to a specified memory location.
+function up to a specified memory location.
.TP
.I eval
evalues an expression or numeric type and displays the result
-in hexidecimal, decimal, octal and binary.
+in hexadecimal, decimal, octal and binary.
.TP
.I exit
causes
@@ -230,7 +230,7 @@
in the system.
.TP
.I fuser
-displays the tasks using the specifed file or socket.
+displays the tasks using the specified file or socket.
.TP
.I gdb
passes its argument to the underlying
@@ -274,7 +274,7 @@
display various network related data.
.TP
.I p
-passes its argumnts to the
+passes its arguments to the
.I gdb
"print" command for evaluation and display.
.TP
@@ -361,11 +361,54 @@
.I wr
modifies the contents of memory. When writing to memory on
a live system, this command should obviously be used with great care.
+.SH FILES
+.TP
+.I ~/.crashrc
+initialization commands
+.SH ENVIRONMENT
+.TP
+.B EDITOR
+Command input is read using
+.BR readline(3).
+If
+.B EDITOR
+is set to
+.I emacs
+or
+.I vi
+then suitable keybindings are used. This can be overridden by ``\fBset\ vi\fP''
+or ``\fBset\ emacs\fP'' commands, but only in
+.IR ~/.crashrc .
+.SH NOTES
+.PP
+If
+.B crash
+does not work, look for a newer version: kernel evolution frequently makes
+.B crash
+updates necessary.
+.PP
+The command ``\fBset\ scroll\ off\fP'' will cause output to be sent directly to
+the terminal rather than through a paging program. This is useful,
+for example, if you are running
+.B crash
+in a window of
+.BR emacs .
.SH AUTHOR
Dave Anderson <anderson(a)redhat.com> wrote
.B Crash
.TP
Jay Fenlason <fenlason(a)redhat.com> wrote this man page.
.SH "SEE ALSO"
-netdump(8)
-gdb(1)
+.PP
+The
+.B help
+command within
+.B crash
+provides more complete and accurate documentation than this manpage.
+.TP
+.I http://people.redhat.com/anderson/
+The home page of
+.IR crash .
+.PP
+.BR netdump (8),
+.BR gdb (1)
================ end ================
9:49 a.m.
New subject: less(1) TERM requirements; man page update [was Re: crash CPU bound waiting for user response]
D. Hugh Redelmeier wrote:
| From: Dave Anderson <anderson(a)redhat.com>
|
| Chip Coldwell wrote:
| > On Tue, 3 Jul 2007, D. Hugh Redelmeier wrote:
| > >==> It does not say in what way the terminal is not fully
| > >functional. That seems like a bug.
| > Well, the issue is that the emacs terminal emulator does not fully
| > support the [n]curses escape sequences needed to position the cursor
| > for your pager (e.g. less).
The whole point of termcap/terminfo is to tame the whacky world of
terminal diversity. There is nothing "wrong" with a terminal that
does not have features needed by less(1).
In fact less(1) would almost never be useful within an emacs/jove
terminal window even if it did work: emacs/jove has more appropriate
facilities built in.
The same goes for readline within an emacs/jove terminal.
| I would think the easiest way to deal with this issue would be
| to not allow crash to use "less" if the TERM type is "vanilla".
| And if it is vanilla, fall back to using "more", which is what
| is done now if "less" doesn't exist on the host system.
The name of an entry in termcap/terminfo is not supposed to be
material. One is supposed to make decisions based on the declared
attributes.
Unfortunately, less(1) does not document what capabilities it
requires: neither in the man page nor in the warning messages. I
don't care enough to read the source code, and in any case anything
learned there would be provisional since it isn't part of the
"contract".
Getting crash entagled with termcap/terminfo on behalf of less(1) is
probably a bad idea. Mind you, I expect crash already is involved
with termca/terminfo through using readline (I've not checked).
I suspect that the current situation is probably better than trying to
fix it. A simple "set scroll off" cures the problem for a run.
Making this clear in documentation would be a modest improvement.
Fine, but at a minimum I propose the addition of a "--more" command
line argument to force its use instead of "less". With that in place,
I've verified that crash scrolling works fine using the "vanilla"
TERM type, and I presume that using "more" for scrolling would suffice
within the emacs/jove/vanilla environment as well?
Is there a simple way of turning off readline? To make the problem
harder: I want to do it some times (i.e. when running crash under jove)
but not at others (i.e. when running crash directly in an xterm).
No.
Here is a proposed patch to the man page.
OK, thanks,
Dave
===================================================================
RCS file: RCS/crash.8,v
retrieving revision 1.1
diff -u -r1.1 crash.8
--- crash.8 2007/07/09 15:41:55 1.1
+++ crash.8 2007/07/09 18:16:56
@@ -5,7 +5,7 @@
.TH CRASH 8
.SH NAME
crash \- Analyze Linux crash data or a live system
-.SH SYNAPSIS
+.SH SYNOPSIS
.B crash
[
.B -h
@@ -44,7 +44,7 @@
core dump has been created by the Red Hat
.I netdump
facility. It is loosely based on the SVR4 UNIX crash
-command, but has been signficantly enhanced
+command, but has been significantly enhanced
by completely merging it with the
.I gdb
debugger. The marriage of the two effectively combines the
@@ -207,11 +207,11 @@
.I dis
disassembles memory, either entire kernel functions, from a
location for a specified number of instructions, or from the start of a
-fuction up to a specified memory location.
+function up to a specified memory location.
.TP
.I eval
evalues an expression or numeric type and displays the result
-in hexidecimal, decimal, octal and binary.
+in hexadecimal, decimal, octal and binary.
.TP
.I exit
causes
@@ -230,7 +230,7 @@
in the system.
.TP
.I fuser
-displays the tasks using the specifed file or socket.
+displays the tasks using the specified file or socket.
.TP
.I gdb
passes its argument to the underlying
@@ -274,7 +274,7 @@
display various network related data.
.TP
.I p
-passes its argumnts to the
+passes its arguments to the
.I gdb
"print" command for evaluation and display.
.TP
@@ -361,11 +361,54 @@
.I wr
modifies the contents of memory. When writing to memory on
a live system, this command should obviously be used with great care.
+.SH FILES
+.TP
+.I ~/.crashrc
+initialization commands
+.SH ENVIRONMENT
+.TP
+.B EDITOR
+Command input is read using
+.BR readline(3).
+If
+.B EDITOR
+is set to
+.I emacs
+or
+.I vi
+then suitable keybindings are used. This can be overridden by ``\fBset\
vi\fP''
+or ``\fBset\ emacs\fP'' commands, but only in
+.IR ~/.crashrc .
+.SH NOTES
+.PP
+If
+.B crash
+does not work, look for a newer version: kernel evolution frequently makes
+.B crash
+updates necessary.
+.PP
+The command ``\fBset\ scroll\ off\fP'' will cause output to be sent directly to
+the terminal rather than through a paging program. This is useful,
+for example, if you are running
+.B crash
+in a window of
+.BR emacs .
.SH AUTHOR
Dave Anderson <anderson(a)redhat.com> wrote
.B Crash
.TP
Jay Fenlason <fenlason(a)redhat.com> wrote this man page.
.SH "SEE ALSO"
-netdump(8)
-gdb(1)
+.PP
+The
+.B help
+command within
+.B crash
+provides more complete and accurate documentation than this manpage.
+.TP
+.I http://people.redhat.com/anderson/
+The home page of
+.IR crash .
+.PP
+.BR netdump (8),
+.BR gdb (1)
================ end ================
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
11:30 a.m.
New subject: less(1) TERM requirements; man page update [was Re: crash CPU bound waiting for user response]
| From: Dave Anderson <anderson(a)redhat.com>
| Fine, but at a minimum I propose the addition of a "--more" command
| line argument to force its use instead of "less". With that in place,
| I've verified that crash scrolling works fine using the "vanilla"
| TERM type, and I presume that using "more" for scrolling would suffice
| within the emacs/jove/vanilla environment as well?
Would it not be better to use $PAGER to make this choice?
- it is already a convention
- it doesn't add to the tangle of options
- it allows even more control (eg. PAGER=cat)
1:10 p.m.
New subject: less(1) TERM requirements; man page update [was Re: crash CPU bound waiting for user response]
D. Hugh Redelmeier wrote:
| From: Dave Anderson <anderson(a)redhat.com>
| Fine, but at a minimum I propose the addition of a "--more" command
| line argument to force its use instead of "less". With that in place,
| I've verified that crash scrolling works fine using the "vanilla"
| TERM type, and I presume that using "more" for scrolling would suffice
| within the emacs/jove/vanilla environment as well?
Would it not be better to use $PAGER to make this choice?
- it is already a convention
- it doesn't add to the tangle of options
- it allows even more control (eg. PAGER=cat)
I guess because $PAGER is typically not set, and PAGER=cat is
pretty much the same as "set scroll off".
3:39 a.m.
New subject: less(1) TERM requirements; man page update
Dave Anderson <anderson(a)redhat.com> writes:
D. Hugh Redelmeier wrote:
> | From: Dave Anderson <anderson(a)redhat.com>
> | Fine, but at a minimum I propose the addition of a "--more" command
> | line argument to force its use instead of "less". With that in place,
> | I've verified that crash scrolling works fine using the "vanilla"
> | TERM type, and I presume that using "more" for scrolling would suffice
> | within the emacs/jove/vanilla environment as well?
> Would it not be better to use $PAGER to make this choice?
> - it is already a convention
> - it doesn't add to the tangle of options
> - it allows even more control (eg. PAGER=cat)
>
I guess because $PAGER is typically not set, and PAGER=cat is
pretty much the same as "set scroll off".
I don't mind when a tool has its own idiosyncratic default for unset
$PAGER, but I do mind when it ignores $PAGER in favour of its own
idiosyncratic pager selection mechanism.
7:41 a.m.
New subject: less(1) TERM requirements; man page update
Markus Armbruster wrote:
Dave Anderson <anderson(a)redhat.com> writes:
>D. Hugh Redelmeier wrote:
>
>>| From: Dave Anderson <anderson(a)redhat.com>
>>| Fine, but at a minimum I propose the addition of a "--more" command
>>| line argument to force its use instead of "less". With that in
place,
>>| I've verified that crash scrolling works fine using the "vanilla"
>>| TERM type, and I presume that using "more" for scrolling would
suffice
>>| within the emacs/jove/vanilla environment as well?
>>Would it not be better to use $PAGER to make this choice?
>>- it is already a convention
>>- it doesn't add to the tangle of options
>>- it allows even more control (eg. PAGER=cat)
>>
>
>I guess because $PAGER is typically not set, and PAGER=cat is
>pretty much the same as "set scroll off".
I don't mind when a tool has its own idiosyncratic default for unset
$PAGER, but I do mind when it ignores $PAGER in favour of its own
idiosyncratic pager selection mechanism.
Ok -- but I'm still curious as to what other pager would be
preferable to less, more, or none?
Dave
10:28 a.m.
New subject: less(1) TERM requirements; man page update
Dave Anderson <anderson(a)redhat.com> writes:
Markus Armbruster wrote:
> Dave Anderson <anderson(a)redhat.com> writes:
>
>>D. Hugh Redelmeier wrote:
>>
>>>| From: Dave Anderson <anderson(a)redhat.com>
>>>| Fine, but at a minimum I propose the addition of a "--more"
command
>>>| line argument to force its use instead of "less". With that in
place,
>>>| I've verified that crash scrolling works fine using the
"vanilla"
>>>| TERM type, and I presume that using "more" for scrolling would
suffice
>>>| within the emacs/jove/vanilla environment as well?
>>>Would it not be better to use $PAGER to make this choice?
>>>- it is already a convention
>>>- it doesn't add to the tangle of options
>>>- it allows even more control (eg. PAGER=cat)
>>>
>>
>>I guess because $PAGER is typically not set, and PAGER=cat is
>>pretty much the same as "set scroll off".
> I don't mind when a tool has its own idiosyncratic default for unset
> $PAGER, but I do mind when it ignores $PAGER in favour of its own
> idiosyncratic pager selection mechanism.
>
Ok -- but I'm still curious as to what other pager would be
preferable to less, more, or none?
Dave
Personally, I'm happy with less and none, but I very much prefer to
control it through $PAGER, because that's the common way to do it.
A more philosophical argument is that it's simply not ours to decide
what pagers users are allowed use. And we don't have to. $PAGER is
no less usable than the alternatives, yet provides all the choice
users could want.
10:34 a.m.
New subject: less(1) TERM requirements; man page update
Dave Anderson wrote:
Markus Armbruster wrote:
> Dave Anderson <anderson(a)redhat.com> writes:
>
>
>> D. Hugh Redelmeier wrote:
>>
>>> | From: Dave Anderson <anderson(a)redhat.com>
>>> | Fine, but at a minimum I propose the addition of a "--more"
command
>>> | line argument to force its use instead of "less". With that in
>>> place,
>>> | I've verified that crash scrolling works fine using the
"vanilla"
>>> | TERM type, and I presume that using "more" for scrolling would
>>> suffice
>>> | within the emacs/jove/vanilla environment as well?
>>> Would it not be better to use $PAGER to make this choice?
>>> - it is already a convention
>>> - it doesn't add to the tangle of options
>>> - it allows even more control (eg. PAGER=cat)
>>>
>>
>> I guess because $PAGER is typically not set, and PAGER=cat is
>> pretty much the same as "set scroll off".
>
>
>
> I don't mind when a tool has its own idiosyncratic default for unset
> $PAGER, but I do mind when it ignores $PAGER in favour of its own
> idiosyncratic pager selection mechanism.
>
Ok -- but I'm still curious as to what other pager would be
preferable to less, more, or none?
Dave
I worked up a test version of crash that defaults to the use
of the PAGER variable (instead of less -E -X with a prompt).
I would presume that setting PAGER=/usr/bin/less might be
a typical practice. But when doing so, less (with no arguments)
always requires user interaction to continue, even if the output
is less than a page size in length, and what's worse, it then
clears the output screen. That type of behaviour is unacceptable,
and is exactly the type of issue that I was worrying about.
That being said, I will go along with the use of the PAGER
variable, but not by default. It's going to have to be
a .crashrc or command-line setting. I don't think that's
unreasonable -- certainly nobody's ever complained about it
in the past.
Idiosyncratically,
Dave
1:16 p.m.
New subject: less(1) TERM requirements; man page update [was Re: crash CPU bound waiting for user response]
On Mon, 9 Jul 2007, D. Hugh Redelmeier wrote:
| From: Dave Anderson <anderson(a)redhat.com>
|
| Chip Coldwell wrote:
| > On Tue, 3 Jul 2007, D. Hugh Redelmeier wrote:
| > >==> It does not say in what way the terminal is not fully
| > >functional. That seems like a bug.
| > Well, the issue is that the emacs terminal emulator does not fully
| > support the [n]curses escape sequences needed to position the cursor
| > for your pager (e.g. less).
The whole point of termcap/terminfo is to tame the whacky world of
terminal diversity. There is nothing "wrong" with a terminal that
does not have features needed by less(1).
Fair enough, but then this is a bug in less: it is refusing to run on
a terminal that has nothing "wrong" with it.
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
1:31 p.m.
New subject: less(1) TERM requirements; man page update [was Re: crash CPU bound waiting for user response]
Chip Coldwell wrote:
On Mon, 9 Jul 2007, D. Hugh Redelmeier wrote:
>| From: Dave Anderson <anderson(a)redhat.com>
>|
>| Chip Coldwell wrote:
>| > On Tue, 3 Jul 2007, D. Hugh Redelmeier wrote:
>
>| > >==> It does not say in what way the terminal is not fully
>| > >functional. That seems like a bug.
>
>| > Well, the issue is that the emacs terminal emulator does not fully
>| > support the [n]curses escape sequences needed to position the cursor
>| > for your pager (e.g. less).
>
>The whole point of termcap/terminfo is to tame the whacky world of
>terminal diversity. There is nothing "wrong" with a terminal that
>does not have features needed by less(1).
Fair enough, but then this is a bug in less: it is refusing to run on
a terminal that has nothing "wrong" with it.
Chip
There are a few terminal capability checks that "less" makes on the
termcap file, and if any of them are missing, it sets missing_cap,
and later on spews that message/forced-input-sequence -- for example:
sc_eol_clear = ltgetstr("ce", &sp);
if (sc_eol_clear == NULL || *sc_eol_clear == '\0')
{
missing_cap = 1;
sc_eol_clear = "";
}
sc_eos_clear = ltgetstr("cd", &sp);
if (below_mem && (sc_eos_clear == NULL || *sc_eos_clear ==
'\0'))
{
missing_cap = 1;
sc_eos_clear = "";
}
sc_clear = ltgetstr("cl", &sp);
if (sc_clear == NULL || *sc_clear == '\0')
{
missing_cap = 1;
sc_clear = "\n\n";
}
6347
days inactive
6356
days old
devel@lists.crash-utility.osci.io
24 comments
4 participants
participants (4)
-
Chip Coldwell -
D. Hugh Redelmeier -
Dave Anderson -
Markus Armbruster