Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!ai-lab!dead!ead.dsa.com!schorr
From: schorr@ead.dsa.com (Andrew J. Schorr)
Newsgroups: comp.unix.aix
Subject: AIX 3.1 dbx problem
Keywords: AIX dbx virtual memory SLOW
Message-ID: <1991May20.132212@ead.dsa.com>
Date: 20 May 91 17:22:12 GMT
Sender: news@ead.dsa.com
Reply-To: schorr@ead.dsa.com (Andrew J. Schorr)
Organization: Daiwa Securities America, New York
Lines: 35

The dbx in AIX 3.1.5 (probably previous releases, also) does not
cut the mustard for us, and I'm wondering if others have the same
problems, comments, etc.

Here is the scenario:
I have a large program (1 Mbyte binary, links in many shared libraries,
totalling around 10 Mbytes) which crashes with the message "Memory fault".
This same program runs fine on a Sun, under SunOS 4.1.1.  This suggests
that either the code is buggy, and just happens to work on the Sun,
or the AIX compiler is generating bad code.  In any case, I thought that
I would debug it and see what was happening.  I fired up dbx.  Many minutes
later, while it was still reading the symbolic information (according to
the message it prints), it died (the system ran out of virtual memory).

This leaves me with 2 problems:
1. dbx is using a huge amount of virtual memory.  There were approximately
   30 Mbytes of virtual memory available when I ran dbx.  I have no idea
   how much I would need in order for dbx to work.
2. What is dbx doing on start-up that takes so long?  My guess is that
   it's building symbol tables (& related activities) for every module
   in the program, as well as in the shared libraries (which, I should
   mention, were compiled with the -g flag).  If that is the case, why does
   dbx need to resolve all this info at start-up?  Can't it delay this stuff
   and do it as necessary (on a demand basis)?
Perhaps compiling the shared libraries without -g would eliminate 
this problem?  But even so, that shouldn't be necessary.

Any comments?

-Andy

P.S. On the positive side, linking programs with shared (dynamic) libraries
is much faster (and uses much less memory) than linking with normal, static
libraries.  Presumably this is because much of the symbol resolution has
already occurred.