Crash going back twice while loading a page

I can reproduce (although not 100% of the times) on desktop too. Here is how the backtrace looks like when ran in gdb:

#0 QCoreApplication::postEvent (receiver=0x3b78820, event=0x7fff40041990, priority=0)
    at kernel/qcoreapplication.cpp:1284
#1 0x00007ffff649945e in QQuickPixmapReader::processJob (this=0x3984d80, runningJob=0x3b78820, url=...,
    requestSize=...) at util/qquickpixmapcache.cpp:563
#2 0x00007ffff6499f84 in QQuickPixmapReader::processJobs (this=0x3984d80) at util/qquickpixmapcache.cpp:526
#3 0x00007ffff649a2bd in QQuickPixmapReaderThreadObject::event (this=<optimized out>, e=<optimized out>)
    at util/qquickpixmapcache.cpp:480
#4 0x00007ffff593b16c in QApplicationPrivate::notify_helper (this=0x672610, receiver=0x7fff400013a0, e=0x3b6dd70)
    at kernel/qapplication.cpp:3504
#5 0x00007ffff594041e in QApplication::notify (this=0x7fffffffdc70, receiver=0x7fff400013a0, e=0x3b6dd70)
    at kernel/qapplication.cpp:3287
#6 0x00007ffff797981b in QCoreApplication::notifyInternal (this=0x7fffffffdc70, receiver=0x7fff400013a0,
    event=event@entry=0x3b6dd70) at kernel/qcoreapplication.cpp:935
#7 0x00007ffff797b7e3 in sendEvent (event=0x3b6dd70, receiver=<optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
#8 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0,
    data=0x3980450) at kernel/qcoreapplication.cpp:1539
#9 0x00007ffff797bde8 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0,
    event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1397
#10 0x00007ffff79d0a63 in postEventSourceDispatch (s=0x7fff400012d0) at kernel/qeventdispatcher_glib.cpp:279
#11 0x00007ffff3c3ec5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff3c3ef48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff3c3effc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff79d0e57 in QEventDispatcherGlib::processEvents (this=0x7fff400008c0, flags=...)
    at kernel/qeventdispatcher_glib.cpp:426
#15 0x00007ffff7977042 in QEventLoop::exec (this=this@entry=0x7fff55f3bdd0, flags=..., flags@entry=...)
    at kernel/qeventloop.cpp:212
#16 0x00007ffff773b4a4 in QThread::exec (this=this@entry=0x3984d80) at thread/qthread.cpp:511
#17 0x00007ffff649a346 in QQuickPixmapReader::run (this=0x3984d80) at util/qquickpixmapcache.cpp:688
#18 0x00007ffff77402ee in QThreadPrivate::start (arg=0x3984d80) at thread/qthread_unix.cpp:345
#19 0x00007ffff4ab90a5 in start_thread (arg=0x7fff55f3c700) at pthread_create.c:309
#20 0x00007ffff4dc984d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

It seems the issue is with the custom FaviconImageProvider class when a request for a favicon is issued and almost instantly cancelled.

I tested a "fix" similar to https://code.launchpad.net/~jpakkane/unity8/threadfix/+merge/206948, but that didn’t help, the crash is still happening. I need to dig further in QtQuick’s internals to understand how requests to custom image providers are issued and cancelled.

I’ve spent some more time investigating the issue, and it looks to me like it could be a bug in Qt itself. I’ve filed https://bugreports.qt-project.org/browse/QTBUG-42875 upstream. While I’m waiting for confirmation, I’m going to disable the custom favicon image provider to get rid of the crashes.

The side effect of this work around is that favicons will no longer be cached to disk, which will result in them having to be refetched when the browser is closed and restarted. The biggest hit would be the history page, which when opened will fetch all the favicons that are visible in the view.

I can reproduce it when you quickly tap twice / multiple times

It survives when you tap multiple times, but less rapidly (still << 1s).

I confirmed this is broken in krillin rtm 169, and added it to to the QA regression test plan.

I had to go back and forth several times to trigger the crash, but it still happened within a minute or so.

I’m working on a proper fix, thanks to Florian’s help in nailing the issue. I will make sure the fix comes with a unit test, so that the above entry can eventually be removed from the test plan.

This bug was fixed in the package webbrowser-app - 0.23+15.04.20141202-0ubuntu1

---------------
webbrowser-app (0.23+15.04.20141202-0ubuntu1) vivid; urgency=low

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Olivier Tilloy ]
  * Replace the custom favicon image provider with a FaviconFetcher
    component that better handles cancelling pending requests. (LP:
    #1395748)
 -- Ubuntu daily release <email address hidden> Tue, 02 Dec 2014 09:22:48 +0000

This was a late waiver on rtm so ok to land now

This bug was fixed in the package webbrowser-app - 0.23+15.04.20141202~rtm-0ubuntu1

---------------
webbrowser-app (0.23+15.04.20141202~rtm-0ubuntu1) 14.09; urgency=low

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Olivier Tilloy ]
  * Replace the custom favicon image provider with a FaviconFetcher
    component that better handles cancelling pending requests. (LP:
    #1395748)
 -- Ubuntu daily release <email address hidden> Tue, 02 Dec 2014 12:29:06 +0000