query on ldd in Linux

The reason am asking this query is, I would like to understand:
1) Is RIP pointer address a load-address of an instruction?
2) Who assigns load address to application app? linker?
3) Is load address of an instruction in app same as virtual address of that same instruction in app?
4) In point 2) 3), if the answer is yes, How linker decide the virtual address space of an app?



Sham

[root@ukirp198 bin]# ldd app
libc.so.6 => /a/b/libc.so.6 (0x00ad3000)
/lib/ld-linux.so.2 (0x00ab5000)

1) Does "nm -a /a/b/app" provide absolute/offset load address for each dynamic symbol?
2) Does "nm -D /lib/lic.so.6" provide the absolute/offset load address for each symbol in this library?

Can somebody answer the above 2 questions
Sham

1) can we do " objdump -d " work on .so file also?
2) we are  getting RIP error like this: "app[3282]: segfault at 0000000000000046 rip 0000000000b2ab7d rsp 00000000f4880170 error 4"


process is going to crash again after 2 days on 3 Redhat 5.4 machines with same RIPerror.

So, Can you please let me know the steps that i can run today before hand of crash of app? We are also suspecting that RIP error is coming somewhere in fclose()





Sham

>> 1) can we do " objdump -d " work on .so file also?

yes

>> So, Can you please let me know the steps that i can run today before hand of crash of app?

If you know when it will crash, you can attach a debugger to it, and observe the crash.

If you don't know exactly, you can take note of the shared libraries and their virtual addresses by checking :

        cat /proc/<pid>/maps

where <pid> is the process id of your process.

After taking
cat /proc/<pid>/maps


What should i do? I know, this file has range of virtual address for caiuxsA2 and its dependent so.

But which instruction in that suspect library/app? How do i know?

It shows you the mappings of all shared libraries. Keep this information in some text file.

When the crash occurs, you can use the information in that text file to figure out in which shared library the crash occurred, and what the virtual address was.

Probem is, core is not getting generated, despite making "ulimit -c  unlimited", do i ask cat  /proc/pid/limits

we have application
app
and dependent libraries
xyz.so, libc.so


Before previous crash,  we see problem in, "nm -D libc.so",
:
0000000000b377f0 T _IO_doallocbuf
0000000000b2ab60 T _IO_fclose
0000000000bde680 T _IO_fclose
:

becasue RIP error as:
app[3282]: segfault at 0000000000000046 rip 0000000000b2ab7d rsp
00000000f4880170 error 4

So, How do we proceed?

Sham

i mean, how do i know, frmo where fclose() is caleed app orxyz.so?

>> Probem is, core is not getting generated

I suspected that ;)

But with the mappings, and the RIP at the time of the crash, you can get the exact instruction that caused the crash.


>> i mean, how do i know, frmo where fclose() is caleed app orxyz.so?

Ah, but that's something else - that requires a stack dump to perform a stack trace. And that in turn requires a core file to be generated (or a debugger to be attached to the process at the time of the crash).

So, if you need that, you'll either have to make sure there's a debugger attached to the process during the crash (but keep in mind this adds overhead), or you'll have to restart the process with core dumps enabled.

If this is the case, I will depend on core

What are the steps to verify/confirm that a process can generate core on SIGSEGV?

>> What are the steps to verify/confirm that a process can generate core on SIGSEGV?

If core generation is enabled for the process (ulimit -c unlimited), it will. You can test it by sending an ABRT signal to the process eg. (but that will end the process).

ulimit -c is 0
But if i set it to unlimited, it becomes 0 after reboot

hello
If I modify ulimit -c to unlimited
Do I need to restart app to take the change into effect
Sham

thanx

Sorry for the delay. But yes, that's correct.