Hi, On 2010-02-17 at 11:32:57 [+0100], Bharathwaaj S <[email protected]> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
