Re: Symbol's chain of function indirections contains a loop

[Lennart Borgman]

On Sun, Jan 30, 2011 at 7:21 PM, Eli Zaretskii <address@hidden> wrote:
>> From: Lennart Borgman <address@hidden>
>> Date: Sun, 30 Jan 2011 12:04:16 +0100
>> Cc: Tassilo Horn <address@hidden>, address@hidden, address@hidden
>>
>> I have no idea of what is going on, but I notice these defaliases
>>
>> ./ldefs-boot.el:30154:(defalias 'vc-pull 'vc-update)
>> ./loaddefs.el:29693:(defalias 'vc-update 'vc-pull)
>
> That was it!  Once Andreas regenerated ldefs-boot.el, Emacs now
> bootstraps flawlessly on MS-Windows for me.


Thanks Eli and Andreas. Finally I was able to build Emacs again.

However the troubles we have discussed here were not all. I had
another one too which costed my some time. I am still not sure about
the problem and the solution to it (though I am quite sure it is w32
specific). Here it is:

For some time I have seen I have seen that the subprocess to running
the program diff in ediff hangs. I have to kill the program (I am
using Task Manager to do this). After that Emacs recieves the correct
info from diff and everything works as it should.

So it looks like Emacs is waiting for the subprocess to finish, doing
just the last thing whatever that might be, but something prevents it
from finishing.

I observed this with my patched Emacs and thought I would have a
closer look after a new checkout.

But then I saw that building Emacs also hanged. No CPU consumption. It
just hanged. It looked like it waited for a subprocess too.

So I searched the net and saw someone had problem with Google Desktop
and some compiler IDE (not Emacs). He did not find out what the
problem was but it went away when he uninstalled Google Desktop.

This was along my "suspicion line" where I suspect some update to my
antivirus software. Now I thought that Google Desktop probably used
the file change notification API:s too so it looked to me that they
may be doing some bad API call there.

I thought that there are more reason to suspect Google Desktop than
the antivirus software since the antivirus software is widely used
(and optimized not to disturb which probably mean they delay looking
at new and change files) on w32 while Google Desktop might not be that
much used (since w32 has a built in indexer). Beside that Google seems
to put less effort on w32. Rumors says they are not using w32 in
house. That of course means they might have less expertise on w32
API:s now.

So I disabled Google Desktop. And then I could build Emacs.

Though this does not mean I know where the problem really is. Could
there still be some problem with the w32 subprocess calls? Do we check
everything we can check after each call? And when it is finished?