This is the mail archive of the
mailing list for the GDB project.
memory alloc bug (release blocker?)
- From: dje at google dot com (Doug Evans)
- To: gdb at sourceware dot org
- Date: Fri, 26 Feb 2010 14:12:40 -0800 (PST)
- Subject: memory alloc bug (release blocker?)
[source = gdb 7.1. branch, target amd64-linux]
There's a memory allocation problem in gdb that I'm not sure how to fix.
It only affects target remote.
remote.c:remote_start_remote calls update_address_spaces which
frees all aspaces and reallocates them.
However, the initial inferior, created by initialize_inferiors,
already has an aspace and is left dangling.
The effect is that the program stops in _dl_debug_state
because gdb doesn't recognize it's stopped at a software breakpoint
because the address spaces don't match and so adjust_pc_after_break
doesn't backup pc.
One won't see this if the malloc/free in update_address_spaces
gets the same block back. I happened to have a gdb that got a
different block back. I managed to trigger the problem in another
gdb that "worked" with this patch:
diff -u -p -r1.4 progspace.c
--- progspace.c 19 Jan 2010 09:39:12 -0000 1.4
+++ progspace.c 26 Feb 2010 22:01:46 -0000
@@ -437,8 +437,12 @@ update_address_spaces (void)
+ void *p;
+ p = xmalloc (sizeof (*pspace->aspace));
if (aspace == NULL)
@@ -447,6 +451,8 @@ update_address_spaces (void)
pspace->aspace = new_address_space ();
+ free (p);
update_address_spaces has this comment:
It is assumed that there are no bound inferiors yet, otherwise,
they'd be left with stale referenced to released aspaces.
Given that there's always an inferior, and given that it's not clear
what it means, code-wise, to bind an inferior to a pspace/aspace,
I'm not sure what the right fix is. Is the assumption wrong,
and the bug is in update_address_spaces? Or is remote_start_remote
supposed to unbind all inferiors first? Or is initialize_inferiors
not supposed to create an inferior with a bound program-space? Or ... ?