Topic
  • No replies
SystemAdmin
SystemAdmin
196 Posts

Pinned topic my program sometimes core in dlopen() function

‏2010-07-01T05:02:10Z |

/aiboss1/openboss/zxx/SmsTransfer->(162)_>dbx jx_dxyyt.bin core.1
Type 'help' for help.
http://using memory image in core.1
reading symbolic information ...
Segmentation fault in find_ldinfo__FPC8_dl_info at 0xd070a6e8 ($t7)
0xd070a6e8 (find_ldinfo__FPC8_dl_info+0x28) 80640010 lwz r3,0x10(r4)
(dbx) where
find_ldinfo__FPC8_dl_info() at 0xd070a6e8
search_for_lib2__FPC8_dl_info() at 0xd070a054
load_libs__FPFv_i() at 0xd070b13c
loadAndInit() at 0xd0709898
dlopen(??, ??) at 0xd03ea29c
do_openDll(const char*)(0x34b01f79), line 286 in "obd_client_objs.cpp"
unnamed block in open_dll(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&)(0xf0c8d560, 0x321118e0), line 219 in "obd_client_objs.cpp"
open_dll(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&)(0xf0c8d560, 0x321118e0), line 219 in "obd_client_objs.cpp"
unnamed block in bind(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&,const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&)(0x321125a8, 0x32111950, 0x32112600), line 504 in "obd_client_objs.cpp"
bind(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&,const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&)(0x321125a8, 0x32111950, 0x32112600), line 504 in "obd_client_objs.cpp"

the up words is the stack info about core . can anyone help me to solve this problem..
Updated on 2010-11-04T23:23:23Z at 2010-11-04T23:23:23Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    196 Posts

    Re: my program sometimes core in dlopen() function

    ‏2010-11-04T23:23:23Z  
    Looking at the instruction causing the problem:
    0xd070a6e8 (find_ldinfo__FPC8_dl_info+0x28) 80640010 lwz r3,0x10(r4)

    It looks like r4 is garbage, and trying to load 0x10 bytes off of this garbage is triggering the problem. From the AIX register linkage convention we see r4 holds the 2nd argument of calls. Now, I can't see the assembly for find_ldinfo..., but assuming that it's close to the entry point and r4 was not reused for another purpose, it probably holds the address of the second argument passed to find_ldinfo.... If you run the program with dbx and wait for it to crash, you can inspect the address values, and then using these values, match them up with the arguments of the calls in the stack trace to try and track it back to the bad data being passed in.

    Note that the call to open_dll

    open_dll(const std::basic_string,std::allocator >&)( 0xf0c8d560, 0x321118e0), line 219 in "obd_client_objs.cpp"

    has a suspicious value 0xf0c8d560 --it doesn't look like a typical memory address.
    If an invalid file pointer is passed in, it could muck up the system and trigger a failure like you're seeing. Can you somehow validate the parameters you are passing to open_dll?
    Updated on 2014-03-24T22:17:57Z at 2014-03-24T22:17:57Z by iron-man