[64bit] emacs is unable to call subprocesses if display-time-mode is set

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Apr 2 19:00:00 GMT 2013


On Apr  2 14:04, Ken Brown wrote:
> On 4/1/2013 12:04 PM, Ken Brown wrote:
> >On 4/1/2013 8:48 AM, Ken Brown wrote:
> >>On 3/30/2013 7:17 AM, Corinna Vinschen wrote:
> >>>On Mar 30 06:54, Ken Brown wrote:
> >>>>When you set display-time-mode in emacs, the mode line near the
> >>>>bottom of the screen shows the current time.  The code that does
> >>>>this involves setting itimers.
> >>>
> >>>Can you extrace a simple testcase from the itimer code?  That would help
> >>>a lot to track down this case.  I'm a bit scared of emacs...
> >>
> >>I was wrong about itimers.  It turns out that emacs uses two different
> >>kinds of timers.  One type is defined in C code and uses itimers, and
> >>the other type is defined in Lisp code.  It's the latter that's involved
> >>here.  So it won't be easy to make a test case in plain C.
> >>
> >>I'm also finding that the order in which I do things affects whether or
> >>not the bug shows up.  For example, if I start a shell within emacs
> >>before setting display-time-mode, the bug disappears.  I'll keep looking
> >>at the emacs code, but maybe you'll be able to see something in the
> >>strace output.
> >
> >Sorry for yet another email, but I just wanted to let you know that you
> >shouldn't put much time into this unless something jumps out at you.
> >
> >I just looked at this with gdb again and noticed that the function
> >`Fcall_process' [which is the C function that implements the lisp
> >function `call-process'] is being called with an argument nargs =
> >4305072226, which is 0x1009A3062; the value should be 4.  nargs is of
> >type ptrdiff_t.  I'll try to figure out why this is happening.
> 
> It turns out that gdb is giving me bogus information.  I don't know
> if that's caused by a gdb bug, a Cygwin bug, an emacs bug, or
> something else.

GDB sometimes can't show correct information if you didn't step into the
function deep enoughs since the debug information isn't complete.  A
single step to the next line most of the time fixes that.

> If you wouldn't mind taking a look at the original bug when you get
> a chance, maybe you can spot something using strace or whatever
> other tools you have.  (BTW, I just retested with cygwin-1.7.18-15,
> and the bug is still there.)  If you want to confirm the gdb issue,
> install emacs-debuginfo and run gdb with a breakpoint at
> Fcall_process before carrying out my recipe.

I can try tomorrow, but a testcase is ultimately more helpful.  The
strace doesn't contain a lot of info, except that the crash occurs in
the function cmalloc, which allocates space on the cygheap.  It's not
clear what function has been called at this point, though.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat



More information about the Cygwin-developers mailing list