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

[Ken Brown]

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