1. Peter Hosey
  2. Symbolicator
Issue #2 resolved

Truncated library/framework name aborts the symbolification

Mattias Arrelid
created an issue

If a crash report contains a thread which uses a symbol from a library with a long name, that name will be truncated. Example:

{{{ Thread 4: 0 libSystem.B.dylib 0x900341c6 mach_msg_trap + 10 1 libSystem.B.dylib 0x9003b9bc mach_msg + 72 2 ....audio_hijack_server.hermes 0x002224ce ah_serv_loop + 109 3 libSystem.B.dylib 0x90065095 _pthread_start + 321 4 libSystem.B.dylib 0x90064f52 thread_start + 34 }}}

The above state will make symbolification crash with a traceback like this:

{{{ Traceback (most recent call last): File "/usr/local/bin/symbolicator", line 238, in <module> main() File "/usr/local/bin/symbolicator", line 230, in main flush_buffers() File "/usr/local/bin/symbolicator", line 176, in flush_buffers sys.stdout.write(symbolicate_backtrace_line(line)) File "/usr/local/bin/symbolicator", line 146, in symbolicate_backtrace_line function_info = look_up_address_by_bundle_ID(bundle_ID, address) File "/usr/local/bin/symbolicator", line 70, in look_up_address_by_bundle_ID dSYM_path = find_dSYM_by_bundle_ID(bundle_ID) File "/usr/local/bin/symbolicator", line 50, in find_dSYM_by_bundle_ID return find_dSYM_by_UUID(binary_images[bundle_ID]) KeyError: '....audio_hijack_server.hermes' }}}

Either you could make a best effort to guess the name [1], or you could just skip that line.

[1] Looking in the "binary images" section at the bottom of the crash report will reveal that the line causing trouble is associated with the library "com.rogueamoeba.audio_hijack_server.hermes"

Comments (8)

  1. Peter Hosey repo owner

    What I meant was “say on the ticket that you're going to fix it”, which you've done. ☺

    It's not the fix I had in mind, but it should solve the problem, so I'll pull it. If you want or anyone else wants to move to the address-range solution, that patch remains welcome.

  2. Log in to comment