[Bug macros/16855] New: Backtrace stopped: frame did not save the PC

[Bug macros/16855] New: Backtrace stopped: frame did not save the PC

[bkorb at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16855

            Bug ID: 16855
           Summary: Backtrace stopped: frame did not save the PC
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: macros
          Assignee: unassigned at sourceware dot org
          Reporter: bkorb at gnu dot org

I ran a gdb macro that chased through a linked list.  When done, the stack
trace was hosed.  I do not think that running a macro should _EVER_ trash the
stack.

(gdb) all bt

Thread 4 (Thread 0x7ffdda3e7700 (LWP 869)):
#0  0x0000003135032925 in raise () from /lib64/libc.so.6
#1  0x0000003135034105 in abort () from /lib64/libc.so.6
#2  0x000000313502ba4e in __assert_fail_base () from /lib64/libc.so.6
#3  0x000000313502bb10 in __assert_fail () from /lib64/libc.so.6
#4  0x000000000053b83d in rm_from_list_locked (le=0x17cfe340
<hostMemBufMngr+332112704>) at src/bfr/bfrFuncs.h:59
#5  0x000000000053b8b2 in get_from_list_locked (lh=0x17d14fe8
<hostMemBufMngr+332206056>) at src/bfr/bfrFuncs.h:77
#6  0x000000000053b98b in bfrGetCmdWrEntry (ssdId=3, q_idx=4, se_id=0) at
src/bfr/bfrFuncs.h:109
#7  0x000000000053bcdd in GetHotPrgQueWrPtr (ssdId=3) at
src/hostm/sciHwFacade.h:324
#8  0x0000000000546cde in ThreadFncWriteComplete (writerContext=0x6cc9cce0
<Ftl+141952>) at src/main/sciThreadWriteComplete.c:1966
#9  0x0000000000540cc8 in ThreadFncHotWriteComplete () at
src/main/sciThreadWriteComplete.c:460
#10 0x00000000004ef98f in sciFtl2Thread (arg=0x6cd34c70 <sciThreadParam+48>) at
src/main/sciFtlThread.c:423
#11 0x00000031354079d1 in start_thread () from /lib64/libpthread.so.0
#12 0x00000031350e8b6d in clone () from /lib64/libc.so.6

(gdb) source list.gdb
(gdb) list_count &cqd->bfrcd_list
   1 -> 0x17cfe2f8
[...]
 255 -> 0x17cfe388
found 255 elements in 0x17d14fc0
(gdb) bt
#0  0x0000000017cfe388 in hostMemBufMngr ()
#1  0x0000003135034105 in abort () from /lib64/libc.so.6
#2  0x000000313502ba4e in __assert_fail_base () from /lib64/libc.so.6
#3  0x000000313502bb10 in __assert_fail () from /lib64/libc.so.6
#4  0x000000000053b83d in rm_from_list_locked (le=0x17cfe340
<hostMemBufMngr+332112704>) at src/bfr/bfrFuncs.h:59
#5  0x000000000053b8b2 in get_from_list_locked (lh=0x17d14fe8
<hostMemBufMngr+332206056>) at src/bfr/bfrFuncs.h:77
#6  0x0000000017cfe2f8 in hostMemBufMngr ()
#7  0x0000000017879e58 in hostMemBufMngr ()
#8  0x0000000300000004 in ?? ()
#9  0x0000000017cfe388 in hostMemBufMngr ()
#10 0x0000000017879d30 in hostMemBufMngr ()
#11 0x0000000017879e58 in hostMemBufMngr ()
#12 0x0000000017d14fc0 in hostMemBufMngr ()
#13 0x0000000006694000 in hostMemBufMngr ()
#14 0x0000000017cfe340 in hostMemBufMngr ()
#15 0x00007ffdda3e6c90 in ?? ()
#16 0x000000000053bcdd in GetHotPrgQueWrPtr (ssdId=0) at
src/hostm/sciHwFacade.h:324
Backtrace stopped: frame did not save the PC



$ cat list.gdb
# -*- python -*-

define list_count
  set $head = $arg0
  set $elem = $head->ll_next
  set $ct   = 0

  while $elem != $head
    set $ct += 1
    set $pc  = (bfr_pendcmd_t*)$elem
#    set $cmd = (SFctlGenTagCmd*)&(((struct bfr_pendcmd*)$pc)->bfrpc_cmd)
#    printf "%4u -> %p tag 0x%X\n", $ct, $elem, $cmd->tag
    printf "%4u -> %p\n", $ct, $elem
    if $elem == $elem->ll_next
      printf "malformed element at %p\n", $elem
      p *$elem
      loop_break
    end
    set $elem = $elem->ll_next
  end

  printf "found %u elements in %p\n", $ct, $head
end

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/16855] Backtrace stopped: frame did not save the PC

[bkorb at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16855

--- Comment #1 from Bruce Korb <bkorb at gnu dot org> ---
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
(gdb) show configuration
This GDB was configured as follows:
   configure --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --without-expat
             --with-gdb-datadir=/usr/local/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --with-separate-debug-dir=/usr/local/lib/debug (relocatable)
             --with-zlib
             --without-babeltrace

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)


$ uname -a
Linux bkorb-vm 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3 21:39:27 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux


$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/16855] Backtrace stopped: frame did not save the PC

[bkorb at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16855

Bruce Korb <bkorb at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical

--- Comment #2 from Bruce Korb <bkorb at gnu dot org> ---
I bumped to critical because it sure is critical for me.  I am trying to debug
a large application and it takes 15 minutes to get it to where I need to futz
around.  The data structures are twisty and complicated enough I need to use
macros to search through them.  When I am done looking around, the result
cannot be resumed because the stack is trash.  Not good.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/16855] Backtrace stopped: frame did not save the PC

[peter.schauer at mytum dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=16855

Peter Schauer <peter.schauer at mytum dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.schauer at mytum dot de

--- Comment #3 from Peter Schauer <peter.schauer at mytum dot de> ---
I am pretty sure that the following line in your macro is the culprit:
    set $pc  = (bfr_pendcmd_t*)$elem
in which you are assigning to the current program counter of your
program, thus messing up the stack backtrace.

Please try to change it to
    set $my_pc  = (bfr_pendcmd_t*)$elem
#    set $cmd = (SFctlGenTagCmd*)&(((struct bfr_pendcmd*)$my_pc)->bfrpc_cmd)
or comment it out altogether, as it seems not to be used anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/16855] Backtrace stopped: frame did not save the PC

[bkorb at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16855

Bruce Korb <bkorb at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Bruce Korb <bkorb at gnu dot org> ---
You are correct, I was not considering a possible name conflict.
Henceforth, I'll just prefix them all with "_".  This also
explains why the structure information went away, requiring me
to always use the cast:  (bfr_pendcmd_t*)$pc
So this degrades to a documentation RFE: a caveat about
how to choose variable names.  :(

Thank you.

-- 
You are receiving this mail because:
You are on the CC list for the bug.