Re: Problems with Insigt and cygwin1.dll

Re: Problems with Insigt and cygwin1.dll

[Keith Seitz]

Pavel Kudrna wrote:
> 
> I have also the unresolved problem with crash of another program in
> _size_of_stack_reserve__ (). So I can help with the fact that this
> function you can find in ld.exe. But also I have to repeat your
> (maybe not expressed) question how to debug into the .dll? Can
> anybody at least say that it's not possible?

I don't know about your specific problems, but as far as  debugging the
cygwin DLL goes, that is certainly possible: I've done it many, many
times. There are really no special techniques for doing this. Just make
sure that the DLL and newlib were compiled with debug info and that you
use the "dir" command to add the source paths for these modules to gdb's
list. You should be able to step into newlib, which then gets you into
the DLL.

Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com

Re: Problems with Insigt and cygwin1.dll

[Fernando Nasser]

Keith Seitz wrote:
> 
> Pavel Kudrna wrote:
> >
> > I have also the unresolved problem with crash of another program in
> > _size_of_stack_reserve__ (). So I can help with the fact that this
> > function you can find in ld.exe. But also I have to repeat your
> > (maybe not expressed) question how to debug into the .dll? Can
> > anybody at least say that it's not possible?
> 
> I don't know about your specific problems, but as far as  debugging the
> cygwin DLL goes, that is certainly possible: I've done it many, many
> times. There are really no special techniques for doing this. Just make
> sure that the DLL and newlib were compiled with debug info and that you
> use the "dir" command to add the source paths for these modules to gdb's
> list. You should be able to step into newlib, which then gets you into
> the DLL.
> 

OK, folks.  This is a known problem.  You will find that the program
dies while in a call to select(), in the cygwin1.dll library.

I have a cygwin1.dll that I built with some changes that operates better
and only presents problems under some unusual circumstances.  I can put
it in our ftp site so you can download it.

But if you can spare some time and try to debug it I think everybody
would appreciate.  I won't be able to get to this for quite a while and
other people don't have the right hardware to reproduce it.  If you do,
building cygwin with debugger symbols is a must.  Please send me
questions if you need more information as you go.

Please note that this problem only happens with the select() simulation
under cygwin.  You can debug your programs through the serial port on
Linux and Solaris (which have a native select() in the OS) with no
problems at all. 


-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: Problems with Insigt and cygwin1.dll

[Chris Faylor]

On Tue, Mar 21, 2000 at 02:21:53PM +0000, Fernando Nasser wrote:
>Keith Seitz wrote:
>> Pavel Kudrna wrote:
>> > I have also the unresolved problem with crash of another program in
>> > _size_of_stack_reserve__ (). So I can help with the fact that this
>> > function you can find in ld.exe. But also I have to repeat your
>> > (maybe not expressed) question how to debug into the .dll? Can
>> > anybody at least say that it's not possible?
>> 
>> I don't know about your specific problems, but as far as  debugging the
>> cygwin DLL goes, that is certainly possible: I've done it many, many
>> times. There are really no special techniques for doing this. Just make
>> sure that the DLL and newlib were compiled with debug info and that you
>> use the "dir" command to add the source paths for these modules to gdb's
>> list. You should be able to step into newlib, which then gets you into
>> the DLL.
>> 
>
>OK, folks.  This is a known problem.  You will find that the program
>dies while in a call to select(), in the cygwin1.dll library.

It is premature to say that this is a "known problem" until we can see
where in gdb/cygwin the problem is occurring.

Until we get verification of that fact, I would still like to see debugging
information and would urge people not to download non-standard versions of
tye cygwin DLL.  I have enough headaches with the snapshots that we provide
without having to worry about YA variant offshoot.

cgf

Re: Problems with Insigt and cygwin1.dll

[Andy Hare]

OK Guys,

    late last night I reloaded Insight into GDB and disassembled the
addresses given in my original note. The address at 4fcafd is in fact the
address immediately following the select call in Unix_ReadSerial just as
Fernando suggested earlier. My next problem is to rebuild cygwin from the
sources in debug mode and then to start tracing the calls through, if there
are any pointers to building a debug version I would be grateful as I have
not built cygwin from the sources before. I will let you know how I get on
but it may not be until the weekend before I get a decent run at the
problem.

Andy Hare

----- Original Message -----
From: Chris Faylor <cgf@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Keith Seitz <kseitz@firetalk.com>; Pavel Kudrna
<kudrna@plasma.troja.mff.cuni.cz>; Insight Mail list
<insight@sourceware.cygnus.com>
Sent: Tuesday, March 21, 2000 5:33 PM
Subject: Re: Problems with Insigt and cygwin1.dll


> On Tue, Mar 21, 2000 at 02:21:53PM +0000, Fernando Nasser wrote:
> >Keith Seitz wrote:
> >> Pavel Kudrna wrote:
> >> > I have also the unresolved problem with crash of another program in
> >> > _size_of_stack_reserve__ (). So I can help with the fact that this
> >> > function you can find in ld.exe. But also I have to repeat your
> >> > (maybe not expressed) question how to debug into the .dll? Can
> >> > anybody at least say that it's not possible?
> >>
> >> I don't know about your specific problems, but as far as  debugging the
> >> cygwin DLL goes, that is certainly possible: I've done it many, many
> >> times. There are really no special techniques for doing this. Just make
> >> sure that the DLL and newlib were compiled with debug info and that you
> >> use the "dir" command to add the source paths for these modules to
gdb's
> >> list. You should be able to step into newlib, which then gets you into
> >> the DLL.
> >>
> >
> >OK, folks.  This is a known problem.  You will find that the program
> >dies while in a call to select(), in the cygwin1.dll library.
>
> It is premature to say that this is a "known problem" until we can see
> where in gdb/cygwin the problem is occurring.
>
> Until we get verification of that fact, I would still like to see
debugging
> information and would urge people not to download non-standard versions of
> tye cygwin DLL.  I have enough headaches with the snapshots that we
provide
> without having to worry about YA variant offshoot.
>
> cgf
>

Re: Problems with Insigt and cygwin1.dll

[Fernando Nasser]

Andy Hare wrote:
> 
> OK Guys,
> 
>     late last night I reloaded Insight into GDB and disassembled the
> addresses given in my original note. The address at 4fcafd is in fact the
> address immediately following the select call in Unix_ReadSerial just as
> Fernando suggested earlier. My next problem is to rebuild cygwin from the
> sources in debug mode and then to start tracing the calls through, if there
> are any pointers to building a debug version I would be grateful as I have
> not built cygwin from the sources before. I will let you know how I get on
> but it may not be until the weekend before I get a decent run at the
> problem.
> 
We can guide you through that.

Just expand the cygwin source tree in one directory.

create a work directory, lets say "build" and cd there.

Run "../configure"

And after "make -w"

You should have a "newcygwin1_dll" or something similar (I forgot) in the winsup directory.  It is compiled with
debugger symbols by default.


When you get to this point, e-mail me and we can continue from there.

Thanks for attempting this.

Fernando

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: Problems with Insigt and cygwin1.dll

[Chris Faylor]

On Tue, Mar 21, 2000 at 09:29:34AM +0100, Pavel Kudrna wrote:
>I have also the unresolved problem with crash of another program in 
>_size_of_stack_reserve__ (). So I can help with the fact that this 
>function you can find in ld.exe. But also I have to repeat your 
>(maybe not expressed) question how to debug into the .dll? Can 
>anybody at least say that it's not possible?

I answered this question in the cygwin mailing list.  The bottom
line is that, yes, it is, of course, possible to debug any DLL.

You can load a DLLs symbols via the "add-symbol" command or you
can set a breakpoint in your program after the DLL has been loaded
and set breakpoints and debug normally.

cgf

Re: Problems with Insigt and cygwin1.dll

[Pavel Kudrna]

I have also the unresolved problem with crash of another program in 
_size_of_stack_reserve__ (). So I can help with the fact that this 
function you can find in ld.exe. But also I have to repeat your 
(maybe not expressed) question how to debug into the .dll? Can 
anybody at least say that it's not possible?

Pavel Kudrna


On 20 Mar 00, at 22:47, Andy Hare wrote:

> First of all, apologies for those of you who see this message in both mail
> lists but I am not sure if the problem is in insight or cygwin1.dll.
> 
> When I run a cross version of Insight (ARM based snapshot from 14/3/00)
> under b20.1 under NT4.0 using the latest cygwin1.dll (18/3/00) while single
> stepping I get an exception and the system stops responding. Below is the
> contents of the stackdump that is generated;
> 
> Exception: STATUS_ACCESS_VIOLATION at eip=61036620
> eax=00000000 ebx=0A436B18 ecx=00000000 edx=029ABAB8 esi=00000001
> edi=00000004
> ebp=029ABA38 esp=029AB9C0
> program=C:\cygnus\xgcc-arm\insight\bin\arm-elf-gdb.exe
> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
> 029ABA38  61035EA9  (029ABAB8, 029ABBA0, 029ABA70, 029ABA60)
> 029ABB58  61035EA9  (00000004, 029ABBA0, 029ABA70, 00000000)
> 029ABBA8  004FCAFD  (0059E550, 00000200, 00000001, 00000000)
> 029ABBD8  004FB9C2  (0A409348, 00000001, 00000001, 610739F0)
> 029ABC08  004F9677  (00579D30, 00000000, 029ABC44, 00000001)
> 029ABC48  004F4194  (00000001, 029ABC84, 029ABC88, 004F96D6)
> 029ABC88  004F453B  (00000001, 0A436AF8, 029ABCC8, 004FB278)
> 029ABCC8  004F46FE  (029ABD20, 029ABD24, 029ABD28, 029ABD2C)
> 029ABD38  004F5ADA  (0200122C, 00000001, 029ABD68, 004F6161)
> 029ABD68  004D19C1  (02018248, 029ABDA4, 00000001, 029ABDA4)
> 029ABDA8  004D1393  (FFFFFFFF, 00000001, 00000000, 00431A81)
> 029ABDE8  00431B25  (00000001, 00000000, 029ABE18, 00433393)
> 029ABE18  004333F2  (029ABEC8, 00000001, 029ABE98, 00432E74)
> 029ABE98  00432E80  (029ABEC8, 029ABEC8, 029ABEE8, 004D1393)
> 029ABF48  00431EE1  (00000001, 00000001, 00000000, 00431BAD)
> 029ABF68  00431D51  (FFFFFFFF, 00000050, 00000001, 0042D9CC)
> End of stack trace (more stack frames may be present)
> 
> The given address appears to live in cygwin1.dll. Running insight under GDB
> reveals that the program received a signal SIGSEGV, segmentation fault at
> address 0x61036620 in _size_of_stack_reserve__ (). This address is in the
> cygwin1.dll address space according to listdlls.exe So I downloaded the
> source code for cygwin1.dll to try and find this function so that I could
> back trace the offending code and maybe fix the problem. however I cannot
> find in any of the source code this function or label. I have used grep to
> look for this in both the Insight code base and that for cygwin1.dll. Can
> anyone tell me where this function is coming from and how  I can track the
> problem back. I am happy to try and find the problem but I need to know
> where this function exists.
> 
> The problem only manifests itself when stepping through code on an ANGEL
> target if the target code is just run then the problem does not occur.
> 
> Any pointers or help will be greatly appreciated and I will report back with
> any findings especially if I can find the problem and fix it.
> 
> Andy Hare
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 

Problems with Insigt and cygwin1.dll

[Andy Hare]

First of all, apologies for those of you who see this message in both mail
lists but I am not sure if the problem is in insight or cygwin1.dll.

When I run a cross version of Insight (ARM based snapshot from 14/3/00)
under b20.1 under NT4.0 using the latest cygwin1.dll (18/3/00) while single
stepping I get an exception and the system stops responding. Below is the
contents of the stackdump that is generated;

Exception: STATUS_ACCESS_VIOLATION at eip=61036620
eax=00000000 ebx=0A436B18 ecx=00000000 edx=029ABAB8 esi=00000001
edi=00000004
ebp=029ABA38 esp=029AB9C0
program=C:\cygnus\xgcc-arm\insight\bin\arm-elf-gdb.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
029ABA38  61035EA9  (029ABAB8, 029ABBA0, 029ABA70, 029ABA60)
029ABB58  61035EA9  (00000004, 029ABBA0, 029ABA70, 00000000)
029ABBA8  004FCAFD  (0059E550, 00000200, 00000001, 00000000)
029ABBD8  004FB9C2  (0A409348, 00000001, 00000001, 610739F0)
029ABC08  004F9677  (00579D30, 00000000, 029ABC44, 00000001)
029ABC48  004F4194  (00000001, 029ABC84, 029ABC88, 004F96D6)
029ABC88  004F453B  (00000001, 0A436AF8, 029ABCC8, 004FB278)
029ABCC8  004F46FE  (029ABD20, 029ABD24, 029ABD28, 029ABD2C)
029ABD38  004F5ADA  (0200122C, 00000001, 029ABD68, 004F6161)
029ABD68  004D19C1  (02018248, 029ABDA4, 00000001, 029ABDA4)
029ABDA8  004D1393  (FFFFFFFF, 00000001, 00000000, 00431A81)
029ABDE8  00431B25  (00000001, 00000000, 029ABE18, 00433393)
029ABE18  004333F2  (029ABEC8, 00000001, 029ABE98, 00432E74)
029ABE98  00432E80  (029ABEC8, 029ABEC8, 029ABEE8, 004D1393)
029ABF48  00431EE1  (00000001, 00000001, 00000000, 00431BAD)
029ABF68  00431D51  (FFFFFFFF, 00000050, 00000001, 0042D9CC)
End of stack trace (more stack frames may be present)

The given address appears to live in cygwin1.dll. Running insight under GDB
reveals that the program received a signal SIGSEGV, segmentation fault at
address 0x61036620 in _size_of_stack_reserve__ (). This address is in the
cygwin1.dll address space according to listdlls.exe So I downloaded the
source code for cygwin1.dll to try and find this function so that I could
back trace the offending code and maybe fix the problem. however I cannot
find in any of the source code this function or label. I have used grep to
look for this in both the Insight code base and that for cygwin1.dll. Can
anyone tell me where this function is coming from and how  I can track the
problem back. I am happy to try and find the problem but I need to know
where this function exists.

The problem only manifests itself when stepping through code on an ANGEL
target if the target code is just run then the problem does not occur.

Any pointers or help will be greatly appreciated and I will report back with
any findings especially if I can find the problem and fix it.

Andy Hare