• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 622
  • Last Modified:

query on ldd in Linux

Hello
From an C application, we are getting the following error in sys msgs
app[5678]: segfault at 0000000 rip 00003f32a823 rsp 000123ade323 error 4

My query is, Can i map RIP address (00003f32a823) to a function name by running below commands?
======
ldd /a/b/app | less
nm -a /a/b/app | less
nm -D <library which has closest load address> | less
=========

If yes, please confirm.

Sham
0
mohet01
Asked:
mohet01
  • 10
  • 6
1 Solution
 
mohet01Author Commented:
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
0
 
mohet01Author Commented:
[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
0
 
Infinity08Commented:
The RIP (instruction pointer) listed in the segfault entry in syslog is the virtual address where the segmentation fault occurred.
For executables, the symbol value (the hex value at the start of each line) listed by nm is the virtual address at which that symbol can be found.
For shared libraries, the symbol value listed by nm is the offset (to the virtual address where the shared library was loaded) at which the symbol can be found.


So if the segfault occurred in the executable :

        nm /a/b/app | sort

should help you find the function where the segfault occurred (by looking for the symbol with a highest symbol value that is lower than the instruction pointer).


If the segfault occurred in a shared library, then first you need to figure out which library, and at what virtual address it was loaded.

On my system, this is a quite easy, as I would get an entry in syslog like this :

        app[5678]: segfault at 0000000 rip 00003f32a823 rsp 000123ade323 error 4 in library.so[3f300000+290000]

where the exact shared library where the segfault occurred is listed (library.so), as well as the virtual address where the shared library was loaded (0x3f300000).

Another way to get this information, is from a core dump.

I'll assume you don't have either of those as an option though (but double-check it to be sure), so this becomes quite a bit harder. On recent Linux systems, the virtual address at which a shared library is loaded is "randomized", so it's different for every run. This also means ldd won't help you find the information, since the crash already happened, and the process is no longer there.

Of course, if you can reproduce the segfault, none of the above really matters, since you can make it generate a core dump, attach a debugger to it, or take note of the virtual addresses where the shared libraries are loaded.



And finally, once you have found in which binary the segfault occurred, and the address where it occurred, to track down the exact instruction that caused the segfault, you can do :

        objdump -d <binary_where_segfault_occurred>

and look for the instruction at the obtained address.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
mohet01Author Commented:
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
0
 
Infinity08Commented:
>> 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.
0
 
mohet01Author Commented:
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?
0
 
Infinity08Commented:
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.
0
 
mohet01Author Commented:
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
0
 
mohet01Author Commented:
i mean, how do i know, frmo where fclose() is caleed app orxyz.so?
0
 
Infinity08Commented:
>> 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.
0
 
mohet01Author Commented:
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?
0
 
Infinity08Commented:
>> 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).
0
 
mohet01Author Commented:
ulimit -c is 0
But if i set it to unlimited, it becomes 0 after reboot
0
 
mohet01Author Commented:
hello
If I modify ulimit -c to unlimited
Do I need to restart app to take the change into effect
Sham
0
 
mohet01Author Commented:
thanx
0
 
Infinity08Commented:
Sorry for the delay. But yes, that's correct.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 10
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now