Gabriele Svelto
Gabriele Svelto
Yesterday I stumbled upon [this crash](https://crash-stats.mozilla.org/report/index/44fc2a5e-2e21-432e-8956-974460220523) for which we only get the top stack frame: ``` 0 | pnrpnsp.dll | WppCleanupUm ``` Visual Studio yields a full trace: ``` wscapi.dll!WppCleanupUm()...
A small cosmetic issue I noticed is that we print an empty line between the bottom of the crashing thread's stack and the first thread like so: ``` 2 ntdll.dll!RtlDispatchException...
As part of the work to get rid of the ~~evil JSON~~ separate crash annotations file I've removed the `ThreadIdNameMapping` annotation and made sure that all our minidump writers fill...
We extract this field from `/proc/cpuinfo` in Linux minidumps but it's also available in (most) Windows ones as a [crash annotation](https://searchfox.org/mozilla-central/rev/b0c5c3b9821c2f22193fd6e1e9f66032639da1a1/toolkit/crashreporter/CrashAnnotations.yaml#234-237) in the .extra file. The version is stored as...
As per title and https://github.com/luser/rust-minidump/pull/245#issuecomment-945812018 Currently this would only be possible on Windows. On Linux we could implement it by parsing `/proc/self/maps` which is included in the minidumps, or we...
See [bug 1728963](https://bugzilla.mozilla.org/show_bug.cgi?id=1728963) on our tracker. The idea is to compute certain fields of the JSON output (such as AvailableVirtualMemory in 32-bit Windows minidumps and AvailablePageFile in all Windows minidumps)...
Breakpad introduced support for inlined functions and frames in revision [f0803507](https://chromium.googlesource.com/breakpad/breakpad/+/f0803507950279bd1e48d05f5fb4b4377c2917f7). Once we've got full support for stack unwinding using traditional Breakpad CFI we should support this too.
This stream isn't documented yet but it seems to be available by default in recent Windows minidumps. It's stream number is 21 (SystemMemoryInfoStream). The relevant section in the minidumpapiset.h file...
As per title. This seems to contain various bits of information about memory usage of the process. The stream number is 22 (ProcessVmCountersStream) and this is the relevant section in...
While processing debug information extracted from Fedora 34 packages I came across some ELF files that symbolic doesn't seem to parse correctly. This one for example: [libc-2.32.9000.so.debug](https://drive.google.com/file/d/1ge2bMpFvj-wkw4DongpjpzmxWt842drX/view?usp=sharing) Parsing it throws...