New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 717941 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-05-15
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Chromium fatal error on <div> with mjpg background-image

Reported by r.kee...@gmail.com, May 3 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.81 Chrome/58.0.3029.81 Safari/537.36

Steps to reproduce the problem:
1. Add div with background-image (<div class="maximize" id="camera-left"></div>)
2. Add the stream's mjpg address (example for me - 10.0.0.115/Streaming/channels/102/httppreview)
3. Start the stream on a lossy connection (I use a wireless data link with a 0.5W transmitter and 20mbps maximum bandwidth) The stream is set to refresh 3 times per second (change the background-image to = "", then add the address back)

What is the expected behavior?
Video stream is refreshed 3x per second in case of connection drops, but even when no video can be streamed, the only thing would be an address unreachable error.

What went wrong?
Sometimes, randomly, the whole web app will crash, and when running through the log, this is the stacktrace I get : 

[1:1:0503/134718.818972:FATAL:ImageResource.cpp(260)] Check failed: !getContent()->hasImage() || !errorOccurred(). 
#0 0x7f13bb80bd97 base::debug::StackTrace::StackTrace()
#1 0x7f13bb8283f7 logging::LogMessage::~LogMessage()
#2 0x7f139cd0c328 blink::ImageResource::allClientsAndObserversRemoved()
#3 0x7f13aa3b6a01 blink::Resource::didRemoveClientOrObserver()
#4 0x7f139cdf5b33 <unknown>
#5 0x7f13aa39d5ec blink::ThreadState::invokePreFinalizers()
#6 0x7f13aa39d9b4 blink::ThreadState::preSweep()
#7 0x7f13aa39de4f blink::ThreadState::collectGarbage()
#8 0x7f13aa39e3e8 blink::ThreadState::performIdleGC()
#9 0x7f13aa16281c <unknown>
#10 0x7f13aa2ea001 blink::scheduler::WebSchedulerImpl::runIdleTask()
#11 0x7f13aa2ea3a8 <unknown>
#12 0x7f13aa2e9686 <unknown>
#13 0x7f13aa2e9865 <unknown>
#14 0x7f13bb80d2d8 base::debug::TaskAnnotator::RunTask()
#15 0x7f13aa2e0cfa blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#16 0x7f13aa2e1da7 blink::scheduler::TaskQueueManager::DoWork()
#17 0x7f13bb80d2d8 base::debug::TaskAnnotator::RunTask()
#18 0x7f13bb833230 base::MessageLoop::RunTask()
#19 0x7f13bb834e6d base::MessageLoop::DeferOrRunPendingTask()
#20 0x7f13bb835c8d <unknown>
#21 0x7f13bb8360a9 base::MessagePumpDefault::Run()
#22 0x7f13bb832612 base::MessageLoop::RunHandler()
#23 0x7f13bb85d768 base::RunLoop::Run()
#24 0x7f13b63daf29 <unknown>
#25 0x7f13b64e33a8 <unknown>
#26 0x7f13b64e37ad <unknown>
#27 0x7f13b64e23b1 content::ContentMain()
#28 0x55f9f010bcf4 <unknown>
#29 0x7f13a6061830 __libc_start_main
#30 0x55f9f010bb99 <unknown>

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 58.0.3029.81  Channel: n/a
OS Version: 16.04
Flash Version: 

This is probably a really hard-to-reproduce bug that may require specific hardware and the application itself (driving a RC robot with a camera attached)
 
Labels: Needs-Feedback BugSource-User PaintTeamTriaged-20170503
NextAction: 2017-05-15
The randomness is probably related to the GC happening at unpredictable times.

Can you provide us with a test case the has the steps you describe in the report, even if it doesn't crash? We have ways to force GCs on predictable schedules and to simulate various network connections so we might be able to reproduce even if you can't.
Labels: Needs-Triage-M58
The NextAction date has arrived: 2017-05-15
Status: WontFix (was: Unconfirmed)
Closing due to lack of feedback. Please reopen if you can provide something to test with.

Sign in to add a comment