Bug 25565

Summary: gdb step will falsely exit for calling malloc function
Product: gdb Reporter: Anonymous <iamanonymous.cs>
Component: breakpointsAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: iamanonymous.cs, vries
Priority: P2    
Version: HEAD   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed: 2020-12-30 00:00:00

Description Anonymous 2020-02-16 16:00:22 UTC
$ gdb -v
GNU gdb (GDB) 9.0.50.20191210-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC) 

$ cat small.c

void *memset (void *, int, __SIZE_TYPE__);
void *malloc (__SIZE_TYPE__);

void main() 
{
  char *x = (char*)malloc(10);
  memset(x, 0, 10);
}

$ gcc -g --coverage small.c; gdb -q ./a.out
Reading symbols from ./a.out...
(gdb) start
Temporary breakpoint 1 at 0x1173: file small.c, line 7.
Starting program: /home/yibiao/cv-gcov/a.out 

Temporary breakpoint 1, main () at small.c:7
7	  char *x = (char*)malloc(10);
(gdb) step
[Inferior 1 (process 2356) exited with code 0240]
(gdb) q


##############################################
We can find that, type "start" and follows "step" the program will exit directly. 
However, it behaves as expected when compiling small.c without "--coverage", 


$ gcc -g  small.c; gdb -q ./a.out
Reading symbols from ./a.out...
(gdb) start
Temporary breakpoint 1 at 0x1151: file small.c, line 7.
Starting program: /home/yibiao/cv-gcov/a.out 

Temporary breakpoint 1, main () at small.c:7
7	  char *x = (char*)malloc(10);
(gdb) step
8	  memset(x, 0, 10);
(gdb) q
A debugging session is active.

	Inferior 1 [process 2376] will be killed.

Quit anyway? (y or n) y
Comment 1 Tom de Vries 2020-12-30 16:36:07 UTC
I tried with gcc 9.3.1, and both gdb trunk and gdb-10-branch.  Can't reproduce.

Does this reproduce for you with either gdb trunk, or gdb-10-branch (or, gdb-10.1-release if that's easier for you)?
Comment 2 Anonymous 2021-01-03 06:55:56 UTC
(In reply to Tom de Vries from comment #1)
> I tried with gcc 9.3.1, and both gdb trunk and gdb-10-branch.  Can't
> reproduce.
> 
> Does this reproduce for you with either gdb trunk, or gdb-10-branch (or,
> gdb-10.1-release if that's easier for you)?

Yes, this unexpected behavior is observed in the GNU gdb version of (GDB) 9.0.50.20191210-git.
Comment 3 Tom de Vries 2021-01-03 07:43:36 UTC
(In reply to Yibiao Yang from comment #2)
> (In reply to Tom de Vries from comment #1)
> > I tried with gcc 9.3.1, and both gdb trunk and gdb-10-branch.  Can't
> > reproduce.
> > 
> > Does this reproduce for you with either gdb trunk, or gdb-10-branch (or,
> > gdb-10.1-release if that's easier for you)?
> 
> Yes, this unexpected behavior is observed in the GNU gdb version of (GDB)
> 9.0.50.20191210-git.

The version you mention is neither gdb-10-branch, nor current trunk.
Comment 4 Tom de Vries 2021-01-06 12:28:17 UTC
Duplicate.

FTR, I had difficulty reproducing this because the problem is caused by the .plt.sec, which was not present in the exec I was looking at.

*** This bug has been marked as a duplicate of bug 27151 ***