Re: Problems with: Improvements to fork handling (2/5)

[Daniel Colascione <dan dot colascione at gmail dot com>]

On 5/28/11 7:35 PM, Ryan Johnson wrote:
> On 28/05/2011 8:23 PM, Christopher Faylor wrote:
>> On Sat, May 28, 2011 at 06:40:30PM -0400, Ryan Johnson wrote:
>>> On 28/05/2011 4:50 PM, Christopher Faylor wrote:
>>>> On Wed, May 11, 2011 at 02:31:37PM -0400, Ryan Johnson wrote:
>>>>> This patch has the parent sort its dll list topologically by
>>>>> dependencies. Previously, attempts to load a DLL_LOAD dll risked
>>>>> pulling
>>>>> in dependencies automatically, and the latter would then not benefit
>>>> >from the code which "encourages" them to land in the right places. The
>>>>> dependency tracking is achieved using a simple class which allows to
>>>>> introspect a mapped dll image and pull out the dependencies it lists.
>>>>> The code currently rebuilds the dependency list at every fork rather
>>>>> than attempt to update it properly as modules are loaded and unloaded.
>>>>> Note that the topsort optimization affects only cygwin dlls, so any
>>>>> windows dlls which are pulled in dynamically (directly or indirectly)
>>>>> will still impose the usual risk of address space clobbers.
>>>> Bad news.
>>>>
>>>> I applied this patch and the one after it but then noticed that zsh
>>>> started
>>>> producing:  "bad address: " errors.
>>>>
>>>> path:4: bad address: /share/bin/dopath
>>>> term:1: bad address: /bin/tee
>>>>
>>>> The errors disappear when I back this patch out.
>>>>
>>>> FWIW, I was running "zsh -l".  I have somewhat complicated
>>>> .zshrc/.zlogin/.zshenv files.  I'll post them if needed.
>>>>
>>>> Until this is fixed, this patch and the subsequent ones which rely on
>>>> it, can't go in.  I did commit this fix but it has been backed out now.
>>> Hmm. I also see bad address errors in bash sometimes. However, when I
>>> searched through the cygwin mailing list archives I saw that other
>>> people have reported this problem in the past [1], so I figured it was
>>> some existing, sporadic issue rather than my patch...
>>>
>>> Could you tell me what a 'bad address' error is? I'd be happy to debug
>>> this, but really don't know what kind of bug I'm hunting here, except
>>> that it might be a problem wow64 and suspending threads [2]. Whatever
>>> became of these bad address errors the last time(s) they cropped up? I
>>> can't find any resolution with Google, at least.
>> If I had any insight beyond "It works without the patch and it doesn't
>> work with it" I would have shared it.

> Let me rephrase a bit... The error happens too early in fork for gdb to
> be any help, and I was hoping you could tell me what part(s) of cygwin
> are capable of "raising" this error -- it seems to be a linux (not
> Windows) flavor of error message, but the case-insensitive regexp
> 'bad.address' does not match anything in the cygwin sources.

The actual string is in strerror.c in newlib, which is why you didn't
find it with a grep on winsup/cygwin. The error code is EFAULT. There
are 127 places in the cygwin1.dll where EFAULT can raised, according to
grep '\bEFAULT\b' *.cc. In most of them, EFAULT is raised after
something called san has detected that to Windows raised an unexpected
structured exception. My hunch would be to look in spawn.cc first, in
spawn_guts, but I haven't read your patch in enough detail to narrow the
problem down further. strace might be handy.

Attachment: signature.asc
Description: OpenPGP digital signature