Closed Bug 810381 Opened 12 years ago Closed 11 years ago

Intermittent test_streams_element_capture.html,test_streams_element_capture_createObjectURL.html | application crashed [@ FastConvertYUVToRGB32Row_C],[@ mozilla::gfx::yuv_to_rgb565_row_c(unsigned short*, unsigned char const*, unsigned char const*, ...]

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: crash, intermittent-failure)

Crash Data

https://tbpl.mozilla.org/php/getParsedLog.php?id=16890240&tree=Mozilla-Inbound Android no-ionmonkey Tegra 250 mozilla-inbound opt test mochitest-2 on 2012-11-09 01:28:00 PST for push f2e49ecb6779 slave: tegra-298 21036 INFO TEST-PASS | /tests/content/media/test/test_streams_element_capture.html | 320x240.ogv checking playback has ended INFO | automation.py | Application ran for: 0:08:31.486125 INFO | automation.py | Reading PID log: /tmp/tmpJb37sPpidlog getting files in '/mnt/sdcard/tests/profile/minidumps/' Downloading symbols from: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android-noion/1352451992/fennec-19.0a1.en-US.android-arm.crashreporter-symbols.zip PROCESS-CRASH | /tests/content/media/test/test_streams_element_capture.html | application crashed (minidump found) Crash dump filename: /tmp/tmpEbV7Or/54354ff0-40ea-1e7d-292cb226-4ce8578f.dmp Operating system: Android 0.0.0 Linux 2.6.32.9-00002-gd8084dc-dirty #1 SMP PREEMPT Wed Feb 2 11:32:06 PST 2011 armv7l nvidia/harmony/harmony/harmony:2.2/FRF91/20110202.102810:eng/test-keys CPU: arm 0 CPUs Crash reason: SIGSEGV Crash address: 0x5e9d501c Thread 4 (crashed) 0 libxul.so!FastConvertYUVToRGB32Row_C [yuv_row_c.cpp : 57 + 0x0] r4 = 0x00000000 r5 = 0x5a421000 r6 = 0x5a421000 r7 = 0x00000001 r8 = 0x5e9d501c r9 = 0x5e9e7c1c r10 = 0x5e9ec71c fp = 0x00000140 sp = 0x4e7e4688 lr = 0x5513417b pc = 0x551342e6 Found by: given as instruction pointer in context 1 libxul.so!mozilla::gfx::ConvertYCbCrToRGB32(unsigned char const*, unsigned char const*, unsigned char const*, unsigned char*, int, int, int, int, int, int, int, mozilla::gfx::YUVType) [yuv_convert.cpp : 104 + 0x9] r4 = 0x00000001 r5 = 0x5e9d501c r6 = 0x5a421000 r7 = 0x00000001 r8 = 0x00000000 r9 = 0x00000140 r10 = 0x5858fc00 fp = 0x000058fc sp = 0x4e7e46b0 pc = 0x5513417b Found by: call frame info 2 libxul.so!gfxUtils::ConvertYCbCrToRGB(mozilla::layers::PlanarYCbCrImage::Data const&, gfxASurface::gfxImageFormat const&, nsIntSize const&, unsigned char*, int) [gfxUtils.cpp : 767 + 0x1f] r4 = 0x53d6fed4 r5 = 0x5a421000 r6 = 0x00000500 r7 = 0x00000000 r8 = 0x4e7e475c r9 = 0x00000000 r10 = 0x5858fc00 fp = 0x000058fc sp = 0x4e7e4700 pc = 0x550fc55d Found by: call frame info 3 libxul.so!mozilla::layers::PlanarYCbCrImage::GetAsSurface() [ImageContainer.cpp : 502 + 0xf] r4 = 0x53d6fea0 r5 = 0x53d7f760 r6 = 0x53d6ff18 r7 = 0x53d6fed4 r8 = 0x4e7e47b0 r9 = 0x00000000 r10 = 0x5858fc00 fp = 0x000058fc sp = 0x4e7e4748 pc = 0x5510e0f5 Found by: call frame info 4 libxul.so!mozilla::layers::SharedPlanarYCbCrImage::GetAsSurface() [ImageContainerChild.cpp : 495 + 0x3] r4 = 0x51c9d180 r5 = 0x4e7e47b0 r6 = 0x4e7e4780 r7 = 0x00000000 r8 = 0x4e7e47b0 r9 = 0x00000000 r10 = 0x5858fc00 fp = 0x000058fc sp = 0x4e7e4778 pc = 0x5512772d Found by: call frame info 5 libxul.so!mozilla::layers::ImageContainer::GetCurrentAsSurface(nsIntSize*) [ImageContainer.cpp : 323 + 0x5] r4 = 0x51c9d180 r5 = 0x4e7e47b0 r6 = 0x4e7e4780 r7 = 0x00000000 r8 = 0x4e7e47b0 r9 = 0x00000000 r10 = 0x5858fc00 fp = 0x000058fc sp = 0x4e7e4780 pc = 0x5510e79f Found by: call frame info 6 libxul.so!nsLayoutUtils::SurfaceFromElement(nsHTMLVideoElement*, unsigned int) [nsLayoutUtils.cpp : 4486 + 0x3] r4 = 0x4e7e484c r5 = 0x00000000 r6 = 0x53c2cef0 r7 = 0x00000000 r8 = 0x4e7e47b0 r9 = 0x00000000 r10 = 0x5858fc00 fp = 0x000058fc sp = 0x4e7e47a0 pc = 0x5491d94d Found by: call frame info 7 libxul.so!nsLayoutUtils::SurfaceFromElement(mozilla::dom::Element*, unsigned int) [nsLayoutUtils.cpp : 4521 + 0x7] r4 = 0x4e7e484c r5 = 0x00000004 r6 = 0x53c2cef0 r7 = 0x4e7e49c8 r8 = 0x00000000 r9 = 0x00000000 r10 = 0x5858fc00 fp = 0x000058fc sp = 0x4e7e47e0 pc = 0x5491de3f
Whiteboard: [orange]
Summary: Intermittent crash [@ FastConvertYUVToRGB32Row_C] in test_streams_element_capture.html → Intermittent Android crash in test_streams_element_capture.html [@ FastConvertYUVToRGB32Row_C]
Crash Signature: [@ FastConvertYUVToRGB32Row_C]
Summary: Intermittent Android crash in test_streams_element_capture.html [@ FastConvertYUVToRGB32Row_C] → Intermittent Android test_streams_element_capture.html, test_streams_element_capture_createObjectURL.html | application crashed [@ FastConvertYUVToRGB32Row_C]
Chris, can you take a look at this top orange please? :-)
Flags: needinfo?(chris.double)
Summary: Intermittent Android test_streams_element_capture.html, test_streams_element_capture_createObjectURL.html | application crashed [@ FastConvertYUVToRGB32Row_C] → Intermittent test_streams_element_capture.html,test_streams_element_capture_createObjectURL.html | application crashed [@ FastConvertYUVToRGB32Row_C],[@ mozilla::gfx::yuv_to_rgb565_row_c(unsigned short*, unsigned char const*, unsigned char const*, ...]
File in question appears to be sourced by Roc, I defer to him to comment.
Flags: needinfo?(chris.double) → needinfo?(roc)
Passing the buck to Tim
Flags: needinfo?(roc) → needinfo?(tterribe)
(In reply to Chris Double (:doublec) from comment #168) > File in question appears to be sourced by Roc, I defer to him to comment. 3.5 months to find out it should be punted to someone else is slightly frustrating :-(
Hard to say what's going on here just from the log (there's no function parameter values, the register dump is missing registers, and gcc is doing the register allocation itself, so I'm not sure which registers map to which values anyway), but most likely someone is passing in a buffer that is the wrong size (which puts it back in roc's domain). I could trace the logic back as far as ShmemYCbCrImage::ComputeMinBufferSize(), which looks kosher as far as it goes, but doesn't tell me where aYSize and aCbCrSize come from. Coming from the other direction, the actual sizes of the videos used in the test don't look like they would trigger any common bugs (no odd width/height, etc.). Would probably need to see this in a debugger, and my Android config is so out of date that'll probably take a bit of work.
Flags: needinfo?(tterribe)
Thanks. This is happening at a low rate (none for a whole month recently) so will probably be very difficult to catch in a debugger. I don't have any good ideas.
Closing inactive keywords:intermittent-failure bugs where the TBPLbot has previously commented and the test isn't marked as disabled; filter on orange-cleanup-201401.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.