Crash in tparam.c on OpenBSD

Crash in tparam.c on OpenBSD

[Casper Gripenberg]

Hi,

I'm running OBSD 3.3 with a recently compiled 
GNU Emacs 21.3.1 (i386-unknown-openbsd3.3, X toolkit, Xaw3d 
scroll bars). This is compiled straight from the original
emacs source:

 > ls 
 ... 20399831 Mar 19  2003 emacs-21.3.tar.gz

Emacs works fine, except if I happen to run emacs with
TERM set, but not TERMCAP set. This situation arises when
I run emacs with sudo, as sudo cleans out the TERMCAP
variable for security reasons (yeah I know..what 
security, when emacs is run as root..but that's beside
the point :)).

When I run without TERMCAP (manually unset TERMCAP or
through sudo) emacs will dump core when there is anything
it is about to highlite. I.e. if I do an i-search and
emacs finds a match then BOOM..instant core. 

If I set TERM to vt100 then it seems to work OK, but
for example TERM=linux or xterm-xfree86 and I get the
crash. When I gdb the core I see an abort() call being
made in tparam.c on line 298:

	    case 'D':		/* %D means weird Delta Data transformation.  */
	      argp[0] -= 2 * (tem % 16);
	      break;

	    default:
>	      abort ();
	    }
	}


The reason for the abort call is in the arguments to the
method tparam1:

(gdb) up
#1  0x86ec8 in fatal_error_signal (sig=6) at emacs.c:354
(gdb) up
#2  0x4015f004 in ?? ()
(gdb) up
#3  0x123bd5 in tparam1 (string=0x49b105 "\e[3%p1%dm", 
    outstring=0x5904c0 "\e[3", len=0, up=0x0, left=0x0, argp=0xcfbfc088)
    at tparam.c:298
(gdb) 

See the string "\e[3%p1%dm". This string conains %p, which
seems to me is not recognized by the parsing algorithm in
tparam1(). Hence the abort() call.

Now going up two levels we get here:

(gdb) up
#4  0x123709 in tparam (string=0x49b105 "\e[3%p1%dm", outstring=0x0, len=0, 
    arg0=6, arg1=2496000, arg2=1, arg3=8) at tparam.c:105
(gdb) up
#5  0x4b3a9 in turn_on_face (f=0x261600, face_id=11) at term.c:2107
(gdb) 

Which looks like this:

      if (fg >= 0 && TS_set_foreground)
	{
>	  p = tparam (TS_set_foreground, NULL, 0, (int) fg);
	  OUTPUT (p);
	  xfree (p);
	}

Where TS_set_foreground is the "\e[3%p1%dm" string.

I have no idea what all this means, or what the tparam method
does, or anything about TERMCAP...so I'm not going to draw
any conclusions :) But it makes me interested..where does
the %p come from, and why does emacs not know what to do
with it (should it know? probaby not?).

I put the termcap as well as the full 'gdb where' here:

http://zoidberg.homeip.net/emacsbug/

Regards,
  Casper

Re: Crash in tparam.c on OpenBSD

[Eli Zaretskii]

> Date: Fri, 2 Jan 2004 00:54:31 +0200
> From: Casper Gripenberg <casper.gripenberg@kotiportti.fi>
> 
> (gdb) up
> #4  0x123709 in tparam (string=0x49b105 "\e[3%p1%dm", outstring=0x0, len=0, 
>     arg0=6, arg1=2496000, arg2=1, arg3=8) at tparam.c:105
> (gdb) up
> #5  0x4b3a9 in turn_on_face (f=0x261600, face_id=11) at term.c:2107
> (gdb) 
> 
> Which looks like this:
> 
>       if (fg >= 0 && TS_set_foreground)
> 	{
> >	  p = tparam (TS_set_foreground, NULL, 0, (int) fg);
> 	  OUTPUT (p);
> 	  xfree (p);
> 	}
> 
> Where TS_set_foreground is the "\e[3%p1%dm" string.
> 
> I have no idea what all this means

It means that your Emacs was compiled for termcap, but the TERM entry
it gets fed is for terminfo, which is a newer method of specifying
terminal capabilities.  Emacs as compiled on your machine cannot
handle terminfo entries, so it barfs.

There should be an entry in the PROBLEMS file named "Emacs aborts
inside the function `tparam1'" which tells you more, including
suggested ways to solve this problem.

Re: Crash in tparam.c on OpenBSD

[Casper Gripenberg]

On Fri, Jan 02, 2004 at 11:25:27AM +0200, Eli Zaretskii wrote:
> It means that your Emacs was compiled for termcap, but the TERM entry
> it gets fed is for terminfo, which is a newer method of specifying
> terminal capabilities.  Emacs as compiled on your machine cannot
> handle terminfo entries, so it barfs.
> 
> There should be an entry in the PROBLEMS file named "Emacs aborts
> inside the function `tparam1'" which tells you more, including
> suggested ways to solve this problem.

Thanks. You are correct about the location of the problem.
After a bit of wrestling back and forth with the source, and 
not really getting anywhere, I figured out to check the newer 
OBSD 3.4 ports tree. In there was 21.3 patched the following 
way:

$OpenBSD: patch-src_s_openbsd_h,v 1.1 2003/07/05 00:27:08 naddy Exp $
--- src/s/openbsd.h.orig        Wed Mar 22 13:08:18 2000
+++ src/s/openbsd.h     Fri Jun 27 01:17:51 2003
@@ -9,3 +9,8 @@
 /*  David Mazieres <dm@reeducation-labor.lcs.mit.edu> says this
     is necessary.  Otherwise Emacs dumps core when run -nw.  */
 #undef LIBS_TERMCAP
+
+/*  Idea From the FreeBSD port. Seems to work well.
+    Needs testing and then commiting to emacs developers */
+#define TERMINFO
+#define LIBS_TERMCAP -lncurses

Looks simple enough. Close to what I tried, but I was probably
editing the wrong files (manually patching config.h). 

Anyway the 3.4 port works beautifully. I get color in the
terminal too, which I did not get before. Happy now :)

Regards,
  Casper

Re: Crash in tparam.c on OpenBSD

[Thomas Dickey]

Eli Zaretskii <eliz@elta.co.il> wrote:
>> Date: Fri, 2 Jan 2004 00:54:31 +0200
>> From: Casper Gripenberg <casper.gripenberg@kotiportti.fi>
>> 
>> (gdb) up
>> #4  0x123709 in tparam (string=0x49b105 "\e[3%p1%dm", outstring=0x0, len=0, 
>>     arg0=6, arg1=2496000, arg2=1, arg3=8) at tparam.c:105
>> (gdb) up
>> #5  0x4b3a9 in turn_on_face (f=0x261600, face_id=11) at term.c:2107
>> (gdb) 
>> 
>> Which looks like this:
>> 
>>       if (fg >= 0 && TS_set_foreground)
>> 	{
>> >	  p = tparam (TS_set_foreground, NULL, 0, (int) fg);
>> 	  OUTPUT (p);
>> 	  xfree (p);
>> 	}
>> 
>> Where TS_set_foreground is the "\e[3%p1%dm" string.
>> 
>> I have no idea what all this means

> It means that your Emacs was compiled for termcap, but the TERM entry
> it gets fed is for terminfo, which is a newer method of specifying
> terminal capabilities.  Emacs as compiled on your machine cannot
> handle terminfo entries, so it barfs.

> There should be an entry in the PROBLEMS file named "Emacs aborts
> inside the function `tparam1'" which tells you more, including
> suggested ways to solve this problem.

This appears to be a problem with emacs' configure script.  It shouldn't
have to compile-in most of the logic for tparam, since that can be done
with calls to the "real" tgoto.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Re: Crash in tparam.c on OpenBSD

[Eli Zaretskii]

> From: Thomas Dickey <dickey@saltmine.radix.net>
> Newsgroups: gnu.emacs.bug
> Date: 2 Jan 2004 11:01:04 GMT
> 
> This appears to be a problem with emacs' configure script.  It shouldn't
> have to compile-in most of the logic for tparam, since that can be done
> with calls to the "real" tgoto.

Sorry, I don't understand: there's no place in the Emacs configure
script where it references tparam.  So could you please elaborate?

FWIW, it looks like support for %pN was recently added to tparam.c in
the Emacs CVS, so this problem shouldn't happen anymore.

Re: Crash in tparam.c on OpenBSD

[Thomas Dickey]

Eli Zaretskii <eliz@elta.co.il> wrote:
>> From: Thomas Dickey <dickey@saltmine.radix.net>
>> Newsgroups: gnu.emacs.bug
>> Date: 2 Jan 2004 11:01:04 GMT
>> 
>> This appears to be a problem with emacs' configure script.  It shouldn't
>> have to compile-in most of the logic for tparam, since that can be done
>> with calls to the "real" tgoto.

> Sorry, I don't understand: there's no place in the Emacs configure
> script where it references tparam.  So could you please elaborate?

It's been several months since I looked (well, I _could_ download the
source again...).  What I recalled was that Emacs' tparam() is used in
a few places that could be directed to the underlying tgoto() function -
if that tgoto() is not supplied by Emacs.  That was essentially what I
reported before.

> FWIW, it looks like support for %pN was recently added to tparam.c in
> the Emacs CVS, so this problem shouldn't happen anymore.

I suppose so.  I'm not sure if it would handle the more complicated
expressions for color.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net