Re: Segfault in _cygwin_dll_entry
On Wed, 11 Feb 2004 [EMAIL PROTECTED] wrote:
The difference, althought it really doesn't matter, is that
libzsh-4.1.1.dll was rebased, while cygggi-2.dll isn't. Something in the
makeup of cygggi-2.dll causes the same condition as when libzsh-4.1.1.dll
is rebased.
I found a couple of __declspec(dllexport) and __declspec(dllimport) from
a previous attempt at porting GGI to cygwin/mingw. When I removed these
the segfault disappeared.
Thanks! That was one of the missing pieces! Ok, I'm attaching a script
which illustrates the problem in a very simple form (it's the distilled
form of how zsh's dlls are built and, I suspect, how cygggi-2.dll was
built as well).
The script creates two very simple source files, one a program main
(testmain.c), one a simple dll (testdll.c), compiles them, uses dllwrap
to create a dll, then runs the program to show it works, and then rebases
the dll and runs it again to show the failure. The script also does a
complete objdump of the dll before and after the rebase.
The important thing to note is that there is a symbol in the dll called,
aptly enough, _image_base__, which appears to be used by something, of
which I know not what. But, the fact that this symbol has the same value
as the dll's original image base must mean something. Rebase, obviously,
does not look for this symbol and does not change it's value. For grins,
I edited the rebased dll with a hex editor or manually changed the value
to be the new image base address and, whamo!, it runs!
Now, the source in this example uses __declspec(dllexport) to export the
symbol (test_main in this case), and the object file thus contains a new
section which I'm not directly familiar with: .drectve
This section has the following content for our little test:
Contents of section .drectve:
202d6578 706f7274 3a746573 745f6d61 -export:test_ma
0010 696e in..
And to dllwrap (or rather gcc) this section means something and causes
the symbol _image_base__ to be set in the dll to the imagebase for the
dll. If you remove/comment the __declspec stuff from the test source and
re-run it, the object file does not have the mystery section and the
subsequent dll doesn't have _image_base__ set it in, and everything
runs well, rebased or not.
So, this is the cause of the error. Now, for the question: should we not
be using __declspec(dllexport)/__declspec(dllimport) or should rebase be
updated to look for this symbol and change it's value accordingly?
Enquiring Minds Want To Know!!!
Regards,
Peter Ekberg
--
Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED]
Cats are just autistic Dogs -- Dr. Tony Attwood#!/bin/bash
echodo()
{
echo $*
eval $*
}
echo ## Creating testdll.c source
cat EOF testdll.c
#include stdio.h
__declspec(dllexport)
int test_main(int argc, char **argv)
{
printf(hello\n);
}
EOF
echo ## Creating testmain.c source
cat EOF testmain.c
#include stdio.h
__declspec(dllimport)
extern int test_main(int argc, char **argv);
main(int argc, char **argv)
{
test_main(argc,argv);
}
EOF
echo ## Compiling testdll.c - testdll.o
echodo gcc -g -c testdll.c
echo ## Creating testdll.dll
echodo dllwrap -g --export-all-symbols -o testdll.dll testdll.o -lc
echo ## Compiling testmain.c - testmain.o
echodo gcc -g -c testmain.c
echo ## Linking testmain.o, testdll.dll - testmain.exe
echodo gcc -g -o testmain testmain.o testdll.dll -lc
echo ## Running testmain.exe, should produce 'hello'
echodo ./testmain
echo ## Getting objdump of clean testdll.dll for later perusal
echodo objdump -a -f -p -x -d -D -S -s -g -e -G -t -T -r -R testdll.dll
testdll.dll.objdump
echo ## Saving clean testdll.dll and objdump
echodo cp -a testdll.dll testdll.clean.dll
echodo cp -a testdll.dll.objdump testdll.clean.dll.objdump
echo ## Rebasing testdll.dll
echodo rebase -v -d -b 0x7000 -o 0x1 testdll.dll
echo ## Getting objdump of clean testdll.dll for later perusal
objdump -a -f -p -x -d -D -S -s -g -e -G -t -T -r -R testdll.dll testdll.dll.objdump
echo ## Running testmain.exe, should produce a Windows popup error box
echodo ./testmain
--
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/
Re: Segfault in _cygwin_dll_entry
The difference, althought it really doesn't matter, is that libzsh-4.1.1.dll was rebased, while cygggi-2.dll isn't. Something in the makeup of cygggi-2.dll causes the same condition as when libzsh-4.1.1.dll is rebased. I found a couple of __declspec(dllexport) and __declspec(dllimport) from a previous attempt at porting GGI to cygwin/mingw. When I removed these the segfault disappeared. 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/
Re: Segfault in _cygwin_dll_entry
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$0x,%eax 0x6ff4095b [EMAIL PROTECTED]: mov%eax,0x7fd98610 0x6ff40960 [EMAIL PROTECTED]: jmp0x6ff408fb [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$0x,%eax 0x600f095b [EMAIL PROTECTED]: mov%eax,0x600f8610 0x600f0960 [EMAIL PROTECTED]: jmp0x600f08fb [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: 0x 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: 0x 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$0x,%eax 0x00354b2b [EMAIL PROTECTED]: mov%eax,0xf06a6060 0x00354b30 [EMAIL PROTECTED]: jmp0x354acb [EMAIL PROTECTED] 0x00354b32 [EMAIL PROTECTED]: mov%ecx,0xf06a6030 ~~ 0x00354b38 [EMAIL PROTECTED]: mov$0x1,%eax 0x00354b3d [EMAIL PROTECTED]: mov%eax,0xf06a6040
Re: Segfault in _cygwin_dll_entry
Peter, On Mon, Feb 09, 2004 at 10:14:10AM +0100, [EMAIL PROTECTED] wrote: You're talking about rebased dlls. I don't know if cygggi-2.dll is rebased or not, how can I tell? Rebasing is a manual process. So, if you didn't run rebaseall or rebase yourself, then cygggi-2.dll and the rest of your DLLs are not rebased. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
Re: Segfault in _cygwin_dll_entry
On Mon, 9 Feb 2004 [EMAIL PROTECTED] wrote: Peter A. Castro wrote: In the case of zsh, it's completely cygwin stuff, no MS stuff. As is the case with LibGGI. The difference, althought it really doesn't matter, is that libzsh-4.1.1.dll was rebased, while cygggi-2.dll isn't. Something in the makeup of cygggi-2.dll causes the same condition as when libzsh-4.1.1.dll is rebased. 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$0x,%eax 0x6ff4095b [EMAIL PROTECTED]: mov%eax,0x7fd98610 0x6ff40960 [EMAIL PROTECTED]: jmp0x6ff408fb [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$0x,%eax 0x600f095b [EMAIL PROTECTED]: mov%eax,0x600f8610 0x600f0960 [EMAIL PROTECTED]: jmp0x600f08fb [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: 0x 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: 0x 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
Re: Segfault in _cygwin_dll_entry
Igor Pechtchanski wrote: 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 assume that by dynamically load, you are referring to dlopen(). If I assume correctly, then that is not the case here. main() is not reached before the segfault happens. /Peter -- 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/
Re: Segfault in _cygwin_dll_entry
Larry Hall wrote: I'd suggest 'cygcheck cygggi-2.dll'. Make sure there's no MS CRT in there anywhere. If there is, you're on dangerous ground. Comparing the output of this with that of cygii-0.dll might be instructive too. ~$ cygcheck /bin/cyggg-0.dll C:/cygwin/bin/cyggg-0.dll C:/cygwin/bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL ~$ cygcheck /bin/cyggii-0.dll C:/cygwin/bin/cyggii-0.dll C:/cygwin/bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL C:/cygwin/bin\cyggg-0.dll ~$ cygcheck /bin/cygggi-2.dll C:/cygwin/bin/cygggi-2.dll C:/cygwin/bin\cyggg-0.dll C:/cygwin/bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL C:/cygwin/bin\cyggii-0.dll 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. What should I read to get going with debugging into the Cygwin DLL? /Peter -- 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/
Re: Segfault in _cygwin_dll_entry
At 02:57 AM 2/6/2004, [EMAIL PROTECTED] you wrote: Larry Hall wrote: I'd suggest 'cygcheck cygggi-2.dll'. Make sure there's no MS CRT in there anywhere. If there is, you're on dangerous ground. Comparing the output of this with that of cygii-0.dll might be instructive too. ~$ cygcheck /bin/cyggg-0.dll C:/cygwin/bin/cyggg-0.dll C:/cygwin/bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL ~$ cygcheck /bin/cyggii-0.dll C:/cygwin/bin/cyggii-0.dll C:/cygwin/bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL C:/cygwin/bin\cyggg-0.dll ~$ cygcheck /bin/cygggi-2.dll C:/cygwin/bin/cygggi-2.dll C:/cygwin/bin\cyggg-0.dll C:/cygwin/bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL C:/cygwin/bin\cyggii-0.dll OK, fine. 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. What should I read to get going with debugging into the Cygwin DLL? Start here: http://cygwin.com/contrib.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
Re: Segfault in _cygwin_dll_entry
At 06:10 AM 2/5/2004, [EMAIL PROTECTED] you wrote: Hello! I have been trying to get LibGGI to build and work on cygwin and I have the following problem: When I run an application linked against the resulting cygggi-2.dll it segfaults in [EMAIL PROTECTED] (according to gdb) before main is reached. LibGGI consists of three core libraries: ggi, gii and gg. Now, cygggi-2.dll is linked against both cyggii-0.dll and cyggg-0.dll. cyggii-0.dll is in turn linked against cyggg-0.dll. I don't know if there is any relevance to this dependency tree, but I include it since programs linked directly against cyggii-0.dll does _not_ segfault. I can not find any relevant difference between how cygggi-2.dll and cyggii-0.dll are built. None of them defines a _cygwin_dll_entry, which means that cygwin should provide one, if I understand things correctly? strace on the failing application produces no output. The only other dlls these dlls depend on (directly) are cygwin1.dll and kernel32.dll (according to depends.exe provided with MSVC) How can I get more info on what is going on? I'd suggest 'cygcheck cygggi-2.dll'. Make sure there's no MS CRT in there anywhere. If there is, you're on dangerous ground. Comparing the output of this with that of cygii-0.dll might be instructive too. 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. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
Re: Segfault in _cygwin_dll_entry
On Thu, 5 Feb 2004, Larry Hall wrote: At 06:10 AM 2/5/2004, [EMAIL PROTECTED] you wrote: Hello! I have been trying to get LibGGI to build and work on cygwin and I have the following problem: When I run an application linked against the resulting cygggi-2.dll it segfaults in [EMAIL PROTECTED] (according to gdb) before main is reached. LibGGI consists of three core libraries: ggi, gii and gg. Now, cygggi-2.dll is linked against both cyggii-0.dll and cyggg-0.dll. cyggii-0.dll is in turn linked against cyggg-0.dll. I don't know if there is any relevance to this dependency tree, but I include it since programs linked directly against cyggii-0.dll does _not_ segfault. I can not find any relevant difference between how cygggi-2.dll and cyggii-0.dll are built. None of them defines a _cygwin_dll_entry, which means that cygwin should provide one, if I understand things correctly? strace on the failing application produces no output. The only other dlls these dlls depend on (directly) are cygwin1.dll and kernel32.dll (according to depends.exe provided with MSVC) How can I get more info on what is going on? I'd suggest 'cygcheck cygggi-2.dll'. Make sure there's no MS CRT in there anywhere. If there is, you're on dangerous ground. Comparing the output of this with that of cygii-0.dll might be instructive too. 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*). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- 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/
Re: Segfault in _cygwin_dll_entry
On Thu, 5 Feb 2004, Igor Pechtchanski wrote: On Thu, 5 Feb 2004, Larry Hall wrote: At 06:10 AM 2/5/2004, [EMAIL PROTECTED] you wrote: Hello! I have been trying to get LibGGI to build and work on cygwin and I have the following problem: Interestingly enough this is the same problem I've been tracking down with reguard to rebaseing zsh's dll's. What follows is some analysis I've been doing on zsh and rebase. When I run an application linked against the resulting cygggi-2.dll it segfaults in [EMAIL PROTECTED] (according to gdb) before main is reached. LibGGI consists of three core libraries: ggi, gii and gg. Now, cygggi-2.dll is linked against both cyggii-0.dll and cyggg-0.dll. cyggii-0.dll is in turn linked against cyggg-0.dll. I don't know if there is any relevance to this dependency tree, but I include it since programs linked directly against cyggii-0.dll does _not_ segfault. I can not find any relevant difference between how cygggi-2.dll and cyggii-0.dll are built. None of them defines a _cygwin_dll_entry, which means that cygwin should provide one, if I understand things correctly? If I understand how cygwin works correctly, the cygwin runtime is called from the native Windows mechanism for loading executables and loading DLLs. cygwin_dll_entry() is a function which resolves the cygwin specific environment and attaches it to the current process/thread of the DLL. It appears this mechanism might have a bug or is making an assumption on how things work which sometimes isn't correct. strace on the failing application produces no output. The only other dlls these dlls depend on (directly) are cygwin1.dll and kernel32.dll (according to depends.exe provided with MSVC) How can I get more info on what is going on? I'd suggest 'cygcheck cygggi-2.dll'. Make sure there's no MS CRT in there anywhere. If there is, you're on dangerous ground. Comparing the output of this with that of cygii-0.dll might be instructive too. In the case of zsh, it's completely cygwin stuff, no MS stuff. 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$0x,%eax 0x6ff4095b [EMAIL PROTECTED]: mov%eax,0x7fd98610 0x6ff40960 [EMAIL PROTECTED]: jmp0x6ff408fb [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$0x,%eax 0x600f095b [EMAIL PROTECTED]: mov%eax,0x600f8610 0x600f0960 [EMAIL PROTECTED]: jmp0x600f08fb [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
