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

[Ryan Johnson]

On 03/04/2013 4:02 PM, Corinna Vinschen wrote:
> On Apr  3 21:03, Corinna Vinschen wrote:
>> On Apr  3 14:00, Ken Brown wrote:
>>> On 4/3/2013 10:05 AM, Corinna Vinschen wrote:
>>>> 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...
> I found it.  When using the display-time-mode option, emacs opens and
> reads /proc/loadavg.  The problem was that the buffer allocated in
> format_proc_loadavg is too small, so the subsequent sprintf overwrites
> unrelated data on the cygheap.
>
> In fact, this problem occurs on 32 bit as well, so I fixed it in CVS
> HEAD in the first place.  It's kind of a miracle that this has never
> been encountered in the 32 bit version before.  The problem exists
> since at least Cygwin 1.7.10.
Sounds like a classic Schroedinbug [1]... thanks for the fix.

[1] http://www.catb.org/jargon/html/S/schroedinbug.html

Ryan