Bug 5730

Summary: stack trace does not show location information
Product: frysk Reporter: Tom Tromey <tromey>
Component: generalAssignee: Unassigned <frysk-bugzilla>
Status: ASSIGNED ---    
Severity: normal CC: mark
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Bug Depends on:    
Bug Blocks: 5707    
Attachments: patch disabling the crc check.

Description Tom Tromey 2008-02-05 20:13:16 UTC
I'm using x86 FC-6.  I built frysk from git today.

I ran fhpd on cc1 (part of gcc, also built today).
I built with -g.

When fhpd stopped at my breakpoint I tried "where".
Only the first frame shows location info:

(fhpd) where
#0 0x081e6371 in internal_error(const char * gmsgid)
/home/tromey/gnu/incremental/build/gcc/../../trunk/gcc/diagnostic.c#599
#1 0x081e6495 in fancy_abort () from
/home/tromey/gnu/incremental/install/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1
#2 0x0825ac9b in expand_expr_real_1 () from
/home/tromey/gnu/incremental/install/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1
[etc]

However, if I "down" and then "list", fhpd does properly show the source
to fancy_abort
Comment 1 Sami Wagiaalla 2008-02-05 20:50:03 UTC
hmm... same is true for bash:

[swagiaal@toner frysk-core]$ ./frysk/bindir/fhpd $$
Attached to process 4299
(fhpd) where
#0 0x00000030f549a835 in __GI___waitpid () from /lib64/libc-2.7.so
#1 0x0000000000435a11 in waitchld () from /bin/bash
#2 0x000000000043782e in wait_for () from /bin/bash
#3 0x000000000042b0a1 in execute_command_internal () from /bin/bash
#4 0x000000000042ba9f in execute_command () from /bin/bash
#5 0x000000000041b7b6 in reader_loop () from /bin/bash
#6 0x000000000041b309 in main () from /bin/bash
#7 0x00000030f541e074 in __libc_start_main () from /lib64/libc-2.7.so
#8 0x0000000000419179 in [unknown] from /bin/bash
(fhpd) down
#1 0x0000000000435a11 in waitchld () from /bin/bash
(fhpd) list
[0.0]
  2965     int call_set_current, last_stopped_job, job, children_exited,
waitpid_flags;
  2966     static int wcontinued = WCONTINUED;  /* run-time fix for glibc problem */
  2967   
  2968     call_set_current = children_exited = 0;
  2969     last_stopped_job = NO_JOB;
  2970   
  2971     do
  2972       {
  2973         /* We don't want to be notified about jobs stopping if job control
  2974           is not active.  XXX - was interactive_shell instead of
job_control */
->2975         waitpid_flags = (job_control && subshell_environment == 0)
  2976                          ? (WUNTRACED|wcontinued)
  2977                          : 0;
  2978         if (sigchld || block == 0)
  2979          waitpid_flags |= WNOHANG;
  2980         CHECK_TERMSIG;
  2981         pid = WAITPID (-1, &status, waitpid_flags);
  2982   
  2983         /* WCONTINUED may be rejected by waitpid as invalid even when
defined */
  2984         if (wcontinued && pid < 0 && errno == EINVAL)
(fhpd)
Comment 2 Sami Wagiaalla 2008-02-05 20:50:26 UTC
Looking into it.
Comment 3 Sami Wagiaalla 2008-02-06 18:29:09 UTC
looks like this was broken by this commit:
     bbf660ad5f803e000274503ad878040f4d604fef

I am still running git bisect to prove it

patch snippit:
@@ -92,13 +91,7 @@ class LibunwindFrame extends Frame
      * Returns the current program counter of this Frame.
      */
     public long getAddress() {
-	ProcInfo myInfo = cursor.getProcInfo();
-	ProcName myName = cursor.getProcName(0);
-    
-	if (myInfo.getError() != 0 || myName.getError() != 0)
-	    return 0;
-    
-	return myInfo.getStartIP() + myName.getOffset();
+      return cursor.getIP();
     }
Comment 4 Mark Wielaard 2008-02-06 18:58:55 UTC
(In reply to comment #3)
> looks like this was broken by this commit:
>      bbf660ad5f803e000274503ad878040f4d604fef
> 
> I am still running git bisect to prove it

That would be somewhat surprising. Although maybe there was some side effect
that explicitly set the location information from the frame.

But I think you are looking in the wrong place. In comment #1 it was pointed out
that the fhpd apparently knows the location information of the frame since a
down and list will correctly show the source code associated with the frame. So
it might make sense to look at where the fhpd list command gets this location
information and make sure that the where command that shows the stack frames
uses the same for printing the location string for each frame.
Comment 5 Sami Wagiaalla 2008-02-06 20:19:31 UTC
okay that patch is the fixer not the breaker stack traces before that patch had
incorrect addresses:

PSTACK:

[swagiaal@toner frysk.patches]$ pstack $$
#0  0x00000030f549a835 in waitpid () from /lib64/libc.so.6
#1  0x0000000000435a11 in ?? ()
#2  0x000000000043782e in wait_for ()
#3  0x000000000042b0a1 in execute_command_internal ()
#4  0x000000000042ba9f in execute_command ()
#5  0x000000000041b7b6 in reader_loop ()
#6  0x000000000041b309 in main ()

FRYSK BEFORE:

[swagiaal@toner frysk.patches]$ ./frysk-core/frysk/bindir/fstack $$
Task #4299
#0 0x00000030f549a835 in __GI___waitpid () from /lib64/libc-2.7.so
#1 0x00000000004359d1 in waitchld () from /bin/bash
#2 0x00000000004377ee in wait_for () from /bin/bash
#3 0x000000000042b071 in execute_command_internal () from /bin/bash
#4 0x000000000042ba5f in time_command () from /bin/bash
#5 0x000000000041b786 in reader_loop () from /bin/bash
#6 0x000000000041b2d9 in main () from /bin/bash
#7 0x00000030f541e074 in __libc_start_main () from /lib64/libc-2.7.so
#8 0x0000000000419179 in [unknown] from /bin/bash

FRYSK AFTER:

(fhpd) where
[0.0]
#0 0x00000030f549a835 in __GI___waitpid () from /lib64/libc-2.7.so
#1 0x0000000000435a11 in waitchld () from /bin/bash
#2 0x000000000043782e in wait_for () from /bin/bash
#3 0x000000000042b0a1 in execute_command_internal () from /bin/bash
#4 0x000000000042ba9f in execute_command () from /bin/bash
#5 0x000000000042c87f in execute_connection () from /bin/bash
#6 0x000000000042a8b3 in execute_command_internal () from /bin/bash
#7 0x000000000042ba9f in execute_command () from /bin/bash
#8 0x000000000041b7b6 in reader_loop () from /bin/bash
#9 0x000000000041b309 in main () from /bin/bash
#10 0x00000030f541e074 in __libc_start_main () from /lib64/libc-2.7.so
#11 0x0000000000419179 in [unknown] from /bin/bash
(fhpd) quit
Quitting...
Comment 6 Sami Wagiaalla 2008-02-13 15:20:00 UTC
looks like debuginfo files are faling something called a crc check
Comment 7 Sami Wagiaalla 2008-02-13 18:54:43 UTC
Created attachment 2260 [details]
patch disabling the crc check.

To confirm that this is the crc bug please test with the attached patch

if the problem is gone using the patch, please attach the output of the
following:
$crc32
/home/tromey/gnu/incremental/install/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1
and

$readelf -x 29
/home/tromey/gnu/incremental/install/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1

section 29 sould be the .gnu_debuglink
Comment 8 Tom Tromey 2008-02-19 21:21:50 UTC
I applied this patch, rebuilt, and reinstalled.

I still see the same problem -- the first item in the stack trace
shows the location, while the rest do not.
Comment 9 Stan Cox 2008-02-25 12:20:22 UTC
With bash:
printStackTrace->DebugInfoFrame.toPrint->getSubprogram->getScopes->
die.getScopes->dwarf_getscopes returns null for those frames with no position
info.  Sami I'll reassign it to me and poke around at it.  The crc info is okay
since, as is noted, list works fine.  
Comment 10 Stan Cox 2008-02-27 15:17:15 UTC
The problem goes away if caching is turned off in DwflCache.  I think the
problem might be DwarfDie caches only one DwflModule.  DebugInfoFrame#getScopes
-> getDwfl -> DwarfDie#getScopes where getScopes ends up failing for the
scenario where one frame is for a shared object and another is for the
executable because these are different modules.
Comment 11 Stan Cox 2008-03-05 03:03:15 UTC
I poked at the bash case and the debuginfo is found okay and the module info and
dwarf die info looks okay.  The stepping engine does a first pass at
DebugInfoFrame#getScopes and this pass works okay.  It is the later pass at
getScopes by where that fails.  Working on something else at the moment so I'll
release it if someone else wants to poke at it.