r_debug

LLDB is asserting and dying in DYLDRendezvous::UpdateSOEntries() and I got a core dump for it and the target it was debugging.

I load the core dump for the target - it's crashing in _dl_debug_state() line in _dl_map_object_from_fd():

 1040|    /* Notify the debugger we have added some objects. We need to  
 1041|     call _dl_debug_initialize in a static program in case dynamic  
 1042|     linking has not been used before. */  
 1043|    r->r_state = RT_ADD;  
 1044+>   _dl_debug_state ();  
 1045|    make_consistent = true;  

_dl_debug_state() is an empty function though.

 70| /* This function exists solely to have a breakpoint set on it by the  
 71|  debugger. The debugger is supposed to find this function's address by  
 72|  examining the r_brk member of struct r_debug, but GDB 4.15 in fact looks  
 73|  for this particular symbol name in the PT_INTERP file. */  
 74| void  
 75| _dl_debug_state (void)  
 76| {  
 77+>}  

Why on earth would it crash there?

(gdb) disassemble _dl_debug_state

Dump of assembler code for function __GI__dl_debug_state:

   0x00007fb123d9cb30 <+0>:     int3

=> 0x00007fb123d9cb31 <+1>:     ret

End of assembler dump.

Oh.

LLDB must have shoved the int3 in there, then it died and didn't remove the mess and the target went down. This is pretty slick though - this is how the debugger is notified that a new shared object is being loaded. Lots of details in elf/link.h that I'm going to start reading.

http://sourceware.org/ml/gdb/2000-q1/msg00193.html

Sadly, loading the core file for lldb doesn't go so well...

BFD: Warning: /var/crash/core.internal-state.6.23639.mikesart-rad.1373391421 is truncated: expected core file size >= 339070976, found: 105598976.