Peter A. Castro wrote:
> In the case of zsh, it's completely cygwin stuff, no MS stuff.
As is the case with LibGGI.
> > > >Is it a known problem?
> > >
> > > No. If nothing "obvious" turns up in your initial efforts to scope
the
> > > problem, you're probably going to be best off debugging into the
Cygwin
> > > DLL to see where it crashes.
> >
> > One obvious thing to check for is whether the application tries to
> > dynamically load a Cygwin-dependent DLL (which may result in
attempting to
> > load cygwin1.dll dynamically, and that is *not supported*).
>
> I have yet to fully understand just where the fault is, but I do know
> this: the .bss segment used by cygwin_dll_entry sometimes is not where
it
> thinks it it.
>
> I found this while debugging the zsh rebase problem, and so my methods
> are a little quirky :)
>
> First, rebase the libzsh-4.1.1.dll and start gdb of zsh.exe, then run
it.
> It'll break with a segfault occuring inside [EMAIL PROTECTED] The
> specific instruction is at [EMAIL PROTECTED]:
>
> (gdb) disassemble
> 0x6ff40951 <[EMAIL PROTECTED]>: call 0x6ff41390
<cygwin_detach_dll>
> 0x6ff40956 <[EMAIL PROTECTED]>: mov $0xffffffff,%eax
> 0x6ff4095b <[EMAIL PROTECTED]>: mov %eax,0x7fd98610
> 0x6ff40960 <[EMAIL PROTECTED]>: jmp 0x6ff408fb
<[EMAIL PROTECTED]>
> 0x6ff40962 <[EMAIL PROTECTED]>: mov %ecx,0x7fd985e0
> ~~~~~~~~~~
> 0x6ff40968 <[EMAIL PROTECTED]>: mov $0x1,%eax
> 0x6ff4096d <[EMAIL PROTECTED]>: mov %eax,0x7fd985f0
> 0x6ff40972 <[EMAIL PROTECTED]>: mov %edx,0x7fd98600
> 0x6ff40978 <[EMAIL PROTECTED]>: movl $0x7fd908a0,0x4(%esp,1)
> 0x6ff40980 <[EMAIL PROTECTED]>: mov %ecx,(%esp,1)
> 0x6ff40983 <[EMAIL PROTECTED]>: call 0x6ff413a0
<cygwin_attach_dll>
>
> So, what's up with 0x7fd985e0 ? gdb can't seem to resolve it nor access
> the address (hence the segfault):
>
> (gdb) info symbol 0x7fd985e0
> No symbol matches 0x7fd985e0.
> (gdb) x/x 0x7fd985e0
> 0x7fd985e0: Cannot access memory at address 0x7fd985e0
>
> Ok, so restore the un-rebased libzsh-4.1.1.dll, start gdb of zsh, set a
> break point at main and run it. It'll stop at the break point, no
> faults. Now, get the address of [EMAIL PROTECTED] and have a look at
> the same section of code:
>
> (gdb) info address [EMAIL PROTECTED]
> Symbol "[EMAIL PROTECTED]" is at 0x600f08d0 in a file compiled
without debugging.
> (gdb) disassemble
> 0x600f0951 <[EMAIL PROTECTED]>: call 0x600f1390
<cygwin_detach_dll>
> 0x600f0956 <[EMAIL PROTECTED]>: mov $0xffffffff,%eax
> 0x600f095b <[EMAIL PROTECTED]>: mov %eax,0x600f8610
> 0x600f0960 <[EMAIL PROTECTED]>: jmp 0x600f08fb
<[EMAIL PROTECTED]>
> 0x600f0962 <[EMAIL PROTECTED]>: mov %ecx,0x600f85e0
> ~~~~~~~~~~
> 0x600f0968 <[EMAIL PROTECTED]>: mov $0x1,%eax
> 0x600f096d <[EMAIL PROTECTED]>: mov %eax,0x600f85f0
> 0x600f0972 <[EMAIL PROTECTED]>: mov %edx,0x600f8600
> 0x600f0978 <[EMAIL PROTECTED]>: movl $0x600f08a0,0x4(%esp,1)
> 0x600f0980 <[EMAIL PROTECTED]>: mov %ecx,(%esp,1)
> 0x600f0983 <[EMAIL PROTECTED]>: call 0x600f13a0
<cygwin_attach_dll>
>
> (gdb) info symbol 0x600f85e0
> storedHandle in section .bss
> (gdb) info address storedHandle
> Symbol "storedHandle" is at 0x600f85e0 in a file compiled without
debugging.
> (gdb) x/x 0x600f85e0
> 0x600f85e0 <storedHandle>: 0x00000000
>
> Ah! So, in the un-rebased scenario storedHandle is in a .bss section.
> So, rebase libzsh-4.1.1.dll again, start gdb of zsh, and let it run.
> It'll break with a segfault, again, occuring inside
[EMAIL PROTECTED]
>
> So, just where is storedHandle?
>
> (gdb) info address storedHandle
> Symbol "storedHandle" is at 0x6ff485e0 in a file compiled without
debugging.
> (gdb) info symbol 0x6ff485e0
> storedHandle in section .bss
> (gdb) x/x 0x6ff485e0
> 0x6ff485e0 <storedHandle>: 0x00000000
>
> Ah, but the code thinks storedHandle is at 0x7fd985e0 (which isn't
> addressable)! It turns out that 0x6ff485e0 is the same location this
> part of the .bss was loaded at in the non-rebased scenario. So, where
> did things get messed up? Did Windows load the section and pass a bogus
> section address to the dll or is there a bug in the fixup code, or did
> cygwin_dll_entry() resolve the handle to the address incorrectly?
>
> I've looked at the code for cygwin_dll_entry and it's straight forward
> enough, so I just don't see where things could have gone wrong. Is this
> perhaps a quirk of the C++ environment or have we perhaps found a
Windows
> bug?
This indeed looks the same. Here's the disassembly from the segfault
in LibGGI.
0x00354b21 <[EMAIL PROTECTED]>: call 0x354cf0
<cygwin_detach_dll>
0x00354b26 <[EMAIL PROTECTED]>: mov $0xffffffff,%eax
0x00354b2b <[EMAIL PROTECTED]>: mov %eax,0xf06a6060
0x00354b30 <[EMAIL PROTECTED]>: jmp 0x354acb
<[EMAIL PROTECTED]>
0x00354b32 <[EMAIL PROTECTED]>: mov %ecx,0xf06a6030
~~~~~~~~~~
0x00354b38 <[EMAIL PROTECTED]>: mov $0x1,%eax
0x00354b3d <[EMAIL PROTECTED]>: mov %eax,0xf06a6040
0x00354b42 <[EMAIL PROTECTED]>: mov %edx,0xf06a6050
0x00354b48 <[EMAIL PROTECTED]>: movl $0xf06a4a70,0x4(%esp,1)
0x00354b50 <[EMAIL PROTECTED]>: mov %ecx,(%esp,1)
0x00354b53 <[EMAIL PROTECTED]>: call 0x354d00
<cygwin_attach_dll>
and here's my version of the storedHandle stuff:
(gdb) info address storedHandle
Symbol "storedHandle" is at 0x356030 in a file compiled without debugging.
(gdb) info symbol 0x356030
storedHandle in section .bss
(gdb) x/x 0x356030
0x356030 <storedHandle>: 0x00000000
The four last digits match for me as well, at least an indication...
There's no C++ involved in any of the LibGGI dlls, I guess we can
rule that out. Or is there C++ in the cygwin1.dll?
You're talking about rebased dlls. I don't know if cygggi-2.dll is
rebased or not, how can I tell? It is relinked when libtool installs
it, but so is cyggii-0.dll. And cyggii-0.dll works when used alone.
And please CC me on this subject, I'm not on the list.
Regards,
Peter Ekberg
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
