gdb freezes in malloc - c

Question

Suppose I have some C program like this:
#include <stdlib.h>
#include <stdbool.h>
int main()
{
while (true) {
void *p = malloc(1000);
free(p);
}
return 0;
}
and I attach to it with gdb like this gdb a.out PID. gdb successfully attaches to it but that I try to do something like call printf("bla bla bla") gdb freezes and if I press Ctrl^C I get this:
(gdb) call printf("bla bla bla")
^C
Program received signal SIGINT, Interrupt.
__lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(malloc) will be abandoned.
When the function is done executing, GDB will silently stop.
I suppose that this happens because my a.out was creating an object and acquired a lock inside malloc.c and in this moment I connected with gdb and tried to create string "bla bla bla" using malloc.
My question is how can I detect that I'm inside malloc.c and let my program finish this execution? I need to do it not inside command line but using some sort of gdb scripting (I only can execute commands inside gdb with -ex option).

Answer 1

The reason you're froze is probably a lock that's being held by your program, and is also required by printf. When you try to aquire it twice - you fail.
A possible WA is when breaking your program to call printf, just before you make the call, type finish - it will cause the current function to complete and return to the main frame. This will ensure the lock is free before you call printf.

Answer 2

If the 'finish' solution doesn't work for you. Here is another idea.
You can check if you are in malloc when you break the program. Based on the boolean in/out you skip calling the print commands. Here is a working example.
# gdb script: pygdb-logg.gdb
# easier interface for pygdb-logg.py stuff
# from within gdb: (gdb) source -v pygdb-logg.gdb
# from cdmline: gdb -x pygdb-logg.gdb -se test.exe
# first, "include" the python file:
source -v pygdb-logg.py
# define shorthand for inMalloc():
define inMalloc
python inMalloc()
end
The associated python file:
# gdb will 'recognize' this as python
# upon 'source pygdb-logg.py'
# however, from gdb functions still have
# to be called like:
# (gdb) python print logExecCapture("bt")
import sys
import gdb
import os
def logExecCapture(instr):
# /dev/shm - save file in RAM
ltxname="/dev/shm/c.log"
gdb.execute("set logging file "+ltxname) # lpfname
gdb.execute("set logging redirect on")
gdb.execute("set logging overwrite on")
gdb.execute("set logging on")
gdb.execute("bt")
gdb.execute("set logging off")
replyContents = open(ltxname, 'r').read() # read entire file
return replyContents
# in malloc?
def inMalloc():
isInMalloc = -1;
# as long as we don't find "Breakpoint" in report:
while isInMalloc == -1:
REP=logExecCapture("n")
#Look for calls that have '_malloc' in them
isInMalloc = REP.find("_malloc")
if(isInMalloc != -1):
# print ("Malloc:: ", isInMalloc, "\n", REP)
gdb.execute("set $inMalloc=1")
return True
else:
# print ("No Malloc:: ", isInMalloc, "\n", REP)
gdb.execute("set $inMalloc=0")
return False
gdb -x pygdb-logg.gdb -se test.exe
From the command line or script,
(gdb) inMalloc
(gdb) print $inMalloc
From an actual test program:
Program received signal SIGINT, Interrupt.
0x00007ffff7a94dba in _int_malloc (av=<optimized out>, bytes=1) at malloc.c:3806
3806 malloc.c: No such file or directory.
(gdb) inMalloc
(gdb) if $inMalloc
>print $inMalloc
>end
$1 = 1
I believe your script can use a similar 'if' structure to do/not do printf
Most of this was knocked off from here