Émeric Maschino wrote:
Indeed, even with your updated packages, Epiphany still crashes with the scenario I described in this bug report
I looked for anything that is different on a release build and on a debug build. It turned out that a lot of code related to the memory heap is different in Source/JavaScriptCore/wtf/FastMalloc.cpp:
#if !(defined(USE_SYSTEM_MALLOC) && USE_SYSTEM_MALLOC) && defined(NDEBUG) #define FORCE_SYSTEM_MALLOC 0 #else #define FORCE_SYSTEM_MALLOC 1 #endif (Consider NDEBUG.)Webkit doesn't use its own heap implementation in FastMalloc.cpp on the debug build! When someone builds the release build all the buggy code runs and will make trouble. This was done to make debugging much easier :-). (Greetings from Google's sadists club.)
I didn't try to find all bugs in the fast malloc implementation. One thing I noticed which could break it on ia64 but works on x86-64 is the following in Source/JavaScriptCore/wtf/FastMalloc.cpp:1375:
// Return 0 if we have no information, or else the correct sizeclass for p.
// Reads and writes to pagemap_cache_ do not require locking.
// The entries are 64 bits on 64-bit hardware and 16 bits on
// 32-bit hardware, and we don't mind raciness as long as each read of
// an entry yields a valid entry, not a partially updated entry.
size_t GetSizeClassIfCached(PageID p) const {
return pagemap_cache_.GetOrDefault(p, 0);
}
void CacheSizeClass(PageID p, size_t cl) const {
pagemap_cache_.Put(p, cl); }
When different processor cores access one memory location - one processor at first, the second one at next - the processor cores excange the data through their caches as needed with their bus protocol automatically on x86 and x86-64. But on ia64 caches are not coherent automatically, the caches are flushed using memory barriers (some special machine instructions). When you use some dispatcher objects, for example, a mutex with the following pattern
- acquire the dispatcher object - read/write to the data location which are guarded by the dispatcher object, - release the dispatcher objectyou don't need to think on the cache coherency and memory barriers. The implementation of the dispatcher object does the memory barriers correctly for you.
When you start to do something own what has multiple threads but doesn't use any dispatcher object, you have to think on memory barriers. Ia64 isn't the only arch that requires this.
One approach would be building-in the needed memory barrier in FastMalloc.cpp. This would mean adding memory barrier definitions for a lot of architectures. You can take a look at the hw/xfree86/common/compiler.h file of the xserver-xorg-core package in order to get an idea what it would mean. So the second approach: We do no longer use the fast malloc implementation on ia64 as it is already done on Blackberry OS and on the Qt port of webkit on any OS other than UNIX.
An appropriate modification can be useful as well on other archs that require memory barriers, for example, alpha, powerpc.
So here is a new set of patches: 01-ia64-wide-ptr.patch at first, 02-ia64-use-system-malloc.patch at next. The patches are for the most recent libwebkitgtk-3.0-0 package of Wheezy. The patches don't change anything on archs other than ia64.The packages which were built with the patch of this bug report and the one of bug#694971 are here; the tar contains all debs which are created by the libwebkitgtk-3.0-0 source:
http://www.fs-driver.org/debian-ia64/webkitgtk-debs-v2.tar The patches also fix bug#582774 (seed FTBFS on ia64). Stephan
01-ia64-wide-ptr.patch
Description: 01-ia64-wide-ptr.patch
02-ia64-use-system-malloc.patch
Description: 02-ia64-use-system-malloc.patch
