NULL pointer crashes are now clearly flagged
114 views
Skip to first unread message
Gabriele Svelto
May 23, 2023, 5:07:12 AM5/23/23
to stability, crash-reporting-wg
Hello all,
after bug 1827416 went into production NULL pointer should be easier to
spot. Prior to the change the address might be non-NULL if an offset was
involved. For example the crash address of this crash:
https://crash-stats.mozilla.org/report/index/f15aabec-bd6e-4725-8401-40a240230523
... would have appeared as 0x00000000000002e8. That's because the
crashing instruction accessed a field of a structure and the pointer to
the structure was NULL. This was a very common occurrence. The crash now
displays the crash address as 0x0000000000000000 instead, making it
clear that this is a NULL pointer access, even when different builds are
involved which might have different offsets.
In case the raw address is needed you can still find it under the "Raw
Data and Minidumps" tab. The `crash_info.address` field will contain the
original address and a `crash_info.adjusted_address` field will be
placed with information about the replacement. Note that crashes
involving general protection faults are similarly handled the same way
(see this one for example
https://crash-stats.mozilla.org/report/index/1712b521-34d2-4c06-bbfe-137020230523).
Gabriele
after bug 1827416 went into production NULL pointer should be easier to
spot. Prior to the change the address might be non-NULL if an offset was
involved. For example the crash address of this crash:
https://crash-stats.mozilla.org/report/index/f15aabec-bd6e-4725-8401-40a240230523
... would have appeared as 0x00000000000002e8. That's because the
crashing instruction accessed a field of a structure and the pointer to
the structure was NULL. This was a very common occurrence. The crash now
displays the crash address as 0x0000000000000000 instead, making it
clear that this is a NULL pointer access, even when different builds are
involved which might have different offsets.
In case the raw address is needed you can still find it under the "Raw
Data and Minidumps" tab. The `crash_info.address` field will contain the
original address and a `crash_info.adjusted_address` field will be
placed with information about the replacement. Note that crashes
involving general protection faults are similarly handled the same way
(see this one for example
https://crash-stats.mozilla.org/report/index/1712b521-34d2-4c06-bbfe-137020230523).
Gabriele
Andrew McCreight
May 23, 2023, 9:52:17 AM5/23/23
to stability, crash-reporting-wg
Nice change! Does this affect all base addresses and not just null? In other words, if it crashes when accessing an offset of 4 into a base address of 0x12345, it'll show the address as 0x12345 and not 0x12349?
Thanks,
Andrew
Gabriele
--
You received this message because you are subscribed to the Google Groups "crash-reporting-wg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crash-reporting...@mozilla.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.com/d/msgid/crash-reporting-wg/899d9182-4e71-0772-44c6-729ea8678ebb%40mozilla.com.
For more options, visit https://groups.google.com/a/mozilla.com/d/optout.
Gabriele Svelto
May 23, 2023, 4:04:10 PM5/23/23
to Andrew McCreight, stability, crash-reporting-wg
On 23/05/2023 15:52, Andrew McCreight wrote:
> Nice change! Does this affect all base addresses and not just null? In
> other words, if it crashes when accessing an offset of 4 into a base
> address of 0x12345, it'll show the address as 0x12345 and not 0x12349?
We apply this change to NULL alone... but it would be trivial to apply
> Nice change! Does this affect all base addresses and not just null? In
> other words, if it crashes when accessing an offset of 4 into a base
> address of 0x12345, it'll show the address as 0x12345 and not 0x12349?
it everywhere, at least on x86.
Gabriele
Reply all
Reply to author
Forward
0 new messages