Bug 233616 - gdb doesn't always display local variables in gcj-compiled applications
gdb doesn't always display local variables in gcj-compiled applications
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
bzcl34nup
: Reopened
Depends On:
Blocks: 233628
  Show dependency treegraph
 
Reported: 2007-03-23 09:48 EDT by Andrew Haley
Modified: 2008-05-06 21:19 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 21:19:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Haley 2007-03-23 09:48:37 EDT
The problem is that gdb can't display local variables in Java mode, but it can
display them in C++ mode.

Here's a simple Java program:

import java.io.*;

public class fh
{
  public static  void main(String[] argv) throws Exception
  {
    PrintWriter p = new PrintWriter("foobar");
    p.println("Arse");
    p.close();
  }
}

Compile it like this:

/usr/bin/gcj fh.java --main=fh -g

The debug it like this:

 $ gdb ./a.out 
(gdb) b 'fh.main(java.lang.String[])void' 
Breakpoint 1 at 0x400c6b: file fh.java, line 7.
(gdb) r
Starting program: /home/aph/a.out 
Breakpoint 1, fh.main(java.lang.String[])void (argv=@2aaaaad08ee0) at fh.java:7
7           PrintWriter p = new PrintWriter("foobar");
Current language:  auto; currently java
(gdb) n
8           p.println("Arse");
(gdb) p p
$1 = warning: RTTI symbol not found for class 'java::io::PrintWriter'
Cannot access memory at address 0x0
(gdb) set lang c++
Warning: the current language does not match this frame.
(gdb) p p
$2 = (class java.io.PrintWriter *) 0x2aaaae549160

Note that gdb returns a spurious "RTTI symbol not found" message and it fails to
 display the symbol's value.
Comment 1 Andrew Haley 2007-03-23 10:02:46 EDT
This works on i686:

Breakpoint 1, fh.main(java.lang.String[])void (argv=@2bf70) at fh.java:7
7           PrintWriter p = new PrintWriter("foobar");
Current language:  auto; currently java
(gdb) n
8           p.println("Arse");
(gdb) p p
$1 = java.io.PrintWriter@953c0
Comment 2 Jan Kratochvil 2007-03-23 18:40:12 EDT
Could you please update the Fedora Core version?
"test2" was I believe for Fedora Core 1.
Not reproducible on RawHide.x86_64:
gdb-6.6-7.fc7.x86_64
gcc-java-4.1.2-5.x86_64
Not reproducible on FC6.x86_64:
gdb-6.5-15.fc6.x86_64
gcc-java-4.1.1-51.fc6.x86_64
Not reproducible on FC5.x86_64:
gdb-6.3.0.0-1.134.fc5.x86_64
gcc-java-4.1.1-1.fc5.x86_64

In all cases this script (for some versions two 'n's there or a different
function name syntax for FC5):

file ./a.out
b 'fh.main(java.lang.String[])void'
r
n
p p
set lang c++
p p
quit

prints:
Current language:  auto; currently java
8           p.println("Arse");
$1 = java.io.PrintWriter@2aaaaea0f3e0
Warning: the current language does not match this frame.
$2 = (struct java.io.PrintWriter *) 0x2aaaaea0f3e0
Comment 3 Andrew Haley 2007-03-24 07:05:31 EDT
I am using F7 Test 2.

If there were an "F7 Test 2" on the drop-down list I'd pick that.  There isn't;
I don't know why.

My result with gdb 6.6-7.fc7rh gcc-java-4.1.2-5 and your script is:

Breakpoint 1 at 0x400c6b: file fh.java, line 7.
[Thread debugging using libthread_db enabled]
[New Thread 46912498391408 (LWP 19310)]
[New Thread 1084229952 (LWP 19325)]
[Switching to Thread 46912498391408 (LWP 19310)]

Breakpoint 1, fh.main(java.lang.String[])void (argv=@2aaaaad08ee0) at fh.java:7
7           PrintWriter p = new PrintWriter("foobar");
Current language:  auto; currently java
8           p.println("Arse");
$1 = 
warning: RTTI symbol not found for class 'java::io::PrintWriter'
/home/aph/.gdbinit:5: Error in sourced command file:
Cannot access memory at address 0x0
Comment 4 Jan Kratochvil 2007-03-24 08:25:36 EDT
It should be "devel" according to
https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00095.html

It is still not reproducible for me, though, there may be other package
dependencies.  Please reproduce it on RH accessible RawHide.x86_64 machine.
Going to check more later.
Comment 12 Andrew Haley 2007-03-26 08:05:21 EDT
This looks like a gdb regression between gdb 6.6-3 and 6.6-7.

Running on the same binary:

GNU gdb Red Hat Linux (6.6-3.fc7rh)
Breakpoint 1, fh.main(java.lang.String[])void (argv=@2aaaaaaf8ee0) at fh.java:7
7           PrintWriter p = new PrintWriter("foobar");
Current language:  auto; currently java
8           p.println("Arse");
$1 = java.io.PrintWriter@2aaaae2d6800
Warning: the current language does not match this frame.
$2 = (struct java.io.PrintWriter *) 0x2aaaae2d6800

GNU gdb Red Hat Linux (6.6-7.fc7rh)
Breakpoint 1, fh.main(java.lang.String[])void (argv=@2aaaaaafaee0) at fh.java:7
7           PrintWriter p = new PrintWriter("foobar");
Current language:  auto; currently java
8           p.println("Arse");
$1 = 
warning: RTTI symbol not found for class 'java::io::PrintWriter'
/home/aph/.gdbinit:5: Error in sourced command file:
Cannot access memory at address 0x0
Comment 13 Andrew Haley 2007-03-26 08:32:55 EDT
I've downgraded the box on which this fails to 6.6-3.fc7rh, and it still fails.
So, this doesn't seem to vary with the version of gdb.  On one machine with gdb
version 6.6-3.fc7rh I get correct results, and on another machine with the exact
same version of gdb I get incorrect results.  This is when debugging the same
binary.

What else is there?  Kernel changes, perhaps?
Comment 14 Jan Kratochvil 2007-03-26 09:44:54 EDT
These were the packages with files accessed during the gcj+gdb run:
binutils-2.17.50.0.9-1.x86_64
gcc-4.1.2-1.x86_64
gcc-java-4.1.2-1.x86_64
glibc-2.5.90-17.x86_64
glibc-common-2.5.90-17.x86_64
glibc-devel-2.5.90-17.x86_64
libgcc-4.1.2-1.x86_64
libgcj-4.1.2-1.i386
libgcj-4.1.2-1.x86_64
libgcj-devel-4.1.2-1.x86_64
ncurses-5.6-5.20070217.fc7.i386
ncurses-5.6-5.20070217.fc7.x86_64
zlib-1.2.3-8.fc7.x86_64
zlib-devel-1.2.3-8.fc7.x86_64

Please also check there ARE / ARE NOT installed the -debuginfo packages the same
way for the reproducibility.  In my nonreproducible testcases there were NO
-debuginfo packages installed.

It would be also useful to attach here at least the resuling `a.out' file if it
is reproducible with it.
Comment 15 Andrew Haley 2007-03-26 10:31:28 EDT
Yes, it's the debuginfo:

gdb ./a.out
GNU gdb Red Hat Linux (6.6-3.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1 at 0x400c6b: file fh.java, line 7.
[Thread debugging using libthread_db enabled]
[New Thread 46912496237696 (LWP 2977)]
[New Thread 1084229952 (LWP 3080)]
[Switching to Thread 46912496237696 (LWP 2977)]

Breakpoint 1, fh.main(java.lang.String[])void (argv=@2aaaaaafaee0) at fh.java:7
7           PrintWriter p = new PrintWriter("foobar");
Current language:  auto; currently java
8           p.println("Arse");
$1 = 
warning: RTTI symbol not found for class 'java::io::PrintWriter'
/home/aph/.gdbinit:5: Error in sourced command file:
Cannot access memory at address 0x0
(gdb) quit
The program is running.  Exit anyway? (y or n) y
zorro:~ $ sudo rpm -e gcc-debuginfo
zorro:~ $ /usr/bin/gdb ./a.out 
GNU gdb Red Hat Linux (6.6-3.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1 at 0x400c6b: file fh.java, line 7.
[Thread debugging using libthread_db enabled]
[New Thread 46912496237696 (LWP 3144)]
[New Thread 1084229952 (LWP 3147)]
[Switching to Thread 46912496237696 (LWP 3144)]

Breakpoint 1, fh.main(java.lang.String[])void (argv=@2aaaaaafaee0) at fh.java:7
7           PrintWriter p = new PrintWriter("foobar");
Current language:  auto; currently java
8           p.println("Arse");
$1 = java.io.PrintWriter@2aaaae33d160
Warning: the current language does not match this frame.
$2 = (struct java.io.PrintWriter *) 0x2aaaae33d160
The program is running.  Exit anyway? (y or n) [answered Y; input not from terminal]
Comment 16 Jan Kratochvil 2007-04-02 12:12:21 EDT
libjava part of gcc is now being compiled with -fno-rtti.
Enabling it fails the libjava compilation.
I believe it is a bug in GDB it should not require existing RTTI for C++/Java
data and use just the static DWARF info instead.

I was told I should reassign it to GCC and thus doing so.
I expect the right way would be to fix GDB instead so please feel free to
reassign it back.
Comment 17 Jan Kratochvil 2007-04-02 12:14:43 EDT
Sorry, Chris Feist, it was a typo.
Comment 19 Tom Tromey 2007-04-02 18:20:39 EDT
libgcj is built with -fno-rtti on purpose; gcj does not generate C++ RTTI,
nor will it.

gdb could also use the libgcj reflection info to print things.
I have no idea how hard this is though.
Comment 20 Jan Kratochvil 2007-04-02 18:45:17 EDT
(In reply to comment #19)
> libgcj is built with -fno-rtti on purpose; gcj does not generate C++ RTTI,
> nor will it.

Thanks, nice to know it really should not be needed for libjava and static DWARF
is enough.

> gdb could also use the libgcj reflection info to print things.
> I have no idea how hard this is though.

That would be a second step - FEAT, though.
Comment 21 Bug Zapper 2008-04-03 19:45:33 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 22 Bug Zapper 2008-05-06 21:19:33 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.