1181148 - wrong symbols for [@ strncpy | js::DecompileValueGenerator(JSContext*, int, JS::Handle<T>, JS::Handle<T>, int) ]

Status: RESOLVED INCOMPLETE

(Socorro :: General, task)

Description

[[:philipp]]

filing this bug in accord with dmajor on irc, since apparently for
https://crash-stats.mozilla.com/report/index/f04217f0-990d-4b5b-93c0-fc4092150707 the symbols are wrong.

Comment 1

[(Away)]

MSVCR120 has enhanced inlining information. My debugger says this is not strncpy but rather:

(Inline) -------- msvcr120!cmpDWORD
(Inline) -------- msvcr120!unaligned_memcmp+0x7558
00206c24 02570ed2 msvcr120!memcmp+0xa2a
00206c64 02570dc3 xul!js::DecompileValueGenerator+0x53

I don't care too strongly about the inlined functions, but if not understanding them is going to make the "base" symbol incorrect, then that's kind of annoying. Ted, anything we can do here?

Comment 2

[(not currently active) Ted Mielczarek]

So the symbol file in question:
http://symbols.mozilla.org/msvcr120.i386.pdb/16F5E2EF340A453ABC8B8F67DC6FD8082/msvcr120.i386.sym

has:
FUNC 183c4 124 c strncpy

and the dump (looking at the raw dump tab) shows for frame 0:
 "module": "msvcr120.dll", "module_offset": "0x1843a", "offset": "0x5c843a",

...which puts it squarely inside strncpy as far as the symbol file indicates. Can you ask WinDBG about the symbol at that address? We're using DIA to dump symbols, so generally it does the right thing, but maybe there's something weird about this particular symbol file?

Comment 3

[(Away)]

Apparently those 0x124 bytes are not contiguous. strncpy starts at 183c4 as claimed, but at 18439 is a 'ret' and the instruction after that (1843a, our EIP) belongs to cmpDWORD. The instructions that make up strncpy resume at a later point.

Comment 4

[(not currently active) Ted Mielczarek]

Ouch, that's unfortunate. Oddly, if I look at that PDB in my local symbol cache on my Windows box and run dump_syms on it, I get only PUBLIC/STACK records, i.e. it's a stripped PDB. The one that we have on the symbol server appears to be from an unstripped PDB. I have no idea how that happened, we just fetch them from the Microsoft symbol server.

Dumping the one I have locally I just see:
$ grep 183c4 /tmp/msvcr.sym
PUBLIC 183c4 0 strncpy
STACK WIN 0 183c4 76 0 0 c 0 0 0 0 0

...but it does show unwind info for the record at 1843a:
$ grep 1843 /tmp/msvcr.sym
STACK WIN 4 1843a 16 0 0 c 0 0 0 1 $T0 $ebp = $eip $T0 4 + ^ = $ebp $T0 ^ = $esp $T0 8 + =
STACK WIN 4 1843a 16 0 0 c 4 0 0 1 $T0 $ebp = $eip $T0 4 + ^ = $ebp $T0 ^ = $esp $T0 8 + =  $20 $T0
4 - ^ =
STACK WIN 4 1843a 16 0 0 c 8 0 0 1 $T0 $ebp = $eip $T0 4 + ^ = $ebp $T0 ^ = $esp $T0 8 + =  $20 $T0
4 - ^ =  $23 $T0 8 - ^ =

The dump_syms code is primarily here if you want to poke at it:
https://code.google.com/p/google-breakpad/source/browse/trunk/src/common/windows/pdb_source_line_writer.cc

If you clone from svn you have to run gyp to generate MSVC projects to build with.

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

Pretty sure none of the bits for this bug are available now.

Philipp: Can we reproduce this with a crash report we currently have in Socorro? If not, I think we should mark this INCOMPLETE or something along those lines.

Comment 6

[[:philipp]]

there are still crashes with the [@ strncpy | js::DecompileValueGenerator] signature - all from before firefox 47 though: https://crash-stats.mozilla.com/signature/?signature=strncpy%20%7C%20js%3A%3ADecompileValueGenerator#reports
but i don't have access to minidumps, so i'm not the right person to judge if things are still going wrong there and how widespread the problem might be, if at all.

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

David, Ted: Do either of you know if this still an issue?

Comment 8

[(not currently active) Ted Mielczarek]

If it's not showing up in newer releases then let's just let this bug be.