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

[Émeric Maschino]

Hi Stephan,

I used your patched packages the passed week for my homeworks.
Stability is far better than the first patchset. With the notable
exception of the Google homepage. I don't know what's going wrong and
if other URLs are also affected. Let me explain.

Opening Epiphany with a blank page as startup page, typing
www.google.com in the bar address and clicking on Enter briefly goes
to the Google homepage and Epiphany immediately crashes. This is not a
history problem as going to the e.g. Debian homepage from the blank
page runs as expected. Then, from the Debian homepage, if you try to
go to the Google homepage, Epiphany crashes.

Now, the funny thing: from the blank page, if you visit the GMail
homepage first, and then the Google homepage, no problem! You can even
go back to the blank page and then visit the Google homepage without
crashing Epiphany. So the position in the history doesn't matter. I
don't know what the GMail homepage triggers that makes the Google
homepage work, but here is it. Just a remark: you don't have to visit
the GMail homepage right before the Google homepage. You can visit
other homepages in between. It's just that if you didn't visit the
GMail homepage before going to the Google homepage, Epiphany will
crash.

I know it's not a fantastic information, but that's the only
reproducible scenario I have that makes Epiphany crashes with your
updated packages.

Let me know if additional tests are welcomed.

     Émeric


2012/12/7 Stephan Schreiber <info at fs-driver.org>:
> É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
>