Bug 19902 - gdb wrongly steps back on this code (my unique_ptr)
Summary: gdb wrongly steps back on this code (my unique_ptr)
Status: RESOLVED INVALID
Alias: None
Product: gdb
Classification: Unclassified
Component: c++ (show other bugs)
Version: 7.10
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-03 15:56 UTC by Askar Safin
Modified: 2016-08-08 18:50 UTC (History)
1 user (show)

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


Attachments
source (345 bytes, text/x-c++src)
2016-04-03 15:56 UTC, Askar Safin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Askar Safin 2016-04-03 15:56:21 UTC
Created attachment 9150 [details]
source

On attached c++ source I got this:

ideal-os:/# gdb /tmp/a.out
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/a.out...done.
(gdb) start
Temporary breakpoint 1 at 0x40073f: file /proc/1/root/tmp/a.cpp, line 71.
Starting program: /tmp/a.out 

Temporary breakpoint 1, main () at /proc/1/root/tmp/a.cpp:71
71        unique<int> a, b;
(gdb) n
72        unique<int> c = std::move (a);
(gdb) s
std::move<unique<int>&> (__t=...) at /usr/include/c++/5/bits/move.h:102
102         { return static_cast<typename std::remove_reference<_Tp>::type&&>(__t); }
(gdb) 
main () at /proc/1/root/tmp/a.cpp:73
73        a = std::move (b);
(gdb) 
std::move<unique<int>&> (__t=...) at /usr/include/c++/5/bits/move.h:102
102         { return static_cast<typename std::remove_reference<_Tp>::type&&>(__t); }
(gdb) 
main () at /proc/1/root/tmp/a.cpp:72
72        unique<int> c = std::move (a);
(gdb) c
Continuing.
*** Error in `/tmp/a.out': double free or corruption (fasttop): 0x0000000000612c40 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x71ff5)[0x7ffff7219ff5]
/lib/x86_64-linux-gnu/libc.so.6(+0x77946)[0x7ffff721f946]
/lib/x86_64-linux-gnu/libc.so.6(+0x7812e)[0x7ffff722012e]
/tmp/a.out[0x40081c]
/tmp/a.out[0x4007a1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffff71c8610]
/tmp/a.out[0x400669]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:07 9897783                            /tmp/a.out
00600000-00601000 rw-p 00000000 08:07 9897783                            /tmp/a.out
00601000-00633000 rw-p 00000000 00:00 0                                  [heap]
7ffff0000000-7ffff0021000 rw-p 00000000 00:00 0 
7ffff0021000-7ffff4000000 ---p 00000000 00:00 0 
7ffff71a8000-7ffff7342000 r-xp 00000000 08:07 9830578                    /lib/x86_64-linux-gnu/libc-2.22.so
7ffff7342000-7ffff7542000 ---p 0019a000 08:07 9830578                    /lib/x86_64-linux-gnu/libc-2.22.so
7ffff7542000-7ffff7546000 r--p 0019a000 08:07 9830578                    /lib/x86_64-linux-gnu/libc-2.22.so
7ffff7546000-7ffff7548000 rw-p 0019e000 08:07 9830578                    /lib/x86_64-linux-gnu/libc-2.22.so
7ffff7548000-7ffff754c000 rw-p 00000000 00:00 0 
7ffff754c000-7ffff7562000 r-xp 00000000 08:07 9831005                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7562000-7ffff7761000 ---p 00016000 08:07 9831005                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7761000-7ffff7762000 rw-p 00015000 08:07 9831005                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7762000-7ffff785f000 r-xp 00000000 08:07 9830583                    /lib/x86_64-linux-gnu/libm-2.22.so
7ffff785f000-7ffff7a5e000 ---p 000fd000 08:07 9830583                    /lib/x86_64-linux-gnu/libm-2.22.so
7ffff7a5e000-7ffff7a5f000 r--p 000fc000 08:07 9830583                    /lib/x86_64-linux-gnu/libm-2.22.so
7ffff7a5f000-7ffff7a60000 rw-p 000fd000 08:07 9830583                    /lib/x86_64-linux-gnu/libm-2.22.so
7ffff7a60000-7ffff7bcb000 r-xp 00000000 08:07 9928888                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7ffff7bcb000-7ffff7dcb000 ---p 0016b000 08:07 9928888                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7ffff7dcb000-7ffff7dd5000 r--p 0016b000 08:07 9928888                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7ffff7dd5000-7ffff7dd7000 rw-p 00175000 08:07 9928888                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7ffff7dd7000-7ffff7ddb000 rw-p 00000000 00:00 0 
7ffff7ddb000-7ffff7dfd000 r-xp 00000000 08:07 9830574                    /lib/x86_64-linux-gnu/ld-2.22.so
7ffff7fea000-7ffff7fef000 rw-p 00000000 00:00 0 
7ffff7ff5000-7ffff7ff8000 rw-p 00000000 00:00 0 
7ffff7ff8000-7ffff7ffa000 r-xp 00000000 00:00 0                          [vdso]
7ffff7ffa000-7ffff7ffc000 r--p 00000000 00:00 0                          [vvar]
7ffff7ffc000-7ffff7ffd000 r--p 00021000 08:07 9830574                    /lib/x86_64-linux-gnu/ld-2.22.so
7ffff7ffd000-7ffff7ffe000 rw-p 00022000 08:07 9830574                    /lib/x86_64-linux-gnu/ld-2.22.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Program received signal SIGABRT, Aborted.
0x00007ffff71db478 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) c
Continuing.

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) quit

Yes, my program segfaults, but this is not the point. Problem is the following: I got to line 73 and then to line 72 again. I. e. wrong ordering of commands.

OS is debian stretch running in chroot environment on debian jessie. gdb is debian 7.10-1+b1, g++-5 is debian 5.3.1-13. g++ -v output is:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-13' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160323 (Debian 5.3.1-13) 

command line: g++ -g -std=c++1z -o /tmp/a.out /proc/1/root/tmp/a.cpp
Comment 1 Askar Safin 2016-04-03 17:25:43 UTC
Of course, attached code is very buggy. Copy constructors etc have wrong signatures. Maybe there are other bugs. It is just example of code with wrong command ordering in gdb
Comment 2 Askar Safin 2016-05-28 15:16:30 UTC
Now it seems for me this is not a bug. gdb steps to line 72 after line 73 just to show me that it is going to call c's destructor. Still this is very strange behavior. You probably should add this case to FAQ or even to gdb interface itself
Comment 3 Pedro Alves 2016-08-08 18:50:22 UTC
Alright, closing then.

There's nothing GDB can do here.  It merely single-step until it reaches a different line, according to the debug information produced by the compiler.