1310924 - AddressSanitizer: SEGV on unknown address 0x (pc 0x bp 0x sp 0x T0)

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: asan output

Found by bughunter and reproduced on latest taskcluster opt-asan build on fedora 24

Steps to reproduce:
-> Load http://www.cncf.com.br/?pg=fotos
--> Build crashed 

bughunter found so far with this signature over 300 urls where Firefox crashes with this signature

filing as s-s just in case

Comment 1

[Carsten Book [:Tomcat]]

decoder, mccr8: do you know who could take a look at that ?

Comment 2

[Andrew McCreight [:mccr8]]

This looks like an OOM. I went to the page, and it seemed to be loading a lot, so that's not too surprising.

Unfortunately it is not possible to tell anything more, because the stack at the end of the ASan report has not been symbolicated.

You should set ASAN_SYMBOLIZER_PATH=<path to llvm-symbolizer> when running ASan.

You might be able to run it out this output to get symbols.

The report starts with "==2568==ERROR: AddressSanitizer failed to allocate 0xfa02000 (262152192) bytes of LargeMmapAllocator (error code: 12)". In this case that's the more interesting bit of information than the SEGV.

Comment 3

[Andrew McCreight [:mccr8]]

You should probably just ignore these "AddressSanitizer failed to allocate" crashes in Bughunter, as they are likely just going to find bad pages. With non-ASan builds, we can at least distinguish between crashes from large allocations (which maybe we could fix) from crashes from a lot of small allocations (which are probably the page being bad).

Comment 4

[Christian Holler (:decoder)]

You should set ASAN_OPTIONS=allocator_may_return_null=1 as well. Without that, ASan will abort when a malloc fails, rather than returning NULL as it should be. With that option, the browser can try to recover the OOM.