java crash from tom tromey

java crash from tom tromey

[Michael Elizabeth Chastain]

Here is a brain dump.

Tom T sent me a reproducible test case and I can reproduce it.

The problem happens with these commands:

  break 't::main TAB'
  run
  next next next step fini
  step step step step step
  print str
  run yes
  next

I have appended a backtrace.

My guess at the etiology is:

  gdb creates an objfile with name "<<anonymous objfile>>"
  and sect_index_test of -1.  I suspect that happens somewhere
  around the "print str" command but I don't really know enough
  about Java to say.

  It's essential to re-run the executable in order to blow away
  some sort of frame cache (another guess on my part).

  In the second run, gdb builds frames again.  It is in the middle
  of frame building when it calls dwarf2_frame_find_fde
  (frame #6 on the stack trace).

  dwarf2_frame_find_fde, gdb does this:

    ALL_OBJFILES (objfile)
      {
	...
	offset = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT(objfile));
	...
      }

  objfile has name "<<anonymous objfile>>" and sect_index_text of -1,
  which triggers the internal error inside the SECT_OFF_TEXT macro.

The test case fails with gdb 5.3 as well (but in a different place)
so this is a not a regression versus 5.3; it doesn't have to be fixed
in 6.0.  It still is high priority because it makes it a lot harder to
debug Java code.

David C suggested trying a gdb from 2003-05-15.  I did that, and
it works okay.

In the 2003-05-15 version of gdb, the objfile for "<<anonymous objfile>>"
initializes sect_index_text to -1, but dwarf2-frame.c did not exist
yet.  dwarf2-frame.c was created on 2003-05-31.

Can someone teach me about anonymous objfiles?

What are they for?

Tom has a hacky patch, which works for him:

  if (objfile->sect_index_text == -1)
    continue;

This might actually be the right patch!
It depends on the nature of anonymous objfiles.

Michael C

===

#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
#1  0x42028ac8 in raise () from /lib/i686/libc.so.6
#2  0x4202a019 in abort () from /lib/i686/libc.so.6
#3  0x0810f85f in internal_vproblem (problem=0x8263418, file=0x0, line=0,
    fmt=0x0, ap=0x0) at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/utils.c:785
#4  0x0810fa0e in internal_verror (file=0x0, line=0, fmt=0x0, ap=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/utils.c:799
#5  0x0810fa46 in internal_error ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/utils.c:808
#6  0x0815d9e5 in dwarf2_frame_find_fde ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/dwarf2-frame.c:1041
#7  0x0815d44f in dwarf2_frame_sniffer (next_frame=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/dwarf2-frame.c:714
#8  0x0811658a in frame_unwind_find_by_frame (next_frame=0x829f240)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/frame-unwind.c:86
#9  0x08113d37 in frame_register_unwind (frame=0x1, regnum=8,
    optimizedp=0x82a17c8, lvalp=0x829f240, addrp=0xbfffedd0,
    realnump=0xbfffedd4, bufferp=0xbfffedf8)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/frame.c:519
#10 0x0811423b in frame_unwind_register (frame=0x0, regnum=0, buf=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/frame.c:611
#11 0x0811f67c in i386_unwind_pc (gdbarch=0x82a8ff0, next_frame=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/i386-tdep.c:714
#12 0x080d34af in gdbarch_unwind_pc (gdbarch=0xbfffedf8, next_frame=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/gdbarch.c:4912
#13 0x08113b51 in frame_pc_unwind (this_frame=0xbfffedf8)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/frame.c:387
#14 0x080bef65 in step_over_function (ecs=0xbfffefc0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/infrun.c:2812
#15 0x080bdc8c in handle_inferior_event (ecs=0xbfffefc0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/infrun.c:2534
#16 0x080bd0df in wait_for_inferior ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/infrun.c:1052
#17 0x080bcea5 in proceed (addr=3221220856, siggnal=144, step=1)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/infrun.c:860
#18 0x080ba0af in step_1 (skip_subroutines=1, single_inst=0, count_string=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/infcmd.c:665
#19 0x080b9ed1 in next_command (count_string=0x0, from_tty=1)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/infcmd.c:559
#20 0x08079e99 in do_cfunc (c=0x0, args=0x0, from_tty=0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/cli/cli-decode.c:53
#21 0x0807bcbc in cmd_func (cmd=0x8292018, args=0x0, from_tty=0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/cli/cli-decode.c:1517
#22 0x0810d124 in execute_command (p=0x828646c "", from_tty=136912920)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:716
#23 0x080c88c1 in command_handler (command=0x8286468 "next")
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-top.c:500
#24 0x080c8cf5 in command_line_handler (rl=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-top.c:793
#25 0x081cd9c5 in rl_callback_read_char ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/readline/callback.c:123
#26 0x080c821b in rl_callback_read_char_wrapper (client_data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-top.c:166
#27 0x080c87ba in stdin_event_handler (error=0, client_data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-top.c:416
#28 0x080c7a9e in handle_file_event (event_file_desc=1108517584)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-loop.c:721
#29 0x080c7549 in process_event ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-loop.c:334
#30 0x080c75a8 in gdb_do_one_event (data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-loop.c:371
#31 0x0810cd61 in do_catch_errors (uiout=0x82a62c8, data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:497
#32 0x0810cc90 in catcher (func=0x810cd50 <do_catch_errors>,
    func_uiout=0x82a62c8, func_args=0xbffff390, func_val=0xbffff388,
    func_caught=0xbffff38c, errstring=0x0, mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:429
#33 0x0810cdba in catch_errors (func=0, func_args=0x0, errstring=0x0, mask=0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:509
#34 0x080c75e4 in start_event_loop ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-loop.c:397
#35 0x0807774b in captured_command_loop (data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/main.c:97
#36 0x0810cd61 in do_catch_errors (uiout=0x82a62c8, data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:497
#37 0x0810cc90 in catcher (func=0x810cd50 <do_catch_errors>,
    func_uiout=0x82a62c8, func_args=0xbffff500, func_val=0xbffff4f8,
    func_caught=0xbffff4fc, errstring=0x0, mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:429
#38 0x0810cdba in catch_errors (func=0, func_args=0x0, errstring=0x0, mask=0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:509
#39 0x08078114 in captured_main (data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/main.c:811
#40 0x0810cd61 in do_catch_errors (uiout=0x8261da0, data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:497
#41 0x0810cc90 in catcher (func=0x810cd50 <do_catch_errors>,
    func_uiout=0x8261da0, func_args=0xbffff7d0, func_val=0xbffff7c8,
    func_caught=0xbffff7cc, errstring=0x0, mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:429
#42 0x0810cdba in catch_errors (func=0, func_args=0x0, errstring=0x0, mask=0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:509
#43 0x08078591 in gdb_main (args=0x4212a2d0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/main.c:820
#44 0x0807772e in main (argc=0, argv=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/gdb.c:35
#45 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Re: java crash from tom tromey

[David Carlton]

On Wed, 6 Aug 2003 12:50:50 -0400, Michael Elizabeth Chastain <mec@shout.net> said:

> Can someone teach me about anonymous objfiles?

> What are they for?

I believe the Java dynamic class objfile is the only anonymous objfile
we have.  It's used as a place to store debug information that isn't
associated to any actual physical file.  Probably jv-lang.c's use of
it is a hack; having said that, our choices are, basically, either to
give up on Java debugging or to continue to deal with this hack.

I'm very glad that Tom has provided a reproducible test case for this;
I would suggest checking it in to our test suite ASAP.  My only qualm
with it is that I can't compile the test case myself, because my
installed GCJ (whatever came with Red Hat 8.0) doesn't know about
Arc2D.  Tom: is there some RPM that I can download to fix that (or I
could just recompile GCJ myself), or (better) is it possible to modify
the test case to use a more widely-available package?

David Carlton
carlton@kealia.com

Re: java crash from tom tromey

[Daniel Jacobowitz]

On Wed, Aug 06, 2003 at 12:50:50PM -0400, Michael Elizabeth Chastain wrote:
> Here is a brain dump.
> 
> Tom T sent me a reproducible test case and I can reproduce it.
> 
> The problem happens with these commands:
> 
>   break 't::main TAB'
>   run
>   next next next step fini
>   step step step step step
>   print str
>   run yes
>   next
> 
> I have appended a backtrace.
> 
> My guess at the etiology is:
> 
>   gdb creates an objfile with name "<<anonymous objfile>>"
>   and sect_index_test of -1.  I suspect that happens somewhere
>   around the "print str" command but I don't really know enough
>   about Java to say.
> 
>   It's essential to re-run the executable in order to blow away
>   some sort of frame cache (another guess on my part).
> 
>   In the second run, gdb builds frames again.  It is in the middle
>   of frame building when it calls dwarf2_frame_find_fde
>   (frame #6 on the stack trace).
> 
>   dwarf2_frame_find_fde, gdb does this:
> 
>     ALL_OBJFILES (objfile)
>       {
> 	...
> 	offset = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT(objfile));
> 	...
>       }
> 
>   objfile has name "<<anonymous objfile>>" and sect_index_text of -1,
>   which triggers the internal error inside the SECT_OFF_TEXT macro.

The correct fix is:
  - a patch, posted by Mark Kettenis:
Date: Sun, 13 Jul 2003 19:17:04 +0200 (CEST)
From: Mark Kettenis <kettenis@chello.nl>
Subject: [RFC/RFA] Per-objfile data mechanism    
  - Then, after that patch, move the check for FDEs in this objfile
before the check for section offsets.

The patch was approved but never checked in.  I'm guessing that Mark
has been too busy (or gotten caught up in the FSF's email troubles)
since we haven't heard from him in a few weeks.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: java crash from tom tromey

[Tom Tromey]

>>>>> "David" == David Carlton <carlton@kealia.com> writes:

David> Tom: is there some RPM that I can download to fix that (or I
David> could just recompile GCJ myself), or (better) is it possible to
David> modify the test case to use a more widely-available package?

I'm sure you can reproduce it with any java program.  I'm not sure
what the important parts of the recipe are, but it seems to be related
to printing values and/or stepping into the shared library.
Re-running the inferior usually then crashes gdb.  (Except for a brief
period of time where the cvs trunk was immune to this bug.)

BTW, as I recall (but keep in mind I'm not a gdb expert), the
anonymous objfiles were created to let the gdb user access some
classes that libgcj creates at runtime.  In particular, all array
classes are created dynamically.  (So are interpreted classes, but
nobody has taught gdb about those.)

Tom

Re: java crash from tom tromey

[Michael Elizabeth Chastain]

David Carlton writes:

> I'm very glad that Tom has provided a reproducible test case for this;
> I would suggest checking it in to our test suite ASAP.

It's my job to reduce it to a *.exp file, yes.

> My only qualm with it is that I can't compile the test case myself,
> because my installed GCJ (whatever came with Red Hat 8.0) doesn't
> know about Arc2D.

That would be gcj 3.2-7.

I suspect that for meaningful Java testing, you need to have a more
recent version of gcj anyways.  I am using gcj HEAD.

Anyways, the problem happens when a program calls type_from_class,
so I expect that I can make a test case that builds with
gcc 3.2-7.

Michael C