[Webkit-unassigned] [Bug 130122] W32: Use-after-free in WTF threading code

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from LRN <lrn1986 at gmail.com>  2014-04-11 12:54:03 PST ---
(In reply to comment #3)
> I'm not convinced about the root cause. There is no way ThreadSpecificThreadExit() could possibly change the value of invocation - it's an object allocated on the stack. It also cannot touch ThreadFunctionInvocation - first, it doesn't delete heap objects, and second, this particular object was created on a different thread in the first place.

Invocation object is allocated on stack, but it seems to allocate something on the heap too (either invocation constructor, or adoptPtr() or something else in that line - i have no way to debug this, because C++).

> 
> Perhaps FastMalloc becomes entirely unusable after ThreadSpecificThreadExit()? That seems possible, and if so, the fix would address the crash. It may be that a better fix would be inside FastMalloc code.

Possible.


> 
> Could you please post steps to reproduce this crash?

Build webkitgtk, run "GtkLauncher.exe http://google.com"

> 
> See also: bug 44137.

Can't tell whether it's related or not.

(In reply to comment #4)
> It looks like this was encountered on a Gtk+-in-Windows environment.

Correct.

> I wonder if there's something different about the threading models in that context? Doesn't the Gtk build (even on Windows) use pthreads?

GTK+ itself doesn't have threads, glib does. Glib can be built with W32 threads or with POSIX threads.
I'm not sure whether this affects WebKit, since it seems to be using its own threading code.

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