[lldb-dev] linux: LLDB python API inconsistent with lldb tool

Ben Nagy ben at iagu.net
Sun Jun 7 00:20:54 PDT 2015

Hi all,

I have kind of a strange problem. First of all, here is the short version.

My crash analysis tool
https://github.com/bnagy/francis/tree/master/exploitaben works fine on
OSX, but on linux it fails to correctly handle some ( but not all )
faulting programs. The lldb tool in the same environment and on the
same inputs works as expected. Ubuntu 15.04, lldb 3.6.

Here's the longer version.

I am analysing crashes (from afl-fuzz, which _may_ be involved). The
basic harness in exploitaben.py is a light modification of one of the
LLDB API example tools process_events.py. It has worked correctly for
many crashes on OSX, so I feel like the basic approach is sound. Here
are some observations.

I built the basic tests from https://github.com/jfoote/exploitable.
When I run, for example

exploitaben.py -- ~/src/exploitable/exploitable/tests/bin/testAbortSignal.test

I get correct output.

When I run a fault, like

exploitaben.py -- pdftoppm -r 16

I get

[ABORT] no valid frames in faulting thread

Which is my message, based on: if not

The same test in lldb:

fuzzadmin at ebx:~/afl/poppler-0.33.0$ lldb -- pdftoppm -r 16
(lldb) target create "/home/fuzzadmin/afl/poppler-0.33.0/utils/pdftoppm"
Current executable set to
'/home/fuzzadmin/afl/poppler-0.33.0/utils/pdftoppm' (x86_64).
(lldb) settings set -- target.run-args  "-r" "16"
(lldb) run

Process 7770 launching
Process 7770 launched:
'/home/fuzzadmin/afl/poppler-0.33.0/utils/pdftoppm' (x86_64)
[snip many Syntax Errors]
Syntax Error: Pages top-level is a single Page. The document is
mal-formet, trying to recover...
Internal Error (0): Call to Object where the object was type 7, not
the expected type 9
Process 7770 stopped

* thread #1: tid = 7770, 0x00007ffff6434267 libc.so.6`gsignal + 55,
name = 'pdftoppm', stop reason = signal SIGABRT
    frame #0: 0x00007ffff6434267 libc.so.6`gsignal + 55
-> 0x7ffff6434267 <gsignal+55>: cmpq   $-0x1000, %rax
   0x7ffff643426d <gsignal+61>: ja     0x7ffff6434290            ; gsignal + 96
   0x7ffff643426f <gsignal+63>: rep
   0x7ffff6434270 <gsignal+64>: retq

I have tested the target built with vanilla gcc, vanilla clang, with
afl instrumentation ( see the afl project for details) and with afl +
clang instrumentation. None work correctly.

At the moment I am at a loss as to how to debug this issue further.
Does anyone have any ideas? If you would prefer to reproduce for
yourself, here's my environment:

poppler-0.33 built from source with ./configure --disable-shared
--disable-poppler-qt4 --disable-poppler-qt5
afl-fuzz v 1.80b
Python 2.7.9
lldb 3.6.0
Ubuntu 15.04

I can provide one of my crashing inputs if required. You can also find
me lurking on #lldb at the moment.



More information about the lldb-dev mailing list