Segmentation fault in _dl_runtime_resolve()

Question

I am doing simple string operations in the code where i am getting a segmention fault. I could not get what the exact problem is. Please take a look if someone can help.

The backtrace of the core is

(gdb) bt
#0  0x00007f595dee41da in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#1  0x00007f595deea105 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
#2  0x0000000000401d04 in getNodeInfo (node=0x7fffbfb4ba83 "TCU-0")
    at hwdetails.cpp:294
#3  0x0000000000402178 in main (argc=3, argv=0x7fffbfb4aef8)
    at hwdetails.cpp:369

At line 294 the crash is coming where the cout statement is there.
LdapDN is char * and is not NULL.

if ( Epath && (Epath->Entry[0].EntityType == SAHPI_ENT_UNSPECIFIED ||
         Epath->Entry[0].EntityType == SAHPI_ENT_ROOT )) {
        // nothing is mapped. Degrade the ldap dn path to slot.
        if(LdapDN){
            std::cout << "LdapDN " << LdapDN << std::endl;
        }
        std::string ldapDN;
        ldapDN = LdapDN;
        std::string slot = LDAP_PIU_ID;
        if ( ldapDN.compare(0, slot.length(), slot) != 0 ) {
            size_t pos = ldapDN.find(slot);
            if ( pos != std::string::npos ) {
                ldapDN = ldapDN.substr(pos);
                LdapDN = (char *)ldapDN.c_str();
                //getEntityPathFromLdapDn(ldapDN.c_str(), epath, domid);
            }
        }
     }

What OS is it running on? What are the compilation options you're using? — Eitan T, May 14 '12 at 07:11

score 8 · Answer 1 · answered May 19 '12 at 21:11

A crash in _dl_fixup generally means that you have corrupted the state of runtime loader.

The two most common causes are:

Heap corruption (overflow) or
Mismatched parts of glibc itself.

If you are not setting e.g. LD_LIBRARY_PATH to point to a non-standard glibc, then we can forget about reason #2.

For #1, run your program under Valgrind, and make sure it detects no errors.

If in fact it doesn't, use disas and info registers GDB commands, update your question with their output, and you may receive additional help.

cosinus0 · Answer 2 · 2013-12-05T13:31:25.913

This is problem with GOT table. _dl_runtime_resolve - procedure which changes GOT (global offset table), when some function from dynamic library call's first time. In the next time using changed GOT entry. When a function (for example printf() from libc.so) from dynamic library call's in your code first time:

goto PLT(program lookup table). The PLT is a trampoline which gets the correct address of the function being called from GOT.
from PLT goto GOT
return to PLT
call _dl_runtime_resolve
- store actual function jump address to GOT
- call function from dynamic library

The second time function call is:

goto PLT
goto GOT
GOT have direct jump to function address from dynamic library. GOT is a reference to a function called once again without going through the _dl_runtime_resolve fast.

"This is problem with GOT table" -- you may be right, or you may be wrong (there are many other possible reasons for the crash in `_dl_runtime_resolve`). You have not supplied any evidence to support your claim, and your description of what actually happens during lazy PLT resolution is wrong in many details, and makes no sense for anyone not already familiar with it. — Employed Russian, Nov 02 '17 at 02:40

score 1 · Answer 3 · answered May 20 '12 at 00:43

i see a memory leak here :

You essentially are losing your previous string LdapDN when you do

 if ( pos != std::string::npos ) {
            ldapDN = ldapDN.substr(pos);
            LdapDN = (char *)ldapDN.c_str();
            //getEntityPathFromLdapDn(ldapDN.c_str(), epath, domid);
        }

Segmentation fault in _dl_runtime_resolve()

3 Answers3