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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Apr  2 18:57, Ken Brown wrote:
> On 4/2/2013 3:00 PM, Corinna Vinschen wrote:
> >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.
> 
> How did you figure out that the crash occurs in cmalloc?  I tried
> addr2line, but it gave me no information:
> 
> $ addr2line -e /bin/cygwin1.dll 1800429F4
> ??:?

Are you sure the stackdump is from the same version of the Cygwin
DLL you're running now?

> Anyway, I tried to run emacs under gdb with a breakpoint at cmalloc.
> But after I pressed c enough times to get back to the running emacs,
> emacs became unresponsive, and I had to kill gdb with the Task
> Manager.  The same steps in 32-bit Cygwin worked fine.  This might
> just be another symptom of the bug.

Maybe.  Using GDB on 64 bit seems to be a bit shaky right now, but
I hope this changes over time.

I didn't try emacs myself yet, but I will today.


Corinna

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