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 21:03:54 +0200
- Subject: Re: [64bit] emacs is unable to call subprocesses if display-time-mode is set
- References: <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> <20130403114102 dot GA31598 at calimero dot vinschen dot de> <515C3358 dot 7080108 at cornell dot edu> <20130403140535 dot GC31598 at calimero dot vinschen dot de> <515C6E2E dot 7080201 at cornell dot edu>
- Reply-to: cygwin-developers at cygwin dot com
On Apr 3 14:00, Ken Brown wrote:
> On 4/3/2013 10:05 AM, Corinna Vinschen wrote:
> >On Apr 3 09:49, Ken Brown wrote:
> >>On 4/3/2013 7:41 AM, Corinna Vinschen wrote:
> >>>On Apr 2 18:57, Ken Brown wrote:
> >>>>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?
> >>
> >>I didn't get a stackdump. I was relying on the following line from
> >>the strace output:
> >>
> >> Process 4928, exception c0000005 at 00000001800429F4
> >>
> >>I just reproduced that today, with the same address, so there's no
> >>question of the DLL version.
> >
> >Hmm. Did you install the cygwin-debuginfo package? If all else
> >fails, try `addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg'. I get
> >
> > $ $ addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 1800429F4
> > /usr/src/debug/cygwin-1.7.18-15/winsup/cygwin/cygheap.cc:298
>
> Ah, that works. I thought addr2line was supposed to know where to
> find cygwin1.dbg.
>
> >I can reproduce the issue but it's tricky to debug. The exception
> >occurs in the forked process and GDB can't follow fork on Cygwin.
> >
> >Btw., can you create an emacs which is built without optimization
> >and non-stripped this would simplify debuigging a bit...
>
> It was already built without optimization. I'm working on building
> a non-stripped version, but cygport isn't cooperating. If you put
> "RESTRICT=strip" into the .cygport file, then cygport doesn't
> package the sources. So you get a binary with debugging symbols,
> but you don't get the corresponding sources.
>
> I'll send Yaakov a patch, but in the meantime I'm working around
> this. It shouldn't be long.
I'm still debugging this and something is very fishy when building
the environment for a process-to-exec. I tracked it down to a
specific string duplication in Cygwin's build_env function which
seems to overwrite administrative data on the cygheap for some
reason I didn't quite follow yet.
This may take some time...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat