1. Consider the following Camino 2.0b4 crashes in libnspr4.dylib (url above): bp-1b7b7ce1-cb9d-4e83-8eff-8fe0b2091001 bp-8748ea9a-b2c0-429d-bd7d-a05242091001 2. Observe that libnspr4.dylib is not symbolized in these crashes. 3. Observe that the module ID of libnspr4.dylib in each case is 51C5DAD348AC42F68C329FA2EB83C7610 4. Observe that the module ID for Camino 2.0b4 Intel is also 51C5DAD348AC42F68C329FA2EB83C7610 (see http://symbols.mozilla.org/symbols_camino/Camino-2.0b4-2009091516-i386-symbols.txt) 5. Wonder why Socorro has not symbolized that frame in these crashes.
I've verified that Socorro is configured properly to find those symbols and pass them on to minidump-stackwalk. Socorro just displays the output of that program from the Breakpad project. This looks like a Breakpad problem, not a Socorro one. I've copied Ted so he can give his assessment.
It did symbolize NSPR. Look at the other threads, they contain stack frames with NSPR symbols. If you look at the NSPR symbols: http://symbols.mozilla.org/symbols_camino/libnspr4.dylib/51C5DAD348AC42F68C329FA2EB83C7610/libnspr4.dylib.sym You can see that there is no function at 0x200d9 (the last function listed ends at 0x200a7 + 0x13). What probably happened here is that your instruction pointer somehow wound up in a bad place that just happened to be inside NSPR's address space. The line before that is clearly a call to PR_AtomicDecrement, which is @0xa4f8, so I don't know what happened in this particular crah.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.