NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/gnu/gdb/bug/1021

Text File | 1992-09-03 | 3.5 KB | 85 lines

Newsgroups: gnu.gdb.bug
Path: sparky!uunet!cis.ohio-state.edu!chico.UUCP!ngiannio
From: [e-mail] (Nicholas Gianniotis)
Subject: gdb 4.5 `bt' command intermittently fails on sparc-sun-sunos4.1 <repost>
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 03:01:54 GMT
Approved: [e-mail]
Lines: 72

I'm writing to report a problem I'm experiencing with gdb 4.5 running on a
Sun SPARCstation 2, kernel architecture "sun4c", application architecture
"sun4", under SunOS Release 4.1.1.

The compilers I used were the SunOS 4.1.1 bundled compiler (/usr/ucb/cc)
and gcc 2.1. Both compilers produced binaries that exihibited the same
problem. The programs were compiled with the "-g" option only, and to test
this problem, were linked both statically (-Bstatic) as well as
dynamically (-Bdynamic).  Both kinds of bindings exhibited the same
problem.

Gdb is being run from within emacs version 18.58.1.

The problem is that with some programs, once they are started under gdb,
gdb does not keep track of the call stack frames, so that a `bt' command
will always report that you are in the topmost frame. For example, with
the current project I am working on now (pfc), with a breakpoint at main:

    Breakpoint 1, main (argc=1, argv=0xf7fff4ec) at pfc.c:61
    (gdb) bt
    #0  main (argc=1, argv=0xf7fff4ec) at pfc.c:61
    (gdb)

After I step into the first function, and try `bt' again, this is the
result:

    (gdb) bt
    #0  pfc_get_env_parm (type=3, name=0x5c072 "PFC_DEBUG",
        default_value=0x5c07c "0", buffer=0x88a44, size=0) at pfc.c:344
    (gdb)

When this routine returns to the topmost frame, I step into another
function, with the same results:

    (gdb) bt
    #0  pfc_setup_publishers (publisher_list=0x8ccd0) at pfc_publish.c:35
    (gdb)

Basically, no matter where I stop my program, every time I issue the `bt'
command, gdb says that I am in the topmost frame (frame #0). Also, in some
cases (not shown above), gdb fails to print the values of the function's
parameters (it either shows empty parentheses () or question marks for the
value "parm=???").

Finally, this behaviour is not exhibited with _every_ program I try to
debug. A simple test-case program I wrote with several levels of function
calls did not cause gdb to exhibit this problem. I have seen this problem
with gdb infrequently in the past, but I'm not quite sure what causes it
or what makes it go away. I'm not sure whether it's the program, the
compiler or gdb; but an additional fact is that when I repeat the above
experiment with dbx (which I avoid using at any cost) and the same
executable, dbx successfully shows the call stack and the parameters at
any point I care to stop at and look.

I am wondering if other people using a similar development environment
have reported a similar condition, and if there is something I can do to
fix it.

If you have never heard of this problem before, I can send you a copy of
the program so you may try to reproduce it. But, since it is inconvenient
to do this (there are half a dozen files involved), and there is also a
chance you know what the problem is from my description, I'll refrain from
sending any source with this note.

Thank you & best regards,
Nick.
--
 Nicholas Gianniotis                              phone: [phone]
 CS First Boston (Japan) Limited                  fax:   [phone]
 Asahi Seimei Hibiya Building                     email: next8![e-mail]
 5-1, Yurakucho 1-chome, Chiyoda-ku, Tokyo 100, Japan.