Bug 4920 - Debug WIndow aborts when hovering over a variable when debugging bash
Summary: Debug WIndow aborts when hovering over a variable when debugging bash
Status: ASSIGNED
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks: 1633 3620
  Show dependency treegraph
 
Reported: 2007-08-13 19:01 UTC by Rick Moseley
Modified: 2008-04-23 20:57 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Moseley 2007-08-13 19:01:22 UTC
On my Fedora 7/x86 machine, with all of the latest yum updates I have the source
window aborting when I try to debug bash in the debug window.  bash does has its
debuginfo installed.  I do not have this problem on my Fedora 6/x86_64 machine,
all appears to work as advertised there.

To reproduce, make sure the bash-debuginfo package is installed and bring up a
bash shell somewhere.  Now bring up the Debug Window and attach to the bash
shell.  On the F7/x86 machine you click on frame containing "main.c", frame #14
on x86, frame #13 on x86_64.  Now scroll to around line #128("int login_shell =
0;") and move the cursor over the "login_shell" variable.  You shouldnow see a
"Aborted." message if you are on a F7/x86 machine.

If I do a "ulimit -c unlimited" before starting frysk to get a core dump and
then run "fstack -a" on the core dump I get:

./build/frysk-core/frysk/bindir/fstack -a core.9822 
Task #9822
#0 0x00220802 in [unknown] from /usr/lib/libgtkjava-2.8.so
#1 0x00000000 in [unknown] from Unknown
Task #9823
#0 0x00220802 in [unknown] from /usr/lib/libgtkjava-2.8.so
#1 0x00000000 in [unknown] from Unknown
Task #9824
#0 0x00220802 in [unknown] from /usr/lib/libgtkjava-2.8.so
#1 0x00000000 in [unknown] from Unknown


I do have the debuginfo loaded for all of the packages frysk uses thanks to
teresa's fdebuginfo utility.  I have also tried using strace, but the results
are indeterminate.  Here is what the end of starce looks like:

futex(0x9608d60, FUTEX_WAIT, 10303, NULL) = 0
futex(0x9608d8c, FUTEX_WAKE, 1)         = 0
gettid()                                = 9966
gettid()                                = 9966
tkill(9969, SIGIO)                      = 0
futex(0x9608d60, FUTEX_WAIT, 10305, NULL) = 0
futex(0x9608d8c, FUTEX_WAKE, 1)         = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(9966, 9966, SIGABRT)             = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT (core dumped) +++

The end of an ftrace looks like this:

10072.10074 <SYSCALL> rt_sigprocmask () 10072.10074 = 0
10072.10074 <SYSCALL> gettimeofday (-1228905960,0) 10072.10074 = 0
10072.10074 <SYSCALL> gettimeofday (-1228906040,0) 10072.10074 = 0
10072.10074 <SYSCALL> futex (0x9ff2d60,5,1,0x1) 10072.10074 = 1
 10072.10072 = 0
10072.10074 <SYSCALL> gettimeofday (-1228905944,0)10072.10072 <SYSCALL> futex
(0x9ff2d8c,1,1,0x9ff2d8c) 10072.10074 = 0
 10072.10072 = 0
10072.10074 <SYSCALL> setitimer (0,0xb6c061f4,NULL) 10072.10074 = 0
10072.10074 <SYSCALL> rt_sigaction () 10072.10074 = 0
10072.10074 <SYSCALL> rt_sigaction () 10072.10074 = 0
10072.10074 <SYSCALL> setitimer (0,0xb6c061f4,NULL) 10072.10074 = 0
10072.10074 <SYSCALL> gettid () 10072.10074 = 10074
10072.10074 <SYSCALL> rt_sigprocmask () 10072.10074 = 0
10072.10074 <SYSCALL> rt_sigprocmask () 10072.10074 = 0
10072.10074 <SYSCALL> waitpid (-1,0x876de24,1073741824)10072.10072 <SYSCALL>
rt_sigprocmask () 10072.10072 = 0
10072.10072 <SYSCALL> rt_sigprocmask () 10072.10072 = 0
10072.10072 <SYSCALL> tgkill () 10072.10072 = 0


trying to get a backtrace via gdb renders the following output:

(gdb) file ./build/frysk-gui/frysk/gui/FryskGui
Reading symbols from
/home/rmoseley/frysk-cvs/build/frysk-gui/frysk/gui/FryskGui...done.
(gdb) bt
#0  0x00110402 in __kernel_vsyscall ()
#1  0x4a950fa0 in ?? ()
#2  0x4aa77ff4 in ?? ()
#3  0xb7fcc8f0 in ?? ()
#4  0xbffd7038 in ?? ()
#5  0x4a9528b1 in ?? ()
#6  0x00000006 in ?? ()
#7  0xbffd6fac in ?? ()
#8  0x00000000 in ?? ()
Comment 1 Rick Moseley 2007-08-15 14:17:51 UTC
fhpd seems to have the same problem.  So this basically eliminates any UI code
or Java-Gnome.

To reproduce, bring up fhpd and attach it to a bash shell(bash-debuginfo should
be installed of course). Do a "down 13" and then a "examine
subshell_environment".  Here is what I get when I run this sequence:

./build/frysk-core/frysk/bindir/fhpd 9128
Attached to process 9128
(fhpd) down 13
#13 0x0805d7d0 in main () from /bin/bash
(fhpd) examine subshell_environment
procs 1 tasks 1
Aborted (core dumped)

In the above sequence I have set "ulimit -c unlimited" set before I run fhpd.

When trying to look at the core file with fstack I get the following error which
I will file in another bug:

./build/frysk-core/frysk/bindir/fstack -a core.18293
Task #18293
#0 0x00110402 in __kernel_vsyscall () from 
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
   at frysk.debuginfo.DebugInfoFrame.getSubprogram(DebugInfoFrame.java:81)
   at
frysk.debuginfo.DebugInfoStackFactory.printStackTrace(DebugInfoStackFactory.java:143)
   at
frysk.debuginfo.DebugInfoStackFactory.printTaskStackTrace(DebugInfoStackFactory.java:120)
   at frysk.util.StacktraceAction.printTasks(StacktraceAction.java:158)
   at
frysk.util.StacktraceAction.allExistingTasksCompleted(StacktraceAction.java:205)
   at frysk.proc.ProcCoreAction.<init>(ProcCoreAction.java:60)
   at frysk.bindir.fstack.stackCore(fstack.java:145)
   at frysk.bindir.fstack.access$1(fstack.java:140)
   at frysk.bindir.fstack$2.parseCores(fstack.java:165)
   at frysk.util.CommandlineParser.doParse(CommandlineParser.java:169)
   at frysk.util.CommandlineParser.parse(CommandlineParser.java:109)
   at frysk.bindir.fstack.main(fstack.java:257)


gdb core.18293
GNU gdb Red Hat Linux (6.6-15.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 "i386-redhat-linux-gnu"...
"/home/rmoseley/frysk-cvs/core.18293": not in executable format: File format not
recognized