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);
}
next 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