[webkit-dev] Javascript collector

[Patrick Hanna]

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
>