520292 - Socorro fails to symbolize parts of crashes even when symbols are available

Status: RESOLVED INVALID

(Socorro :: General, task)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 1

[K Lars Lohn [:lars] [:klohn]]

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.

Comment 2

[(not currently active) Ted Mielczarek]

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.