RE: Am set up for debugging... what next.

RE: Am set up for debugging... what next.

[Troy Noble]

OK,

did that.  That got me further.

Now I'm able to get the debugger to start up, but not really.  In my
program's
stackdump file I see (my program is cygdebug.c, and it just simply
tries to strcat() a null pointer just so I can cause the debugger to kick
in):

      End of stack trace2734786 [main] cygdebug 1804
        try_to_debug: CYGWIN=error_start=c:\gdb-working\start_gdb.cmd

And a console window says:

    c:\work\cygdebug>set CYGWIN_TESTING=1
    c:\work\cygdebug>c:\cygwin\bin2\gdb.exe /work/cygdebug/cygdebug.exe 2172

However gdb never pops up a GUI window.  Watching Task Manager reveals that
gdb
does start and then slowly grows up to 266,800KB used over the span of about
a
minute and then dumps out a stack dump of its own (gdb.exe.stackdump) and
exits.  The stackdump looked useless, but I appended it below.

Been reading back through DJ Delorie's comments, and I'm not sure I
did this right... or even what he means by it:

   "... you'll need to build a copy of gdb that uses a \"debug\"
    version of cygwin, so as to avoid using the dll you're debugging."

Egor Duda said:

    "... place known-working copy of cygwin1.dll and normal unmodified
     copy of gdb.exe into x:\path\to\special\gdb\".

So which is the right approach?

I first tried with the current distribution copy of gdb.exe as well as
the current cygwin1-1.1.8-2.dll into this alternate directory I created,
but I always get the "memory 0x00000004 could not be read" thing that you
get
when you have two incompatible DLLs.  Then I tried to build another DLL off
the
same sources as the debug-enabled DLL, this time without the
--enable-debugging,
and the generated .dll file was still 4.7MB.  Am now trying with
--enable-debugging=no to see if I can get that to build a DLL with no
debug symbols.

Is that what DJ meant?

Would I then copy that DLL (current sources, but without the debug info)
into
the same directory with the unmodified gdb.exe?  Do I need to still rebuild
gdb.exe again, and if so, do I need any special configure options when doing
so?

Thanks for your help.  Troy


Here's the contents of gdb.exe.stackdump:


Stack trace:
Frame     Function  Args
025B5104  610494C9  (00000006, 000006B4, 025B52F8, 00000001)
025B5144  610494C9  (000006B4, 00000006, 025B5174, 610517E6)
025B5174  61049675  (000006B4, 00000006, 025B51B4, 6107DC4D)
025B5194  61085C8A  (610900A0, 000006B4, 00000006, 6107DC4D)
025B51C4  6107A63C  (610900A0, 00000006, 025B52F8, 610786FE)
025B51E4  6107A611  (00000006, 025B52F8, 025B5224, 66001093)
025B5204  61076D14  (00000028, 00000000, 025B5584, 6636B06D)
025B5224  660010AC  (66007D98, 00000028, 025B5264, 66007DC8)
025B5254  66007DE3  (00000028, 0046108D, 025B52A4, 6636C5EB)
025B52A4  6636C5F8  (025B5334, 025B52F8, 025B5344, 663685D5)
025B5344  663685E2  (0A729FC8, 0A02F4E0, 0000000E, 025B55A4)
025B53B4  0046196B  (025B5584, 6120A545, 00596170, 00461EA9)
025B5424  00461EBB  (610C662C, 77FC4A00, 00000000, 025B5584)
025B58A4  00461473  (004610B0, 0A02F4E0, 00000006, 0A030298)
025B58D4  0045EA4F  (025B5A34, 00000000, 025B59F4, 004875B4)
025B59F4  004875EE  (0045EA34, 025B5A34, 0045E8F8, 00000006)
End of stack trace (more stack frames may be present).../cyg



-----Original Message-----
From: Robert Collins [ mailto:robert.collins@itdomain.com.au ]
Sent: Monday, April 23, 2001 4:14 PM
To: Troy Noble; cygwin@cygwin.com
Subject: Re: Am set up for debugging... what next.


----- Original Message -----
From: "Troy Noble" <troy.noble@channelpoint.com>
To: <cygwin@cygwin.com>
Sent: Tuesday, April 24, 2001 7:56 AM
Subject: Am set up for debugging... what next.


> - created a /gdb-working/startup_gdb.cmd that reads:
>
>      set CYGWIN_TESTING=1
>      set PATH=c:\gdb-working;%PATH%
>      c:\gdb-working\gdb.exe %1 %2
>
> - in my .basrhc I set:
>
>      export CYGWIN='error_start=c:\gdb-working\start_gdb.cmd'
>
>      and started a new bash window of course, echo $CYGWIN
>      looks right.
>

Here's your problem: CYGWIN environment variable changes only affect
CYGWIN if they are set _before_ cygwinstarts.

If you're on NT, set cygwin via the system control panel or the .bat or
.cmd file that runs cygwin. If you run any cygwin daemons/services use
the system control panel. For 16 bit ^H^H^H^H^H^Hwin9x platforms set it
via autoexec.bat

Rob

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Am set up for debugging... what next.

[Christopher Faylor]

On Mon, Apr 23, 2001 at 05:55:49PM -0600, Troy Noble wrote:
>Egor Duda said:
>
>    "... place known-working copy of cygwin1.dll and normal unmodified
>     copy of gdb.exe into x:\path\to\special\gdb\".
>
>So which is the right approach?

This is *a* right approach.

>I first tried with the current distribution copy of gdb.exe as well as
>the current cygwin1-1.1.8-2.dll into this alternate directory I
>created, but I always get the "memory 0x00000004 could not be read"
>thing that you get when you have two incompatible DLLs.

>Then I tried to build another DLL off the same sources as the
>debug-enabled DLL, this time without the --enable-debugging, and the
>generated .dll file was still 4.7MB.  Am now trying with
>--enable-debugging=no to see if I can get that to build a DLL with no
>debug symbols.

This does not build a DLL with no debugging symbols.  It builds a version
of cygwin with extra debugging information as in more *code* in the DLL.
Look for the '#ifdef DEBUGGING' sprinkled throughout the cygwin sources.

There is no need for you to avoid building a cygwin1.dll with symbols.

From your description, it sounds like you are unable to even use the
gdb that you copied to its own directory.  You should be able to use
it to debug programs, e.g.  gdb -nw foo.exe .

However, you'll probably only be able to run it in non-gui mode, i.e.,
"gdb -nw".  You'll have to add the -nw to your gdb wrapper.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Am set up for debugging... what next.

[Robert Collins]

----- Original Message -----
From: "Troy Noble" <troy.noble@channelpoint.com>
To: <cygwin@cygwin.com>
Sent: Tuesday, April 24, 2001 7:56 AM
Subject: Am set up for debugging... what next.


> - created a /gdb-working/startup_gdb.cmd that reads:
>
>      set CYGWIN_TESTING=1
>      set PATH=c:\gdb-working;%PATH%
>      c:\gdb-working\gdb.exe %1 %2
>
> - in my .basrhc I set:
>
>      export CYGWIN='error_start=c:\gdb-working\start_gdb.cmd'
>
>      and started a new bash window of course, echo $CYGWIN
>      looks right.
>

Here's your problem: CYGWIN environment variable changes only affect
CYGWIN if they are set _before_ cygwinstarts.

If you're on NT, set cygwin via the system control panel or the .bat or
.cmd file that runs cygwin. If you run any cygwin daemons/services use
the system control panel. For 16 bit ^H^H^H^H^H^Hwin9x platforms set it
via autoexec.bat

Rob


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Am set up for debugging... what next.

[Troy Noble]

OK, I followed directions that Egor, Christopher, and DJ Delorie provided.
And now I need a little more direction.

- grabbed the latest DLL sources
- created an /obj directory, then ran
    /src/configure --enable-debugging --prefix=/install
- did a make
- copied gdb.exe and known-good (i.e. OLD) cygwin1.dll to /gdb-working
- shut everything down and copied the new-cygwin1.dll over cygwin1.dll
- created a /gdb-working/startup_gdb.cmd that reads:

     set CYGWIN_TESTING=1
     set PATH=c:\gdb-working;%PATH%
     c:\gdb-working\gdb.exe %1 %2

- in my .basrhc I set:

     export CYGWIN='error_start=c:\gdb-working\start_gdb.cmd'

     and started a new bash window of course, echo $CYGWIN
     looks right.

Now I run:

$ sleep 30 &
$ ps
$ kill -11 <PID of the sleep 30 command here>

I see:    [1]+  Segmentation fault      sleep 30

Shouldn't gdb pop up at this point?

What am I missing here?

Apologies if this is the wrong list.  Looked like the description
of cygwin-developers was for hard-core folks not just hobbyists
like myself who were trying to get to the root of a common
Access Violation so they can get back to being a user ;->

Thanks, Troy


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple