On Sat, May 28, 2011 at 09:37:49PM -0700, Daniel Colascione wrote: >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.
It doesn't come from newlib. If you grep "Bad address" in winsup/cygwin/* you will see where it comes from. I don't know why grep -i 'bad.address' didn't find anything but it really is there. >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. spawn.cc wasn't touched by the patch but I suppose something in the modified fork code could affect a subsequent exec. Anyway, I don't see any indication that the problem is too early for the CYGWIN_DEBUG= trick to work. See how-to-debug-cygwin.txt. cgf