[webkit-dev] Webkit mipsel crashing in arenaDelete

[Stephan Assmus]

Hi,

On 2010-02-17 at 11:32:57 [+0100], Bharathwaaj S <bharathwaaj.s at gmail.com> 
wrote:
> I tried the same as mentioned by Stephan.
> 
> #if !defined(USE_SYSTEM_MALLOC) &&
> defined(NDEBUG)
> 
> #define FORCE_SYSTEM_MALLOC
> 0
> 
> #else
> 
> #define FORCE_SYSTEM_MALLOC
> 0
> 
> #endif

I might have led you onto the wrong track. Or maybe it is the right track to 
explain your crashing issues (the allocator), but my solution is probably 
wrong.

First of all, I have to explain that I am not the developer debugging the 
allocator issues on the Haiku port. This is what I understand: We did remove 
the USE_SYSTEM_MALLOC=1 define from our build system. We ran debug builds 
through a special version of Haiku's "libroot.so" which has an allocator with 
debugging facilities. As soon as USE_SYSTEM_MALLOC=1 was not defined anymore, 
the JavaScriptCore allocations did not show up anymore in this debugging 
allocator. However, later I have found out that wtf/Platform.h still defines 
USE_SYSTEM_MALLOC=1 for the Haiku port. So I don't know why (changing) the 
defines via our build system would have any affect at all. Maybe only 
changing FORCE_SYSTEM_MALLOC above actually had an effect, but it should only 
affect debug builds.

Finally, the Haiku port suffers random crashes in the JavaScriptCore code 
with regards to allocation at the moment (release/debug doesn't matter). We 
are working on the issue and as soon as I know more, I'll let you know. 
Second, I've found out that even though ENABLE_JSC_MULTIPLE_THREADS is not 
defined for Haiku, compiling TCSystemMalloc into the build will result in a 
scavenger thread running to periodically reclaim unused allocations (using 
the PThread backend). But ENABLE_JSC_MULTIPLE_THREADS is actually only 
supported on Windows and Mac. So I have no idea if that was healthy at all 
and I disabled the scavenger thread, since I presume if the rest of the code 
assumes to run single threaded, another thread doing garbage collection in 
parallel may result in havoc.

Still, this doesn't fix the random crashes of the Haiku port, which is why I 
believe we may have some screwup with regards to which allocator is being 
used at which time. It could as well be misaligned free()s that we saw, due 
to wrong assumptions in JSC when using the system allocator. Will let you 
know when I know more, but maybe the above can give you some helpful pointers 
what things to look into and confirm for your port.

Best regards,
-Stephan