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)

Looking into it.

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();
     }

(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.

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...

looks like debuginfo files are faling something called a crc check

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

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.

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.  

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.

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.