This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 4/3/2013 7:41 AM, Corinna Vinschen wrote:
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?

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.

Ken


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]