Bug#642750: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform

[Stephan Schreiber]

É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 object
you 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01-ia64-wide-ptr.patch
Type: application/octet-stream
Size: 24381 bytes
Desc: 01-ia64-wide-ptr.patch
URL: <http://lists.alioth.debian.org/pipermail/pkg-webkit-maintainers/attachments/20121207/5008419f/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02-ia64-use-system-malloc.patch
Type: application/octet-stream
Size: 810 bytes
Desc: 02-ia64-use-system-malloc.patch
URL: <http://lists.alioth.debian.org/pipermail/pkg-webkit-maintainers/attachments/20121207/5008419f/attachment-0003.obj>