[Webkit-unassigned] [Bug 99142] fileReader abort case causes Chromium renderer crash

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=99142





--- Comment #14 from Ningxin Hu <ningxin.hu at intel.com>  2012-10-14 23:02:15 PST ---
(In reply to comment #13)
> (In reply to comment #12)
> > > I don't know... Given that the change looks reasonable and that you've manually tested, it would be OK to land it without tests. (It would be better to describe the situation in ChangeLog, instead of "No new tests".)
> > 
> > Could you please elaborate? I don't see how either would be an excuse for not making a regression test.
> 
> Ningxin Hu: I confirmed that the failure doesn't happen on DRT, but would you explain why the failure happens in a multi-threaded environment only? Also, maybe you can write a regression test using workers?

Have you ever confirmed the failure in Chromium browser? It should be explicit since load event is fired before abort event.
For the reason, I can figure out that after test calls FileReader.abort which invokes FileReader::abort. In FileReader::abort, it schedules delayedAbort to handle real aborting (including call FileReader::terminate). But when use Chromium to run the test case, FileReader::didFinishLoading is invoked before delayedAbort. So failure happens.
I didn't mention it happens in multi-threaded environment. I mean it should be related to resource loading behavior difference. As you know, the DRT and Chromium uses different resource loader implementation, for example, DRT uses test_shell/simple_resource_loader_bridge.cc in single-process mode, however Chromium uses multi-process resource loading.
So I think it doesn't help to have a worker to run this case. If it really needs a regression test, we need the test infrastructure to support, say to let Chromium run the layout tests.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.