clustc / google-breakpad

Automatically exported from code.google.com/p/google-breakpad
0 stars 0 forks source link

Does not catch signals #569

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Sorry for newbie question.I have libnative_exception_handler.so with breakpad 
init:

    google_breakpad::MinidumpDescriptor descriptor(".");
    google_breakpad::ExceptionHandler eh(descriptor, NULL, breakpad_callback, NULL, true, -1);

and libfunc.so which is not safe.

Both libs are loaded in android using `System.loadLibrary();`

if i breakpad init is done in `libnative_exception_handler.so` signals are not 
catched and breakpad callback is not invoked. if i change `libfunc.so` source 
to init breakpad signals are catched. So does breakpad need to be init in the 
same source file where unsafe function are?.

Original issue reported on code.google.com by d...@antonsmirnov.name on 10 Mar 2014 at 7:41

GoogleCodeExporter commented 9 years ago
demo lib and app: https://github.com/4ntoine/Acra-breakpad

Original comment by d...@antonsmirnov.name on 11 Mar 2014 at 9:18

GoogleCodeExporter commented 9 years ago
I am also getting the same error. From the behaviour, I believe breakpad is 
catching signals per thread. Please correct me if I am wrong.

Do we need to init breakpad with dump callback in every thread or its just 
something wrong with my set up?

Thanks for your help.

Original comment by rohit.wa...@gmail.com on 13 Mar 2014 at 11:11

GoogleCodeExporter commented 9 years ago
I do breakpad init in the same thread but it does not catch the signals (see 
github repo above)

Original comment by d...@antonsmirnov.name on 13 Mar 2014 at 11:12

GoogleCodeExporter commented 9 years ago
I doubt that. You are initializing breakpad in the main application thread and 
the crash is happening in a UI thread.

Original comment by rohit.wa...@gmail.com on 13 Mar 2014 at 11:23

GoogleCodeExporter commented 9 years ago
AFAIK there is no "app thread" and it's single UI thread.

Original comment by d...@antonsmirnov.name on 13 Mar 2014 at 11:25

GoogleCodeExporter commented 9 years ago
I've checked it and i'm absolutely sure it's the same UI thread:

// Application.onCreate()
"<1> main"@830 028 261 120 in group "main": RUNNING

// button clicked
"<1> main"@830 028 261 120 in group "main": RUNNING
testCatch():38, MainActivity {name.antonsmirnov.android.acra_breakpad.app}
access$000():8, MainActivity {name.antonsmirnov.android.acra_breakpad.app}
onClick():29, MainActivity$1 {name.antonsmirnov.android.acra_breakpad.app}
performClick():4171, View {android.view}

Original comment by d...@antonsmirnov.name on 13 Mar 2014 at 11:41

GoogleCodeExporter commented 9 years ago
breakpad init is done in Application.onCreate() (see app code)

Original comment by d...@antonsmirnov.name on 13 Mar 2014 at 11:48

GoogleCodeExporter commented 9 years ago
Breakpad simply initializes a POSIX signal handler. These are process-wide. 
Your problem is that you are creating the ExceptionHandler class on the stack:
https://github.com/4ntoine/Acra-breakpad/blob/master/lib/jni/native_exception_ha
ndler.cpp#L72

The ExceptionHandler class is an RAII-type class, so it will install the signal 
handlers in its constructor, and then remove them in a destructor. If you want 
this to work you'll need to heap-allocate it and store it in a global variable 
somewhere.

Original comment by ted.mielczarek on 13 Mar 2014 at 12:22

GoogleCodeExporter commented 9 years ago
it helped, thanks. Probably you should change your android app code to 
demonstrate this as now it's misleading and i used the code from example.

Original comment by d...@antonsmirnov.name on 13 Mar 2014 at 2:59