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

[Ken Brown]

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.

Thanks, I didn't know that.  I just tried and sure enough gdb reported 
nargs == 4 after one step.

>> 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.

Thanks.  In the meantime, I'll keep trying to make a test case.

Ken