[twurgler@goodyear.com: Re: [twurgler@goodyear.com: Re: emacs 21.2 odd behavior in shell window]]

[Tom Wurgler <twurgler@goodyear.com>]

Here is the current state:

1) If I rename comint.elc to something else, which, when I try to use something
cominty, will force emacs to load the comint.el file instead, then all works as
it always did.  I believe this verifies that it runs interpreted and does not
run compiled.

2) I can't get gdb5.1 or 5.1.1 to work on ANY program.  It just hangs and does
nothing until I kill it.  I recompiled gdb on this 11.00 HP-UX and on a 10.20
machine and neither works at all.  I haven't figured this out yet.

Sorry.
tom




------- Start of forwarded message -------
Date: Fri, 5 Apr 2002 09:27:27 -0500 (EST)
From: Tom Wurgler <twurgler@goodyear.com>
To: rms@gnu.org
CC: twurgler@goodyear.com, twurgler@goodyear.com, bug-gnu-emacs@gnu.org
In-reply-to: <200204050602.g3562j118658@aztec.santafe.edu> (message from
	Richard Stallman on Thu, 4 Apr 2002 23:02:45 -0700 (MST))
Subject: Re: [twurgler@goodyear.com: Re: emacs 21.2 odd behavior in shell window]


Recently Richard Stallman <rms@gnu.org> wrote:

> Date: Thu, 4 Apr 2002 23:02:45 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> CC: twurgler@goodyear.com, bug-gnu-emacs@gnu.org
> Reply-to: rms@gnu.org
> 
> 
>     So I got out of emacs totally, restarted, tried the ^C^C again and it didn't
>     work.
> 
>     So I brought comint.el into a buffer again, eval'ed just comint-interrupt-subjob
>     without adding or changing anything else.  Now ^C^C worked just fine.
> 
> It sounds like the function works interpreted and fails compiled.
> Can you verify that?

I am not sure how to verify that.  

I renamed the comint.elc and then byte-compiled comint.el (I did this because
the .elc header said it was compiled with emacs-21.1).  This did not help.

If I eval the defun, ^C^C works.
If I run esc-: (comint-interrupt-subjob), the routine works.
Just not if I run it via ^C^C via the normal load etc.

If you can guide me a bit, I'll try to verify it...


> 
> If so, the next step is to debug at C level.  Use GDB to put a
> breakpoint at Finterrupt_process, and see if it gets called the same
> way in both cases.  See what happens inside it in both cases.
> 

Not good at this, but I'll give it a try...
------- End of forwarded message -------