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.