Trace a segmentation fault back to an unloaded library

[blackwater]

I have read this question: http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1278944680878+28353475&threadId=1339960
and did the same test using g++ 4.3.3. The test program causes a coredump as I expected.
In this situation I know exactly the library what causes a coredump because I have intentionally put a static variable in its function.
However in general I don't know steps that I shall do in order to find out what library caused a coredump using only backtrace, disassemble, info registers and info shared (as if this happened in a real world situation and I only knew backtrace and registers).
So how could I trace this segmentation fault back to the unloaded library using backtrace, disassemble and info registers?
I have put everyting related to my question in the attached file.
Any help is appreciated.
I do understand that aCC doen't have this sort of problem. So the question is not about aCC.

[Dennis Handly · Accepted solution]

The problem could happen with cc or aC++ but you have to work harder. :-)

>I don't know steps that I shall do in order to find out what library caused a coredump using only backtrace, disassemble, info registers and info shared.

You can't. All you can find out is that you are referencing an address that isn't covered by the current text and data regions from "info shared".

If you run this in gdb, gdb nicely remembers shlibs that were unloaded. And you can do "catch unload" to see which shlib has that address.

Or after it aborts, you run it again and match up with the "info shared" values, before it is unloaded.

[blackwater]

the program coredumped on the instruction:
ld8 ret1=[ret1]

I examine the ret1 register:
info reg ret1
gr9: 0x9fffffffff30d000

and the address 0x9fffffffff30d000 according to "info shared" belongs to the unloaded library libmy_lib.so.1. So accessing this address results in a coredump.