This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [64bit] emacs is unable to call subprocesses if display-time-mode is set
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 3 Apr 2013 13:41:02 +0200
- Subject: Re: [64bit] emacs is unable to call subprocesses if display-time-mode is set
- References: <5156C44D dot 7050805 at cornell dot edu> <20130330111714 dot GA17203 at calimero dot vinschen dot de> <51598232 dot 5020505 at cornell dot edu> <5159B006 dot 3060100 at cornell dot edu> <515B1DA4 dot 3020502 at cornell dot edu> <20130402190027 dot GC2468 at calimero dot vinschen dot de> <515B624A dot 4070102 at cornell dot edu>
- Reply-to: cygwin-developers 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