'dbx' core dumps

'dbx' core dumps

Post by Dav » Thu, 19 Mar 1992 07:18:12



   Ever since I upgraded to AIX 3.1.7 I get frequent core dumps
while running dbx.  I am not doing any multiprocessing, and I
don't think I am asking dbx to do anything unreasonable.  
I do not remeber having any problems like this with version 3.1.5.

   Is this a well know problem?  Is there any fix?

Dave.

--

University of Massachusetts at Lowell
Department of Computer Science
1 University Avenue, Lowell, MA 01854

 
 
 

'dbx' core dumps

Post by Tom Armiste » Fri, 20 Mar 1992 13:48:15



>   Ever since I upgraded to AIX 3.1.7 I get frequent core dumps
>while running dbx.  I am not doing any multiprocessing, and I
>don't think I am asking dbx to do anything unreasonable.  
>I do not remeber having any problems like this with version 3.1.5.

>   Is this a well know problem?  Is there any fix?

>Dave.

Yea - go back to the old version of dbx...

I can core dump any AIX 3.1.? version of dbx.

Every night I say my prayers to the GNU gods, asking for an AIX version
of GDB...

Oh please!!!

Tom
--
Tom Armistead            | 2918 Dukeswood Dr.     | Garland, Tx.  75040



 
 
 

'dbx' core dumps

Post by Dav » Sat, 21 Mar 1992 03:44:51




>>   Ever since I upgraded to AIX 3.1.7 I get frequent core dumps
>>while running dbx...

>>   Is this a well know problem?  Is there any fix?

>Yea - go back to the old version of dbx...

How exactly could I do that?  

% ls -l /usr/bin/dbx
-r-xr-xr-x   2 bin      bin         4882 Mar 21 1991  /usr/bin/dbx

The file /usr/bin/dbx under 3.1.7 is the same as under 3.1.5 (at least
I think it is, I can't verify that right now).  Are there other files
that dbx uses that I would need to copy to go back to the old version?

Quote:>Every night I say my prayers to the GNU gods, asking for an AIX version
>of GDB...

Amen.

Quote:

>Tom
>--

Dave.

--

University of Massachusetts at Lowell
Department of Computer Science
1 University Avenue, Lowell, MA 01854

 
 
 

'dbx' core dumps

Post by Marc J. Stephens » Sun, 22 Mar 1992 05:37:36





>>>   Ever since I upgraded to AIX 3.1.7 I get frequent core dumps
>>>while running dbx...

>>>   Is this a well know problem?  Is there any fix?

Unless this was a very well known problem (which it could be I suppose), then
there is not nearly enough information to go on here.  What is the traceback
when you look at the core file (as in, dbx /usr/bin/dbx when you're in the
same directory as the core file, then run the 'where' subcommand)?

If you haven't already, call your problems into AIX software support.  I
would prefer that the maintainers had an opportunity to fix the problems,
but they need input first.

Quote:

>>Yea - go back to the old version of dbx...

>How exactly could I do that?  

>% ls -l /usr/bin/dbx
>-r-xr-xr-x   2 bin      bin         4882 Mar 21 1991  /usr/bin/dbx

>The file /usr/bin/dbx under 3.1.7 is the same as under 3.1.5 (at least
>I think it is, I can't verify that right now).  Are there other files
>that dbx uses that I would need to copy to go back to the old version?

The bulk of the logic in dbx is in libdbx.a, which resides in /usr/lib
in 3.1 and in /usr/ccs/lib in 3.2 (with a /usr/lib symlink for
compatibility).  /usr/bin/dbx is basically just a main program.  The
size of /usr/bin/dbx should give it away that that's not the whole thing.

Quote:

>>Every night I say my prayers to the GNU gods, asking for an AIX version
>>of GDB...

>Amen.

Some of the very things which gives AIX some of its versatility give
de*s a fairly difficult time.  The simple fact that the modules
(including the original exec'ed program) are relocated from their link
addresses is something which most UN*X de*s aren't expecting, and
that must be dealt with first.  Start adding in shared libraries and
dynamically loading and unloading of modules, and there's some more
trouble.  Add in multiprocess debugging and process attachment/detachment
and there's some more headaches (if you want to try to handle that stuff).

I'm not sure why it has taken people so long to produce a gdb aside from
the aforementioned problems.  The symbolic debugging information is basically
in BSD-style dbx stabstrings, though the general object file format is
an extended form of COFF.  It seems like that part should have been relatively
straightforward for gdb to handle. It seems like it should not have been
too difficult to produce a gdb which could handle debugging the
exec'ed program but no shared libraries.

One intention of using familiar debug information was that people could
port their preferred de*s (such as gdb or whatever else is out there)
as painlessly as possible.  Maybe one will come soon for you.

>>Tom
>>--

>Dave.

>--

>University of Massachusetts at Lowell
>Department of Computer Science
>1 University Avenue, Lowell, MA 01854

--
Marc Stephenson               IBM PSPA (Personal System Programming - Austin,TX)
DISCLAIMER: The content of this posting is independent of official IBM position.