Wireshark · Wireshark-dev: [Wireshark-dev] Can ASAN be somehow tweaked to symbolicate its stack traces?

[Guy Harris <guy@xxxxxxxxxxxx>]

On Feb 5, 2016, at 1:30 PM, bugzilla-daemon@xxxxxxxxxxxxx wrote:

> Bug ID	12087
> Summary	Buildbot crash output: fuzz-2016-02-05-5267.pcap
> Product	Wireshark
> Version	unspecified
> Hardware	x86-64
> URL	https://www.wireshark.org/download/automated/captures/fuzz-2016-02-05-5267.pcap
> OS	Ubuntu

	...

> Problems have been found with the following capture file:

	...

> =================================================================
> ==2982==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x7f7fa3c48494 at pc 0x7f7fa1f3ee1e bp 0x7ffc28499600 sp 0x7ffc284995f8
> READ of size 4 at 0x7f7fa3c48494 thread T0
>     #0 0x7f7fa1f3ee1d 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x7985e1d)
>     #1 0x7f7fa18da2e1 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x73212e1)
>     #2 0x7f7fa18d83bc 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x731f3bc)
>     #3 0x7f7fa22a7136 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x7cee136)
>     #4 0x7f7fa18da2e1 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x73212e1)
>     #5 0x7f7fa18d9f7a 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x7320f7a)
>     #6 0x7f7fa1e0dd15 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x7854d15)
>     #7 0x7f7fa18da2e1 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x73212e1)
>     #8 0x7f7fa18d83bc 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x731f3bc)
>     #9 0x7f7fa18d7bd8 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x731ebd8)
>     #10 0x7f7fa18b833e 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x72ff33e)
>     #11 0x501145 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/bin/tshark+0x501145)
>     #12 0x4fb96b 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/bin/tshark+0x4fb96b)
>     #13 0x7f7f971f7ec4  (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
>     #14 0x43fc26 
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/bin/tshark+0x43fc26)
> 
> 0x7f7fa3c48494 is located 12 bytes to the left of global variable '<string literal>' defined in 'packet-ieee80211-radio.c:253:5' (0x7f7fa3c484a0) of size 7
>   '<string literal>' is ascii string '64-QAM'
> 0x7f7fa3c48494 is located 45 bytes to the right of global variable '<string literal>' defined in 'packet-ieee80211-radio.c:249:5' (0x7f7fa3c48460) of size 7
>   '<string literal>' is ascii string '16-QAM'
> Shadow bytes around the buggy address:
>   0x0ff074781040: 00 00 00 00 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00
>   0x0ff074781050: 00 00 00 00 00 05 f9 f9 f9 f9 f9 f9 06 f9 f9 f9
>   0x0ff074781060: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
>   0x0ff074781070: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
>   0x0ff074781080: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 07 f9 f9 f9
> =>0x0ff074781090: f9 f9[f9]f9 07 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
>   0x0ff0747810a0: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
>   0x0ff0747810b0: f9 f9 f9 f9 00 00 00 00 02 f9 f9 f9 f9 f9 f9 f9
>   0x0ff0747810c0: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
>   0x0ff0747810d0: 00 04 f9 f9 f9 f9 f9 f9 00 00 00 00 02 f9 f9 f9
>   0x0ff0747810e0: f9 f9 f9 f9 00 00 00 00 00 00 00 00 01 f9 f9 f9

OK, so either it managed to symbolicate 0x7f7fa3c48494 and 0x7f7fa3c48494 or it somehow found out in some *other* fashion that those pointers were before or after string literals defined on specific lines of a specific source file.

Is there some reason that it can't, or doesn't, translate the instruction addresses in the stack trace to lines of code in dissectors?