[webkit-help] Help with possible buffer overflow (JS code) in our DFB port

[Alex Vazquez]

2010/8/2 demallien <demallien at me.com>

> Alejandro,
>
> From the description of the bug, it sounds an awful lot like you are
> calling into JSC from different threads.  It's not clear from your post if
> you can reproduce the bug when the code isn't all in the same file or not,
> but I would be double checking that you haven't changed anything with
> respect to when you call code.
>
>
The bug is not reproducible if the JS code is distributed in several files
and neither it is if the code is compressed.


> It's not really clearly marked in the documentation, but each JSAPI call
> that takes a JSContextRef as a parameter, needs all calls using that context
> to be made from the same thread, otherwise you get random corruption of the
> stack.
>
>
Actually, we are not using JSAPI, we are running the JS code from web pages
(we only use HTML + CSS + JS for the GUI) so we are not mixing calls from
different threads explicitely. It could be that the javascript engine is
behaving wrong, though, so we'll investigate that possibility.


> Hope that helps,
>
> Alli
>
>
Thank you for your help,


> We are using a DirectFB port of webkit as GUI renderer on an embedded
> device
> (MIPS architecture).
>
> We use a lot of Javascript code and we are experiencing random crashes when
> we bunch all that code in a single file without compressing it
> (yui-compressor). We suspect that we have some kind of buffer overflow that
> causes these random crashes since it almost never crashes on the same
> point).
>
> It is hard to determine exactly which is the file size limit, if this is
> the
> case, because it seems different for each execution (the memory corrupted
> may not be used for a long time) but we have reproduced the bug with a
> Javascript file of 300 KB. Also, we don't know if the bug is platform
> specific, architecture specific, etc ..
>
> Any idea of how to investigate this issue (source files where the
> Javascript
> files are read to memory, build variables/parameters that can affect this
> behaviour, or any other idea) is welcome.
>
> Thanks and kind regards,
>
> --
> Alejandro Vazquez Fente
>
>
> _______________________________________________
> webkit-help mailing list
> webkit-help at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
>
>


-- 
Alejandro Vazquez Fente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-help/attachments/20100802/99157b37/attachment.html>