Memory corruption crashes without stack traces are not grouped together

[pbajurko]

Expected behavior

On our android client we see a lot of reports like that:

Observed behavior

Every reported event is segmented as separated error because of different memory address. So we end up with thousands of 1 event errors, what doesn't help with assessing severity.

Steps to reproduce

We cannot reproduce issue locally atm. Though from breadcrumbs it happens after users close app so maybe some GC related issue.

Version

5.0.0

Additional information

1. I would like to understand how such event without any stacktrace can be produced.
2. I will try do some event processing on client side with custom hash grouping like described here. Any tips on error matching would be appreciated.

[johnkiely1]

Hi @pbajurko

You should be able to group the errors by errorClass alone, https://docs.bugsnag.com/product/error-grouping/#error-class
which would give you the grouping behaviour you are looking for. This would only apply to new occurrences of events and will not regroup existing ones.

I'd like to look into this a little bit more for you, but will need some information from the events themselves. Would you be able to write in to us at support@bugsnag.com providing some links to a couple of the errors as they appear in your Bugsnag dashboard. Thanks

[pbajurko]

Hmm not sure about error class since we have other memory corruptions with full stack traces and those are grouped fine, so I don't wanna lump them together.

I will write email with details thanks!

[pbajurko]

Following example I added observer for native crashes and grouped them with such snippet

bool group_crashes_with_empty_stacktraces(void *event) {
    if (const char *errorClass = bugsnag_error_get_error_class(event)) {
        if (nullptr != strstr(errorClass, "SIGSEGV") &&
            bugsnag_event_get_stacktrace_size(event) < 3) {
            bugsnag_event_set_grouping_hash(event, "SIGSEGV without stacktrace");
        }
    }
    return true;
}

It works fine, thanks @johnkiely1 for all suggestions. Now if we can not figure out cause of those exceptions I suppose we may just discard them. If you guys don't think it is worth to improve grouping events with empty stack-traces on backend side I think we can close this issue.

[johnkiely1]

Hi pbajurko,

I'm glad you found a solution that works. I will close this for now but feel free to comment here if anything extra crops up and we can reopen as needs be.

[pbajurko]

While Bugsnag SDK does not catch any meaningful stack trace in this particular case, on Playstore crash dashboard we can find:

#00  pc 0000007b57492c84  <unknown>
#01  pc 000000000001ba58  /system/lib64/libc.so (__cxa_thread_finalize+40)
#02  pc 0000000000067e6c  /system/lib64/libc.so (pthread_exit+20)
#03  pc 0000000000067d60  /system/lib64/libc.so (__pthread_start(void*)+292)
#04  pc 000000000001f348  /system/lib64/libc.so (__start_thread+68)

Which seems to be related to platform issue and calling dlclose before thread destructors . @johnkiely1 any idea why there is discrepancy between Bugsnag and Playstore crash reports?

[johnkiely1]

Hi @pbajurko,
Google records crashes using an out-of-process crash reporter so they can have access to things we don't, which is likely the case here. We would need to investigate this some more to fully understand the differences and confirm that.

Do you have any links to existing individual Bugsnag events and their equivalent playstore crash (screenshots) for us to compare. Or are you able to reproduce this (in isolation) and send us the relevant comparison link/screenshot?

You can send us that information via support@bugsnag.com
Thanks

[johnkiely1]

Hey @pbajurko, going to close this as we have continued the discussion via email.

For future travellers:

While we have not been able to reproduce the exact issue seen here, we have made significant improvements in the way we capture NDK stacktraces in v5.21.0 of our Android notifier. We would advise upgrading to this version which should give more complete stack traces.