Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Aleksandar Ristovski <aristovski@qnx.com>
To: gdb-patches@sources.redhat.com
Subject: dangling pointer in so_list
Date: Wed, 31 Aug 2011 20:01:00 -0000	[thread overview]
Message-ID: <j3m3u5$2m0$1@dough.gmane.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

Hello,

I run into a gdb crash examining a core file. This happened on gdb 7.3, 
on QNX. Unfortunately, I could not come up with a reproducible testcase 
on gnu/linux due to differences in dynamic linkers, but offer a detailed 
explanation instead:

What happened is that a process loaded the same shared object more than 
once. Then it crashed and a core was generated.

In the core, we had a link map specifying the same shared object more 
than once. While traversing the link map, gdb loaded shared objects 
(symbols), thus associating each so_list object with an objfile object. 
During the process, it detected duplicates and associated multiple 
so_list objects with the same objfile instance.

At this point, a change to solib-search-path causes gdb to reload 
symbols, and the crash happens: while traversing so_list in 
solib.c:reload_shared_libraries_1, in one iteration gdb calls 
'free_objfile' with a pointer to an instance of the objfile. In a 
subsequent iteration, it tries to do the same with, now, dangling 
pointer to the same objfile object. Not good.

The attached patch fixes the issue.


Thanks,

Aleksandar Ristovski
QNX Software Systems



ChangeLog:
<date>  Aleksandar Ristovski  <aristovski@qnx.com>

         * solib.c (reload_shared_libraries_1): Check whether objfile is 
used before
         freeing it.

[-- Attachment #2: dangling_objfile_in_so_list-201108311551.patch --]
[-- Type: text/x-patch, Size: 878 bytes --]

Index: gdb/solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.153
diff -u -p -r1.153 solib.c
--- gdb/solib.c	30 Aug 2011 02:48:05 -0000	1.153
+++ gdb/solib.c	31 Aug 2011 19:20:44 -0000
@@ -1226,7 +1226,22 @@ reload_shared_libraries_1 (int from_tty)
 	      && filename_cmp (found_pathname, so->so_name) != 0))
 	{
 	  if (so->objfile && ! (so->objfile->flags & OBJF_USERLOADED))
-	    free_objfile (so->objfile);
+	    {
+	      struct so_list *pivot;
+	      int used = 0;
+
+	      for (pivot = so_list_head; pivot != NULL; pivot = pivot->next)
+		{
+		  if (pivot != so && pivot->objfile == so->objfile)
+		    {
+		      used = 1;
+		      break;
+		    }
+		}
+
+	      if (!used)
+		free_objfile (so->objfile);
+	    }
 	  remove_target_sections (so->abfd);
 	  free_so_symbols (so);
 	}

             reply	other threads:[~2011-08-31 20:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-31 20:01 Aleksandar Ristovski [this message]
2011-08-31 20:12 ` Aleksandar Ristovski
2011-09-02 13:52   ` Aleksandar Ristovski
2011-09-02 20:45     ` Jan Kratochvil
2011-09-12 21:18       ` Aleksandar Ristovski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='j3m3u5$2m0$1@dough.gmane.org' \
    --to=aristovski@qnx.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox