Well that is both good news and bad news. The good news is that the
fix is very easy (is someone working on it as we speak?) and it fixes
the crash I am seeing. The bad news is how come this has been working
for so long? How come LayoutTests/plugins/plugin-javascript-
access.html doesn't fail every time it is run?
On Jul 25, 2007, at 4:19 PM, Darin Adler wrote:
On Jul 25, 2007, at 1:02 PM, Patrick Hanna wrote:
I am running into a segmentation fault in
Collector::collectOnMainThreadOnly on the line that reads:
cellBlock(cell)->collectOnMainThreadOnly.set(cellOffset(cell));
I believe that the reason is because the address passed in as
'value' is the address of a stack variable.
OK. That doesn't make sense. A JSValue should either be an
immediate value (which is not a pointer at all) or a JSCell. All
JSCell objects are allocated by the collector. There should not be
any JSCell on the stack.
This address comes from PluginsFunc::callAsFunction. PluginBase is
created on the stack and the constructor for DOMObject calls
Collector::collectOnMainThreadOnly with 'this' as the parameter.
There is a serious bug in that function! It's illegal to allocate a
JSObject except with the GC allocator. JavaScriptCore should really
be changed so that it asserts this at runtime when such objects are
created, or even better, prevents code from even compiling that
does this.
The fix for this particularly bug is simple. The refresh function
from PluginBase needs to be changed into a static member function,
and PluginsFunc::callAsFunction should not attempt to construct a
PluginBase object -- it should just call PluginBase::refresh.
My question is, should Collector::collectOnMainThreadOnly work
with stack pointers?
No, it should not.
-- Darin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
