* [RFC] Detect loops in the solib chain
@ 2008-07-17 20:57 Daniel Jacobowitz
2008-07-17 21:07 ` Stan Shebs
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Daniel Jacobowitz @ 2008-07-17 20:57 UTC (permalink / raw)
To: gdb-patches
A MontaVista customer had a very interestingly corrupt core file -
there was a stray pointer in the list of loaded shared libraries. But
it pointed to something which looked enough like a shared library
entry to get by, and the bad entry's l_next pointed back at the
corrupted entry that led to it. So around and around we went, adding
the same two libraries to the list. When the solib chain reached
about 2GB, GDB was killed.
The best I could think of was to detect cycles. It's a linked list
that we're walking, so without cycles we're bounded by the amount of
memory in the debuggee; it's by no means foolproof, but this should
prevent more cases of wandering off into the woods than we do now.
Does this look OK? Tested on x86_64-linux, no regressions.
--
Daniel Jacobowitz
CodeSourcery
2008-07-17 Daniel Jacobowitz <dan@codesourcery.com>
* solib-svr4.c (svr4_current_sos): Check for cycles in the list.
Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.87
diff -u -p -r1.87 solib-svr4.c
--- solib-svr4.c 3 Jun 2008 12:59:37 -0000 1.87
+++ solib-svr4.c 17 Jul 2008 20:36:23 -0000
@@ -751,7 +751,8 @@ static struct so_list *
svr4_current_sos (void)
{
CORE_ADDR lm;
- struct so_list *head = 0;
+ int loop_flag = 0;
+ struct so_list *head = 0, *loop_so_list = NULL;
struct so_list **link_ptr = &head;
CORE_ADDR ldsomap = 0;
@@ -825,6 +826,13 @@ svr4_current_sos (void)
new->next = 0;
*link_ptr = new;
link_ptr = &new->next;
+
+ /* Advance loop_so_list at half speed. */
+ if (loop_so_list == NULL)
+ loop_so_list = new;
+ else if (loop_flag)
+ loop_so_list = loop_so_list->next;
+ loop_flag = !loop_flag;
}
}
@@ -836,6 +844,13 @@ svr4_current_sos (void)
lm = ldsomap = solib_svr4_r_ldsomap ();
discard_cleanups (old_chain);
+
+ /* Check for cycles in the list. */
+ if (loop_so_list && loop_so_list->lm_info->lm_addr == lm)
+ {
+ warning (_("Corrupt shared library list"));
+ break;
+ }
}
if (head == NULL)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 20:57 [RFC] Detect loops in the solib chain Daniel Jacobowitz
@ 2008-07-17 21:07 ` Stan Shebs
2008-07-17 21:15 ` Thiago Jung Bauermann
2008-07-17 21:18 ` Paul Pluzhnikov
2 siblings, 0 replies; 18+ messages in thread
From: Stan Shebs @ 2008-07-17 21:07 UTC (permalink / raw)
To: gdb-patches
Daniel Jacobowitz wrote:
> A MontaVista customer had a very interestingly corrupt core file -
> there was a stray pointer in the list of loaded shared libraries. But
> it pointed to something which looked enough like a shared library
> entry to get by, and the bad entry's l_next pointed back at the
> corrupted entry that led to it. So around and around we went, adding
> the same two libraries to the list. When the solib chain reached
> about 2GB, GDB was killed.
>
> The best I could think of was to detect cycles. It's a linked list
> that we're walking, so without cycles we're bounded by the amount of
> memory in the debuggee; it's by no means foolproof, but this should
> prevent more cases of wandering off into the woods than we do now.
>
> Does this look OK? Tested on x86_64-linux, no regressions.
>
What, no test case? :-) Anyway, it looks OK to me.
(You could make a little script to scribble on the executable...)
Stan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 20:57 [RFC] Detect loops in the solib chain Daniel Jacobowitz
2008-07-17 21:07 ` Stan Shebs
@ 2008-07-17 21:15 ` Thiago Jung Bauermann
2008-07-17 21:42 ` Daniel Jacobowitz
2008-07-17 21:18 ` Paul Pluzhnikov
2 siblings, 1 reply; 18+ messages in thread
From: Thiago Jung Bauermann @ 2008-07-17 21:15 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
On Thu, 2008-07-17 at 16:57 -0400, Daniel Jacobowitz wrote:
> A MontaVista customer had a very interestingly corrupt core file -
> there was a stray pointer in the list of loaded shared libraries. But
> it pointed to something which looked enough like a shared library
> entry to get by, and the bad entry's l_next pointed back at the
> corrupted entry that led to it. So around and around we went, adding
> the same two libraries to the list. When the solib chain reached
> about 2GB, GDB was killed.
For my own education: it looks to me that this customer won the lottery
two times here (one for pointing to a link map fake entry, and the other
for it to be circular). How often can this happen in practice?
Can we expect somone else to have this problem in this millenium? :-)
--
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 20:57 [RFC] Detect loops in the solib chain Daniel Jacobowitz
2008-07-17 21:07 ` Stan Shebs
2008-07-17 21:15 ` Thiago Jung Bauermann
@ 2008-07-17 21:18 ` Paul Pluzhnikov
2008-07-17 21:41 ` Daniel Jacobowitz
2 siblings, 1 reply; 18+ messages in thread
From: Paul Pluzhnikov @ 2008-07-17 21:18 UTC (permalink / raw)
To: gdb-patches
On Thu, Jul 17, 2008 at 1:57 PM, Daniel Jacobowitz <drow@false.org> wrote:
> The best I could think of was to detect cycles.
This is a double-linked list. You could also check that
lm->l_next == NULL || lm->l_next->l_prev == lm
--
Paul Pluzhnikov
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 21:18 ` Paul Pluzhnikov
@ 2008-07-17 21:41 ` Daniel Jacobowitz
2008-07-17 21:57 ` Paul Pluzhnikov
0 siblings, 1 reply; 18+ messages in thread
From: Daniel Jacobowitz @ 2008-07-17 21:41 UTC (permalink / raw)
To: Paul Pluzhnikov; +Cc: gdb-patches
On Thu, Jul 17, 2008 at 02:17:36PM -0700, Paul Pluzhnikov wrote:
> On Thu, Jul 17, 2008 at 1:57 PM, Daniel Jacobowitz <drow@false.org> wrote:
>
> > The best I could think of was to detect cycles.
>
> This is a double-linked list. You could also check that
>
> lm->l_next == NULL || lm->l_next->l_prev == lm
Hmm - since this is doubly linked, but not circularly, will this
prevent us ever getting into a cycle? I hadn't thought of that.
This version seems to work too.
--
Daniel Jacobowitz
CodeSourcery
2008-07-17 Daniel Jacobowitz <dan@codesourcery.com>
* solib-svr4.c (LM_PREV): New function.
(IGNORE_FIRST_LINK_MAP_ENTRY): Use it.
(svr4_current_sos): Check for correct l_prev.
Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.87
diff -u -p -r1.87 solib-svr4.c
--- solib-svr4.c 3 Jun 2008 12:59:37 -0000 1.87
+++ solib-svr4.c 17 Jul 2008 21:39:50 -0000
@@ -248,6 +248,15 @@ LM_NEXT (struct so_list *so)
}
static CORE_ADDR
+LM_PREV (struct so_list *so)
+{
+ struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
+
+ return extract_typed_address (so->lm_info->lm + lmo->l_prev_offset,
+ builtin_type_void_data_ptr);
+}
+
+static CORE_ADDR
LM_NAME (struct so_list *so)
{
struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
@@ -259,15 +268,12 @@ LM_NAME (struct so_list *so)
static int
IGNORE_FIRST_LINK_MAP_ENTRY (struct so_list *so)
{
- struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
-
/* Assume that everything is a library if the dynamic loader was loaded
late by a static executable. */
if (bfd_get_section_by_name (exec_bfd, ".dynamic") == NULL)
return 0;
- return extract_typed_address (so->lm_info->lm + lmo->l_prev_offset,
- builtin_type_void_data_ptr) == 0;
+ return LM_PREV (so) == 0;
}
static CORE_ADDR debug_base; /* Base of dynamic linker structures */
@@ -750,7 +756,7 @@ svr4_default_sos (void)
static struct so_list *
svr4_current_sos (void)
{
- CORE_ADDR lm;
+ CORE_ADDR lm, prev_lm;
struct so_list *head = 0;
struct so_list **link_ptr = &head;
CORE_ADDR ldsomap = 0;
@@ -766,6 +772,7 @@ svr4_current_sos (void)
/* Walk the inferior's link map list, and build our list of
`struct so_list' nodes. */
+ prev_lm = 0;
lm = solib_svr4_r_map ();
while (lm)
@@ -773,6 +780,7 @@ svr4_current_sos (void)
struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
struct so_list *new = XZALLOC (struct so_list);
struct cleanup *old_chain = make_cleanup (xfree, new);
+ CORE_ADDR next_lm;
new->lm_info = xmalloc (sizeof (struct lm_info));
make_cleanup (xfree, new->lm_info);
@@ -784,14 +792,21 @@ svr4_current_sos (void)
read_memory (lm, new->lm_info->lm, lmo->link_map_size);
- lm = LM_NEXT (new);
+ next_lm = LM_NEXT (new);
+
+ if (prev_lm != 0 && LM_PREV (new) != prev_lm && ldsomap == 0)
+ {
+ warning (_("Corrupted shared library list"));
+ free_so (new);
+ next_lm = 0;
+ }
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
SVR4, it has no name. For others (Solaris 2.3 for example), it
does have a name, so we can no longer use a missing name to
decide when to ignore it. */
- if (IGNORE_FIRST_LINK_MAP_ENTRY (new) && ldsomap == 0)
+ else if (IGNORE_FIRST_LINK_MAP_ENTRY (new) && ldsomap == 0)
{
main_lm_addr = new->lm_info->lm_addr;
free_so (new);
@@ -828,6 +843,9 @@ svr4_current_sos (void)
}
}
+ prev_lm = lm;
+ lm = next_lm;
+
/* On Solaris, the dynamic linker is not in the normal list of
shared objects, so make sure we pick it up too. Having
symbol information for the dynamic linker is quite crucial
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 21:15 ` Thiago Jung Bauermann
@ 2008-07-17 21:42 ` Daniel Jacobowitz
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Jacobowitz @ 2008-07-17 21:42 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: gdb-patches
On Thu, Jul 17, 2008 at 06:14:59PM -0300, Thiago Jung Bauermann wrote:
> For my own education: it looks to me that this customer won the lottery
> two times here (one for pointing to a link map fake entry, and the other
> for it to be circular). How often can this happen in practice?
Beats me, but my guess is more often than you think - the value you
need for it to be circular is readily available. For instance
something that shifts the pointer by a word will make us load l_prev
when we wanted l_next.
They definitely did lose the lottery twice though :-)
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 21:41 ` Daniel Jacobowitz
@ 2008-07-17 21:57 ` Paul Pluzhnikov
2008-07-17 22:10 ` Daniel Jacobowitz
0 siblings, 1 reply; 18+ messages in thread
From: Paul Pluzhnikov @ 2008-07-17 21:57 UTC (permalink / raw)
To: Paul Pluzhnikov, gdb-patches
On Thu, Jul 17, 2008 at 2:40 PM, Daniel Jacobowitz <drow@false.org> wrote:
> @@ -784,14 +792,21 @@ svr4_current_sos (void)
>
> read_memory (lm, new->lm_info->lm, lmo->link_map_size);
>
> - lm = LM_NEXT (new);
> + next_lm = LM_NEXT (new);
> +
> + if (prev_lm != 0 && LM_PREV (new) != prev_lm && ldsomap == 0)
I think you want just:
+ if (LM_PREV (new) != prev_lm)
First entry on the list should also be properly terminated, and
ldsomap has nothing to do with whether the list is corrupt or not.
--
Paul Pluzhnikov
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 21:57 ` Paul Pluzhnikov
@ 2008-07-17 22:10 ` Daniel Jacobowitz
2008-07-18 23:02 ` Kevin Buettner
2010-04-09 15:41 ` Jan Kratochvil
0 siblings, 2 replies; 18+ messages in thread
From: Daniel Jacobowitz @ 2008-07-17 22:10 UTC (permalink / raw)
To: Paul Pluzhnikov; +Cc: gdb-patches
On Thu, Jul 17, 2008 at 02:57:03PM -0700, Paul Pluzhnikov wrote:
> On Thu, Jul 17, 2008 at 2:40 PM, Daniel Jacobowitz <drow@false.org> wrote:
>
> > @@ -784,14 +792,21 @@ svr4_current_sos (void)
> >
> > read_memory (lm, new->lm_info->lm, lmo->link_map_size);
> >
> > - lm = LM_NEXT (new);
> > + next_lm = LM_NEXT (new);
> > +
> > + if (prev_lm != 0 && LM_PREV (new) != prev_lm && ldsomap == 0)
>
> I think you want just:
>
> + if (LM_PREV (new) != prev_lm)
>
> First entry on the list should also be properly terminated, and
> ldsomap has nothing to do with whether the list is corrupt or not.
You're right about prev_lm, thanks. The ldsomap check is necessary,
because that entry may not be on the list (see down below).
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 22:10 ` Daniel Jacobowitz
@ 2008-07-18 23:02 ` Kevin Buettner
2010-04-09 15:41 ` Jan Kratochvil
1 sibling, 0 replies; 18+ messages in thread
From: Kevin Buettner @ 2008-07-18 23:02 UTC (permalink / raw)
To: gdb-patches
On Thu, 17 Jul 2008 18:09:59 -0400
Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Jul 17, 2008 at 02:57:03PM -0700, Paul Pluzhnikov wrote:
> > On Thu, Jul 17, 2008 at 2:40 PM, Daniel Jacobowitz <drow@false.org> wrote:
> >
> > > @@ -784,14 +792,21 @@ svr4_current_sos (void)
> > >
> > > read_memory (lm, new->lm_info->lm, lmo->link_map_size);
> > >
> > > - lm = LM_NEXT (new);
> > > + next_lm = LM_NEXT (new);
> > > +
> > > + if (prev_lm != 0 && LM_PREV (new) != prev_lm && ldsomap == 0)
> >
> > I think you want just:
> >
> > + if (LM_PREV (new) != prev_lm)
> >
> > First entry on the list should also be properly terminated, and
> > ldsomap has nothing to do with whether the list is corrupt or not.
>
> You're right about prev_lm, thanks. The ldsomap check is necessary,
> because that entry may not be on the list (see down below).
As written, I agree that the ldsomap check is necessary. Of course,
having this check means that as soon as ldsomap gets set, this
integrity check is effectively disabled. I think that this will only
matter if the ldsomap entry ends up having a non-zero LM_NEXT.
It seems to me that the ldsomap check could be avoided if you were to
set prev_lm to 0 just after ldsomap gets set. (It's been a while
since I've checked, but I'm guessing that in the case of a unattached
dynamic linker entry, you'd expect both LM_NEXT and LM_PREV for that
entry to be zero.)
Kevin
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2008-07-17 22:10 ` Daniel Jacobowitz
2008-07-18 23:02 ` Kevin Buettner
@ 2010-04-09 15:41 ` Jan Kratochvil
2010-04-09 21:03 ` Jan Kratochvil
1 sibling, 1 reply; 18+ messages in thread
From: Jan Kratochvil @ 2010-04-09 15:41 UTC (permalink / raw)
To: gdb-patches; +Cc: Paul Pluzhnikov, Kevin Buettner
Hi,
this is a follow-up on my different implementation at:
[patch] Fix deadlock on looped solib list
http://sourceware.org/ml/gdb-patches/2010-04/msg00054.html
This thread started by Daniel Jacobowitz has died, pinging it.
On Fri, 18 Jul 2008 00:09:59 +0200, Daniel Jacobowitz wrote:
> On Thu, Jul 17, 2008 at 02:57:03PM -0700, Paul Pluzhnikov wrote:
> > I think you want just:
> >
> > + if (LM_PREV (new) != prev_lm)
> >
> > First entry on the list should also be properly terminated, and
> > ldsomap has nothing to do with whether the list is corrupt or not.
>
> You're right about prev_lm, thanks. The ldsomap check is necessary,
> because that entry may not be on the list (see down below).
Done.
On Sat, 19 Jul 2008 01:02:10 +0200, Kevin Buettner wrote:
> It seems to me that the ldsomap check could be avoided if you were to
> set prev_lm to 0 just after ldsomap gets set. (It's been a while
> since I've checked, but I'm guessing that in the case of a unattached
> dynamic linker entry, you'd expect both LM_NEXT and LM_PREV for that
> entry to be zero.)
Not done. It has a risk of regression on Solaris, I do not have Solaris
easily available (OK, to boot a VM) and keeping the patch as is just does not
apply the new sanity check on the Solaris specific ld.so single entry list.
OK to check-in? (included by name for the fnchange.lst entry :-) )
No regressions on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu.
Thanks,
Jan
gdb/
2010-04-03 Daniel Jacobowitz <dan@codesourcery.com>
Paul Pluzhnikov <ppluzhnikov@google.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Fix deadlock on looped list of loaded shared objects.
* solib-svr4.c (LM_PREV): New function.
(IGNORE_FIRST_LINK_MAP_ENTRY): Use it.
(svr4_current_sos): Check for correct l_prev. New variable prev_lm.
* config/djgpp/fnchange.lst: Add translation for solib-corrupted.exp.
gdb/testsuite/
2010-04-03 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix deadlock on looped list of loaded shared objects.
* gdb.base/solib-corrupted.exp: New.
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -272,6 +272,16 @@ LM_NEXT (struct so_list *so)
}
static CORE_ADDR
+LM_PREV (struct so_list *so)
+{
+ struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
+ struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr;
+
+ return extract_typed_address (so->lm_info->lm + lmo->l_prev_offset,
+ ptr_type);
+}
+
+static CORE_ADDR
LM_NAME (struct so_list *so)
{
struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
@@ -284,16 +294,12 @@ LM_NAME (struct so_list *so)
static int
IGNORE_FIRST_LINK_MAP_ENTRY (struct so_list *so)
{
- struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
- struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr;
-
/* Assume that everything is a library if the dynamic loader was loaded
late by a static executable. */
if (exec_bfd && bfd_get_section_by_name (exec_bfd, ".dynamic") == NULL)
return 0;
- return extract_typed_address (so->lm_info->lm + lmo->l_prev_offset,
- ptr_type) == 0;
+ return LM_PREV (so) == 0;
}
/* Per pspace SVR4 specific data. */
@@ -1101,7 +1107,7 @@ svr4_default_sos (void)
static struct so_list *
svr4_current_sos (void)
{
- CORE_ADDR lm;
+ CORE_ADDR lm, prev_lm;
struct so_list *head = 0;
struct so_list **link_ptr = &head;
CORE_ADDR ldsomap = 0;
@@ -1120,6 +1126,7 @@ svr4_current_sos (void)
/* Walk the inferior's link map list, and build our list of
`struct so_list' nodes. */
+ prev_lm = 0;
lm = solib_svr4_r_map (info);
while (lm)
@@ -1127,6 +1134,7 @@ svr4_current_sos (void)
struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
struct so_list *new = XZALLOC (struct so_list);
struct cleanup *old_chain = make_cleanup (xfree, new);
+ CORE_ADDR next_lm;
new->lm_info = xmalloc (sizeof (struct lm_info));
make_cleanup (xfree, new->lm_info);
@@ -1138,14 +1146,21 @@ svr4_current_sos (void)
read_memory (lm, new->lm_info->lm, lmo->link_map_size);
- lm = LM_NEXT (new);
+ next_lm = LM_NEXT (new);
+
+ if (LM_PREV (new) != prev_lm && ldsomap == 0)
+ {
+ warning (_("Corrupted shared library list"));
+ free_so (new);
+ next_lm = 0;
+ }
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
SVR4, it has no name. For others (Solaris 2.3 for example), it
does have a name, so we can no longer use a missing name to
decide when to ignore it. */
- if (IGNORE_FIRST_LINK_MAP_ENTRY (new) && ldsomap == 0)
+ else if (IGNORE_FIRST_LINK_MAP_ENTRY (new) && ldsomap == 0)
{
info->main_lm_addr = new->lm_info->lm_addr;
free_so (new);
@@ -1182,6 +1197,9 @@ svr4_current_sos (void)
}
}
+ prev_lm = lm;
+ lm = next_lm;
+
/* On Solaris, the dynamic linker is not in the normal list of
shared objects, so make sure we pick it up too. Having
symbol information for the dynamic linker is quite crucial
--- a/gdb/config/djgpp/fnchange.lst
+++ b/gdb/config/djgpp/fnchange.lst
@@ -397,6 +397,7 @@
@V@/gdb/testsuite/gdb.base/siginfo-obj.c @V@/gdb/testsuite/gdb.base/si-obj.c
@V@/gdb/testsuite/gdb.base/siginfo-addr.exp @V@/gdb/testsuite/gdb.base/si-addr.exp
@V@/gdb/testsuite/gdb.base/siginfo-obj.exp @V@/gdb/testsuite/gdb.base/si-obj.exp
+@V@/gdb/testsuite/gdb.base/solib-corrupted.exp @V@/gdb/testsuite/gdb.base/so-crptd.exp
@V@/gdb/testsuite/gdb.base/solib-disc.c @V@/gdb/testsuite/gdb.base/so-disc.c
@V@/gdb/testsuite/gdb.base/solib-display-lib.c @V@/gdb/testsuite/gdb.base/so-displib.c
@V@/gdb/testsuite/gdb.base/solib-display-main.c @V@/gdb/testsuite/gdb.base/so-dispmain.c
--- /dev/null
+++ b/gdb/testsuite/gdb.base/solib-corrupted.exp
@@ -0,0 +1,45 @@
+# Copyright 2010 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+set testfile "solib-corrupted"
+set srcfile start.c
+
+if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } {
+ untested ${testfile}.exp
+ return -1
+}
+
+if ![runto_main] {
+ fail "Can't run to main"
+ return
+}
+
+gdb_test "info sharedlibrary" "" "normal list"
+
+# GDB checks there for matching L_PREV.
+set test "make solibs looping"
+gdb_test_multiple "p/x _r_debug->r_map->l_next = _r_debug->r_map" $test {
+ -re "(No symbol \"_r_debug\" in current context\\.|Attempt to extract a component of a value that is not a structure pointer\\.)\r\n$gdb_prompt $" {
+ # glibc debug info is not available and it is too difficult to find and
+ # parse it from this testcase without the gdb supporting functions.
+ xfail "$test (no _r_debug symbol)"
+ untested ${testfile}.exp
+ return
+ }
+ -re " = 0x\[0-9a-f\]+\r\n$gdb_prompt $" {
+ pass $test
+ }
+}
+gdb_test "info sharedlibrary" "warning: Corrupted shared library list\r\n.*" "corrupted list"
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2010-04-09 15:41 ` Jan Kratochvil
@ 2010-04-09 21:03 ` Jan Kratochvil
2010-04-12 22:54 ` Kevin Buettner
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Jan Kratochvil @ 2010-04-09 21:03 UTC (permalink / raw)
To: gdb-patches; +Cc: Paul Pluzhnikov, Kevin Buettner
On Fri, 09 Apr 2010 17:41:23 +0200, Jan Kratochvil wrote:
> On Sat, 19 Jul 2008 01:02:10 +0200, Kevin Buettner wrote:
> > It seems to me that the ldsomap check could be avoided if you were to
> > set prev_lm to 0 just after ldsomap gets set. (It's been a while
> > since I've checked, but I'm guessing that in the case of a unattached
> > dynamic linker entry, you'd expect both LM_NEXT and LM_PREV for that
> > entry to be zero.)
>
> Not done. It has a risk of regression on Solaris, I do not have Solaris
> easily available (OK, to boot a VM) and keeping the patch as is just does not
> apply the new sanity check on the Solaris specific ld.so single entry list.
Done this part this time. It works during basic test but it is not regression
tested on Solaris as system expect + custom dejagnu produce \r\r\n EOLs
breaking the testsuite completely.
Thanks,
Jan
gdb/
2010-04-09 Daniel Jacobowitz <dan@codesourcery.com>
Paul Pluzhnikov <ppluzhnikov@google.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Fix deadlock on looped list of loaded shared objects.
* solib-svr4.c (LM_PREV): New function.
(IGNORE_FIRST_LINK_MAP_ENTRY): Use it.
(svr4_current_sos): Check for correct l_prev. New variables prev_lm
and next_lm. Clear prev_lm for solib_svr4_r_ldsomap.
* config/djgpp/fnchange.lst: Add translation for solib-corrupted.exp.
gdb/testsuite/
2010-04-09 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix deadlock on looped list of loaded shared objects.
* gdb.base/solib-corrupted.exp: New.
--- a/gdb/config/djgpp/fnchange.lst
+++ b/gdb/config/djgpp/fnchange.lst
@@ -397,6 +397,7 @@
@V@/gdb/testsuite/gdb.base/siginfo-obj.c @V@/gdb/testsuite/gdb.base/si-obj.c
@V@/gdb/testsuite/gdb.base/siginfo-addr.exp @V@/gdb/testsuite/gdb.base/si-addr.exp
@V@/gdb/testsuite/gdb.base/siginfo-obj.exp @V@/gdb/testsuite/gdb.base/si-obj.exp
+@V@/gdb/testsuite/gdb.base/solib-corrupted.exp @V@/gdb/testsuite/gdb.base/so-crptd.exp
@V@/gdb/testsuite/gdb.base/solib-disc.c @V@/gdb/testsuite/gdb.base/so-disc.c
@V@/gdb/testsuite/gdb.base/solib-display-lib.c @V@/gdb/testsuite/gdb.base/so-displib.c
@V@/gdb/testsuite/gdb.base/solib-display-main.c @V@/gdb/testsuite/gdb.base/so-dispmain.c
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -272,6 +272,16 @@ LM_NEXT (struct so_list *so)
}
static CORE_ADDR
+LM_PREV (struct so_list *so)
+{
+ struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
+ struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr;
+
+ return extract_typed_address (so->lm_info->lm + lmo->l_prev_offset,
+ ptr_type);
+}
+
+static CORE_ADDR
LM_NAME (struct so_list *so)
{
struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
@@ -284,16 +294,12 @@ LM_NAME (struct so_list *so)
static int
IGNORE_FIRST_LINK_MAP_ENTRY (struct so_list *so)
{
- struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
- struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr;
-
/* Assume that everything is a library if the dynamic loader was loaded
late by a static executable. */
if (exec_bfd && bfd_get_section_by_name (exec_bfd, ".dynamic") == NULL)
return 0;
- return extract_typed_address (so->lm_info->lm + lmo->l_prev_offset,
- ptr_type) == 0;
+ return LM_PREV (so) == 0;
}
/* Per pspace SVR4 specific data. */
@@ -1101,7 +1107,7 @@ svr4_default_sos (void)
static struct so_list *
svr4_current_sos (void)
{
- CORE_ADDR lm;
+ CORE_ADDR lm, prev_lm;
struct so_list *head = 0;
struct so_list **link_ptr = &head;
CORE_ADDR ldsomap = 0;
@@ -1120,6 +1126,7 @@ svr4_current_sos (void)
/* Walk the inferior's link map list, and build our list of
`struct so_list' nodes. */
+ prev_lm = 0;
lm = solib_svr4_r_map (info);
while (lm)
@@ -1127,6 +1134,7 @@ svr4_current_sos (void)
struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
struct so_list *new = XZALLOC (struct so_list);
struct cleanup *old_chain = make_cleanup (xfree, new);
+ CORE_ADDR next_lm;
new->lm_info = xmalloc (sizeof (struct lm_info));
make_cleanup (xfree, new->lm_info);
@@ -1138,14 +1146,21 @@ svr4_current_sos (void)
read_memory (lm, new->lm_info->lm, lmo->link_map_size);
- lm = LM_NEXT (new);
+ next_lm = LM_NEXT (new);
+
+ if (LM_PREV (new) != prev_lm)
+ {
+ warning (_("Corrupted shared library list"));
+ free_so (new);
+ next_lm = 0;
+ }
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
SVR4, it has no name. For others (Solaris 2.3 for example), it
does have a name, so we can no longer use a missing name to
decide when to ignore it. */
- if (IGNORE_FIRST_LINK_MAP_ENTRY (new) && ldsomap == 0)
+ else if (IGNORE_FIRST_LINK_MAP_ENTRY (new) && ldsomap == 0)
{
info->main_lm_addr = new->lm_info->lm_addr;
free_so (new);
@@ -1182,12 +1197,18 @@ svr4_current_sos (void)
}
}
+ prev_lm = lm;
+ lm = next_lm;
+
/* On Solaris, the dynamic linker is not in the normal list of
shared objects, so make sure we pick it up too. Having
symbol information for the dynamic linker is quite crucial
for skipping dynamic linker resolver code. */
if (lm == 0 && ldsomap == 0)
- lm = ldsomap = solib_svr4_r_ldsomap (info);
+ {
+ lm = ldsomap = solib_svr4_r_ldsomap (info);
+ prev_lm = 0;
+ }
discard_cleanups (old_chain);
}
--- /dev/null
+++ b/gdb/testsuite/gdb.base/solib-corrupted.exp
@@ -0,0 +1,45 @@
+# Copyright 2010 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+set testfile "solib-corrupted"
+set srcfile start.c
+
+if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } {
+ untested ${testfile}.exp
+ return -1
+}
+
+if ![runto_main] {
+ fail "Can't run to main"
+ return
+}
+
+gdb_test "info sharedlibrary" "" "normal list"
+
+# GDB checks there for matching L_PREV.
+set test "make solibs looping"
+gdb_test_multiple "p/x _r_debug->r_map->l_next = _r_debug->r_map" $test {
+ -re "(No symbol \"_r_debug\" in current context\\.|Attempt to extract a component of a value that is not a structure pointer\\.)\r\n$gdb_prompt $" {
+ # glibc debug info is not available and it is too difficult to find and
+ # parse it from this testcase without the gdb supporting functions.
+ xfail "$test (no _r_debug symbol)"
+ untested ${testfile}.exp
+ return
+ }
+ -re " = 0x\[0-9a-f\]+\r\n$gdb_prompt $" {
+ pass $test
+ }
+}
+gdb_test "info sharedlibrary" "warning: Corrupted shared library list\r\n.*" "corrupted list"
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2010-04-09 21:03 ` Jan Kratochvil
@ 2010-04-12 22:54 ` Kevin Buettner
2010-04-12 23:08 ` Pedro Alves
2010-04-23 20:09 ` [RFC] Detect loops in the solib chain Tom Tromey
2 siblings, 0 replies; 18+ messages in thread
From: Kevin Buettner @ 2010-04-12 22:54 UTC (permalink / raw)
To: gdb-patches
On Fri, 9 Apr 2010 23:02:55 +0200
Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> Fix deadlock on looped list of loaded shared objects.
> * solib-svr4.c (LM_PREV): New function.
> (IGNORE_FIRST_LINK_MAP_ENTRY): Use it.
> (svr4_current_sos): Check for correct l_prev. New variables prev_lm
> and next_lm. Clear prev_lm for solib_svr4_r_ldsomap.
> * config/djgpp/fnchange.lst: Add translation for solib-corrupted.exp.
I reviewed this part of the patch. It looks okay to me.
Kevin
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2010-04-09 21:03 ` Jan Kratochvil
2010-04-12 22:54 ` Kevin Buettner
@ 2010-04-12 23:08 ` Pedro Alves
2010-04-18 20:24 ` OpenSolaris dejagnu workaround [Re: [RFC] Detect loops in the solib chain] Jan Kratochvil
2010-04-23 20:09 ` [RFC] Detect loops in the solib chain Tom Tromey
2 siblings, 1 reply; 18+ messages in thread
From: Pedro Alves @ 2010-04-12 23:08 UTC (permalink / raw)
To: gdb-patches; +Cc: Jan Kratochvil, Paul Pluzhnikov, Kevin Buettner
On Friday 09 April 2010 22:02:55, Jan Kratochvil wrote:
> Done this part this time. It works during basic test but it is not regression
> tested on Solaris as system expect + custom dejagnu produce \r\r\n EOLs
> breaking the testsuite completely.
Was that OpenSolaris? I've seen that before too. Here
is the workaround I was using a while ago:
http://sourceware.org/ml/gdb/2008-08/msg00144.html
I don't really know what exactly causes this.
I never saw that problem on Solaris (non-Open), but then
again, there we're using a built from source dejagnu, I think.
--
Pedro Alves
^ permalink raw reply [flat|nested] 18+ messages in thread
* OpenSolaris dejagnu workaround [Re: [RFC] Detect loops in the solib chain]
2010-04-12 23:08 ` Pedro Alves
@ 2010-04-18 20:24 ` Jan Kratochvil
0 siblings, 0 replies; 18+ messages in thread
From: Jan Kratochvil @ 2010-04-18 20:24 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches, Paul Pluzhnikov, Kevin Buettner
On Tue, 13 Apr 2010 01:07:34 +0200, Pedro Alves wrote:
> On Friday 09 April 2010 22:02:55, Jan Kratochvil wrote:
> > Done this part this time. It works during basic test but it is not regression
> > tested on Solaris as system expect + custom dejagnu produce \r\r\n EOLs
> > breaking the testsuite completely.
>
> Was that OpenSolaris? I've seen that before too.
Yes, filed
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6942789
> Here is the workaround I was using a while ago:
>
> http://sourceware.org/ml/gdb/2008-08/msg00144.html
It works, thanks.
> I never saw that problem on Solaris (non-Open), but then
> again, there we're using a built from source dejagnu, I think.
dejagnu must be from source, haven't found it packaged in OpenSolaris.
expect is there some Sun packaged one but it has the same problem as the GNU
one rebuilt there from sources.
Regards,
Jan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2010-04-09 21:03 ` Jan Kratochvil
2010-04-12 22:54 ` Kevin Buettner
2010-04-12 23:08 ` Pedro Alves
@ 2010-04-23 20:09 ` Tom Tromey
2010-04-23 21:47 ` Jan Kratochvil
2 siblings, 1 reply; 18+ messages in thread
From: Tom Tromey @ 2010-04-23 20:09 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches, Paul Pluzhnikov, Kevin Buettner
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> 2010-04-09 Daniel Jacobowitz <dan@codesourcery.com>
Jan> Paul Pluzhnikov <ppluzhnikov@google.com>
Jan> Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> Fix deadlock on looped list of loaded shared objects.
Jan> * solib-svr4.c (LM_PREV): New function.
Jan> (IGNORE_FIRST_LINK_MAP_ENTRY): Use it.
Jan> (svr4_current_sos): Check for correct l_prev. New variables prev_lm
Jan> and next_lm. Clear prev_lm for solib_svr4_r_ldsomap.
Jan> * config/djgpp/fnchange.lst: Add translation for solib-corrupted.exp.
Kevin already ok'd this part.
(FWIW I agree it is ok.)
Jan> 2010-04-09 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> Fix deadlock on looped list of loaded shared objects.
Jan> * gdb.base/solib-corrupted.exp: New.
Jan> + # glibc debug info is not available and it is too difficult to find and
Jan> + # parse it from this testcase without the gdb supporting functions.
Jan> + xfail "$test (no _r_debug symbol)"
Jan> + untested ${testfile}.exp
Jan> + return
Jan> + }
Jan> + -re " = 0x\[0-9a-f\]+\r\n$gdb_prompt $" {
Jan> + pass $test
I think it is preferable to have the test name the same, regardless of
whether it passes or xfails. Extra info can be logged with verbose.
This is ok with that change.
thanks,
Tom
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2010-04-23 20:09 ` [RFC] Detect loops in the solib chain Tom Tromey
@ 2010-04-23 21:47 ` Jan Kratochvil
2010-06-11 17:39 ` Ulrich Weigand
0 siblings, 1 reply; 18+ messages in thread
From: Jan Kratochvil @ 2010-04-23 21:47 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches, Paul Pluzhnikov, Kevin Buettner
On Fri, 23 Apr 2010 22:09:43 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Jan> + # glibc debug info is not available and it is too difficult to find and
> Jan> + # parse it from this testcase without the gdb supporting functions.
> Jan> + xfail "$test (no _r_debug symbol)"
> Jan> + untested ${testfile}.exp
> Jan> + return
> Jan> + }
> Jan> + -re " = 0x\[0-9a-f\]+\r\n$gdb_prompt $" {
> Jan> + pass $test
>
> I think it is preferable to have the test name the same, regardless of
> whether it passes or xfails. Extra info can be logged with verbose.
Changed. Although there are precedent cases of this, still they are therefore
probably not considered as the preferred ones. Such as:
gdb.base/corefile.exp
set test "accessing mmapped data in core file"
pass "$test"
fail "$test (mapping failed at runtime)"
fail "$test (mapping address not found in core file)"
> This is ok with that change.
Checked in.
Thanks,
Jan
http://sourceware.org/ml/gdb-cvs/2010-04/msg00240.html
--- src/gdb/ChangeLog 2010/04/23 18:09:16 1.11678
+++ src/gdb/ChangeLog 2010/04/23 21:44:19 1.11679
@@ -1,3 +1,14 @@
+2010-04-23 Daniel Jacobowitz <dan@codesourcery.com>
+ Paul Pluzhnikov <ppluzhnikov@google.com>
+ Jan Kratochvil <jan.kratochvil@redhat.com>
+
+ Fix deadlock on looped list of loaded shared objects.
+ * solib-svr4.c (LM_PREV): New function.
+ (IGNORE_FIRST_LINK_MAP_ENTRY): Use it.
+ (svr4_current_sos): Check for correct l_prev. New variables prev_lm
+ and next_lm. Clear prev_lm for solib_svr4_r_ldsomap.
+ * config/djgpp/fnchange.lst: Add translation for solib-corrupted.exp.
+
2010-04-23 Doug Evans <dje@google.com>
* configure.ac (CONFIG_SRCS): Add py-auto-load.o even if not using
--- src/gdb/solib-svr4.c 2010/03/11 22:07:02 1.130
+++ src/gdb/solib-svr4.c 2010/04/23 21:44:19 1.131
@@ -272,6 +272,16 @@
}
static CORE_ADDR
+LM_PREV (struct so_list *so)
+{
+ struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
+ struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr;
+
+ return extract_typed_address (so->lm_info->lm + lmo->l_prev_offset,
+ ptr_type);
+}
+
+static CORE_ADDR
LM_NAME (struct so_list *so)
{
struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
@@ -284,16 +294,12 @@
static int
IGNORE_FIRST_LINK_MAP_ENTRY (struct so_list *so)
{
- struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
- struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr;
-
/* Assume that everything is a library if the dynamic loader was loaded
late by a static executable. */
if (exec_bfd && bfd_get_section_by_name (exec_bfd, ".dynamic") == NULL)
return 0;
- return extract_typed_address (so->lm_info->lm + lmo->l_prev_offset,
- ptr_type) == 0;
+ return LM_PREV (so) == 0;
}
/* Per pspace SVR4 specific data. */
@@ -1101,7 +1107,7 @@
static struct so_list *
svr4_current_sos (void)
{
- CORE_ADDR lm;
+ CORE_ADDR lm, prev_lm;
struct so_list *head = 0;
struct so_list **link_ptr = &head;
CORE_ADDR ldsomap = 0;
@@ -1120,6 +1126,7 @@
/* Walk the inferior's link map list, and build our list of
`struct so_list' nodes. */
+ prev_lm = 0;
lm = solib_svr4_r_map (info);
while (lm)
@@ -1127,6 +1134,7 @@
struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
struct so_list *new = XZALLOC (struct so_list);
struct cleanup *old_chain = make_cleanup (xfree, new);
+ CORE_ADDR next_lm;
new->lm_info = xmalloc (sizeof (struct lm_info));
make_cleanup (xfree, new->lm_info);
@@ -1138,14 +1146,21 @@
read_memory (lm, new->lm_info->lm, lmo->link_map_size);
- lm = LM_NEXT (new);
+ next_lm = LM_NEXT (new);
+
+ if (LM_PREV (new) != prev_lm)
+ {
+ warning (_("Corrupted shared library list"));
+ free_so (new);
+ next_lm = 0;
+ }
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
SVR4, it has no name. For others (Solaris 2.3 for example), it
does have a name, so we can no longer use a missing name to
decide when to ignore it. */
- if (IGNORE_FIRST_LINK_MAP_ENTRY (new) && ldsomap == 0)
+ else if (IGNORE_FIRST_LINK_MAP_ENTRY (new) && ldsomap == 0)
{
info->main_lm_addr = new->lm_info->lm_addr;
free_so (new);
@@ -1182,12 +1197,18 @@
}
}
+ prev_lm = lm;
+ lm = next_lm;
+
/* On Solaris, the dynamic linker is not in the normal list of
shared objects, so make sure we pick it up too. Having
symbol information for the dynamic linker is quite crucial
for skipping dynamic linker resolver code. */
if (lm == 0 && ldsomap == 0)
- lm = ldsomap = solib_svr4_r_ldsomap (info);
+ {
+ lm = ldsomap = solib_svr4_r_ldsomap (info);
+ prev_lm = 0;
+ }
discard_cleanups (old_chain);
}
--- src/gdb/config/djgpp/fnchange.lst 2010/04/09 15:15:05 1.112
+++ src/gdb/config/djgpp/fnchange.lst 2010/04/23 21:44:19 1.113
@@ -397,6 +397,7 @@
@V@/gdb/testsuite/gdb.base/siginfo-obj.c @V@/gdb/testsuite/gdb.base/si-obj.c
@V@/gdb/testsuite/gdb.base/siginfo-addr.exp @V@/gdb/testsuite/gdb.base/si-addr.exp
@V@/gdb/testsuite/gdb.base/siginfo-obj.exp @V@/gdb/testsuite/gdb.base/si-obj.exp
+@V@/gdb/testsuite/gdb.base/solib-corrupted.exp @V@/gdb/testsuite/gdb.base/so-crptd.exp
@V@/gdb/testsuite/gdb.base/solib-disc.c @V@/gdb/testsuite/gdb.base/so-disc.c
@V@/gdb/testsuite/gdb.base/solib-display-lib.c @V@/gdb/testsuite/gdb.base/so-displib.c
@V@/gdb/testsuite/gdb.base/solib-display-main.c @V@/gdb/testsuite/gdb.base/so-dispmain.c
--- src/gdb/testsuite/ChangeLog 2010/04/23 18:03:31 1.2252
+++ src/gdb/testsuite/ChangeLog 2010/04/23 21:44:20 1.2253
@@ -1,3 +1,8 @@
+2010-04-23 Jan Kratochvil <jan.kratochvil@redhat.com>
+
+ Fix deadlock on looped list of loaded shared objects.
+ * gdb.base/solib-corrupted.exp: New.
+
2010-04-23 Doug Evans <dje@google.com>
* gdb.python/py-section-script.c: New file.
--- src/gdb/testsuite/gdb.base/solib-corrupted.exp
+++ src/gdb/testsuite/gdb.base/solib-corrupted.exp 2010-04-23 21:44:35.962406000 +0000
@@ -0,0 +1,46 @@
+# Copyright 2010 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+set testfile "solib-corrupted"
+set srcfile start.c
+
+if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } {
+ untested ${testfile}.exp
+ return -1
+}
+
+if ![runto_main] {
+ fail "Can't run to main"
+ return
+}
+
+gdb_test "info sharedlibrary" "" "normal list"
+
+# GDB checks there for matching L_PREV.
+set test "make solibs looping"
+gdb_test_multiple "p/x _r_debug->r_map->l_next = _r_debug->r_map" $test {
+ -re "(No symbol \"_r_debug\" in current context\\.|Attempt to extract a component of a value that is not a structure pointer\\.)\r\n$gdb_prompt $" {
+ # glibc debug info is not available and it is too difficult to find and
+ # parse it from this testcase without the gdb supporting functions.
+ verbose -log "no _r_debug symbol has been found"
+ xfail $test
+ untested ${testfile}.exp
+ return
+ }
+ -re " = 0x\[0-9a-f\]+\r\n$gdb_prompt $" {
+ pass $test
+ }
+}
+gdb_test "info sharedlibrary" "warning: Corrupted shared library list\r\n.*" "corrupted list"
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2010-04-23 21:47 ` Jan Kratochvil
@ 2010-06-11 17:39 ` Ulrich Weigand
2010-06-11 18:34 ` Jan Kratochvil
0 siblings, 1 reply; 18+ messages in thread
From: Ulrich Weigand @ 2010-06-11 17:39 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Tom Tromey, gdb-patches, Paul Pluzhnikov, Kevin Buettner
Jan Kratochvil wrote:
> +2010-04-23 Jan Kratochvil <jan.kratochvil@redhat.com>
> +
> + Fix deadlock on looped list of loaded shared objects.
> + * gdb.base/solib-corrupted.exp: New.
> +
Like all solib test cases, this should be skipped on platforms
that do not support shared libraries.
Tested on spu-elf, committed to mainline.
Bye,
Ulrich
ChangeLog:
* gdb.base/solib-corrupted.exp: Respect skip_shlib_tests.
Index: gdb/testsuite/gdb.base/solib-corrupted.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/solib-corrupted.exp,v
retrieving revision 1.2
diff -u -p -r1.2 solib-corrupted.exp
--- gdb/testsuite/gdb.base/solib-corrupted.exp 1 Jun 2010 21:29:21 -0000 1.2
+++ gdb/testsuite/gdb.base/solib-corrupted.exp 11 Jun 2010 16:43:07 -0000
@@ -13,6 +13,10 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
+if {[skip_shlib_tests]} {
+ return 0
+}
+
set testfile "solib-corrupted"
set srcfile start.c
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] Detect loops in the solib chain
2010-06-11 17:39 ` Ulrich Weigand
@ 2010-06-11 18:34 ` Jan Kratochvil
0 siblings, 0 replies; 18+ messages in thread
From: Jan Kratochvil @ 2010-06-11 18:34 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Tom Tromey, gdb-patches, Paul Pluzhnikov, Kevin Buettner
On Fri, 11 Jun 2010 19:39:11 +0200, Ulrich Weigand wrote:
> Like all solib test cases, this should be skipped on platforms
> that do not support shared libraries.
Aware of it but I somehow missed it in this case, thanks.
Sorry,
Jan
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2010-06-11 18:34 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-17 20:57 [RFC] Detect loops in the solib chain Daniel Jacobowitz
2008-07-17 21:07 ` Stan Shebs
2008-07-17 21:15 ` Thiago Jung Bauermann
2008-07-17 21:42 ` Daniel Jacobowitz
2008-07-17 21:18 ` Paul Pluzhnikov
2008-07-17 21:41 ` Daniel Jacobowitz
2008-07-17 21:57 ` Paul Pluzhnikov
2008-07-17 22:10 ` Daniel Jacobowitz
2008-07-18 23:02 ` Kevin Buettner
2010-04-09 15:41 ` Jan Kratochvil
2010-04-09 21:03 ` Jan Kratochvil
2010-04-12 22:54 ` Kevin Buettner
2010-04-12 23:08 ` Pedro Alves
2010-04-18 20:24 ` OpenSolaris dejagnu workaround [Re: [RFC] Detect loops in the solib chain] Jan Kratochvil
2010-04-23 20:09 ` [RFC] Detect loops in the solib chain Tom Tromey
2010-04-23 21:47 ` Jan Kratochvil
2010-06-11 17:39 ` Ulrich Weigand
2010-06-11 18:34 ` Jan Kratochvil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox