Debian Bug report logs - #642750
epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform

version graph

Package: src:webkit; Maintainer for src:webkit is Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>;

Reported by: Émeric Maschino <emeric.maschino@gmail.com>

Date: Sat, 24 Sep 2011 21:27:01 UTC

Severity: grave

Tags: patch

Found in versions webkitgtk/2.0.4-2, webkit/1.8.1-3.3

Done: Stephan Schreiber <info@fs-driver.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Josselin Mouette <joss@debian.org>:
Bug#642750; Package epiphany-browser. (Sat, 24 Sep 2011 21:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Émeric Maschino <emeric.maschino@gmail.com>:
New Bug report received and forwarded. Copy sent to Josselin Mouette <joss@debian.org>. (Sat, 24 Sep 2011 21:27:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Émeric Maschino <emeric.maschino@gmail.com>
To: submit@bugs.debian.org
Subject: epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Date: Sat, 24 Sep 2011 23:23:20 +0200
[Message part 1 (text/plain, inline)]
Package: epiphany-browser
Version: 3.0.4-1
Severity: important

Epiphany is barely usable on ia64 platform (crashes *VERY* frequently).

Steps to reproduce:
- start up Epiphany; default page is http://www.debian.org
- go to http://www.google.fr and search for Debian
- click on the second Google hit (links to www.debian.org); the Debian
homepage is displayed, as expected
- click on the Epiphany Back button; you're back to the Google results
page, as expected
- click again on the link to www.debian.org in the Google results
page; Epiphany received signal SIGSEGV in (missing?) WriteBarrier.h
(see attached gdb.txt for details).

I don't know if the missing WriteBarrier.h is expected. I have
libwebkitgtk-3.0-0-dbg and libwebkitgtk-1.0-0-dbg 1.4.2-2 packages
installed on my system.

If it can help further, the following messages are recorded on the
console if I reproduce the above steps, starting Epiphany from a
terminal (not running it from gdb):
** Message: console message: undefined @0: 1.445053577918228e-154

** Message: console message: undefined @0: 1.4450535779182651e-154

** Message: console message: undefined @0: 1.445053577918293e-154

** Message: console message: undefined @0: 1.4450535779183208e-154

** Message: console message: undefined @0: 1.4450535779183486e-154

** Message: console message: undefined @0: 1.4450535779183857e-154

** Message: console message: undefined @0: 1.4450535779184135e-154

** Message: console message: undefined @0: 1.4450535779184413e-154

** Message: console message: undefined @0: 1.4450535779186732e-154

** Message: console message: undefined @0: 1.445053577918701e-154

** Message: console message: undefined @0: 1.4450535779187567e-154

** Message: console message: undefined @0: 1.4450535779187845e-154

** Message: console message: undefined @0: 1.4450535779188308e-154

** Message: console message: undefined @0: 1.4450535779188587e-154

** Message: console message: undefined @0: 1.4450535779188958e-154

** Message: console message: undefined @0: 1.4450535779189236e-154

** Message: console message: undefined @0: 1.4450535779189514e-154

** Message: console message: undefined @0: 1.4450535779189792e-154

** Message: console message: undefined @0: 1.445053577919007e-154

** Message: console message: undefined @0: 1.4450535779190349e-154

** Message: console message: undefined @0: 1.4450535779190627e-154

Segmentation fault.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: ia64

Kernel: Linux 2.6.38-2-mckinley (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages epiphany-browser depends on:
ii  dbus-x11                   1.4.14-1
ii  epiphany-browser-data      3.0.4-1
ii  gnome-icon-theme           3.0.0-4
ii  gsettings-desktop-schemas  3.0.1-1
ii  iso-codes                  3.28-1
ii  libavahi-client3           0.6.30-5
ii  libavahi-common3           0.6.30-5
ii  libavahi-gobject0          0.6.30-5
ii  libc6.1                    2.13-21
ii  libcairo2                  1.10.2-6.1
ii  libdbus-1-3                1.4.14-1
ii  libdbus-glib-1-2           0.94-4
ii  libgdk-pixbuf2.0-0         2.24.0-1
ii  libgirepository-1.0-1      0.10.8-2
ii  libglib2.0-0               2.28.6-1
ii  libgnome-keyring0          3.0.0-2
ii  libgtk-3-0                 3.0.12-2
ii  libice6                    2:1.0.7-2
ii  libnspr4-0d                4.8.9-1
ii  libnss3-1d                 3.12.11-3
ii  libpango1.0-0              1.28.4-3
ii  libsm6                     2:1.2.0-2
ii  libsoup-gnome2.4-1         2.34.3-1
ii  libsoup2.4-1               2.34.3-1
ii  libunwind7                 0.99-0.3
ii  libwebkitgtk-3.0-0         1.4.2-2
ii  libx11-6                   2:1.4.4-1
ii  libxml2                    2.7.8.dfsg-4
ii  libxslt1.1                 1.1.26-8

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20110502+nmu1
ii  evince           2.32.0-1
ii  yelp             2.30.1+webkit-1+b1

Versions of packages epiphany-browser suggests:
pn  epiphany-extensions  <none>

-- no debconf information
[gdb.txt (text/plain, attachment)]

Bug reassigned from package 'epiphany-browser' to 'libwebkitgtk-3.0-0'. Request was from Josselin Mouette <joss@debian.org> to control@bugs.debian.org. (Sun, 25 Sep 2011 08:54:37 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions 3.0.4-1. Request was from Josselin Mouette <joss@debian.org> to control@bugs.debian.org. (Sun, 25 Sep 2011 08:54:39 GMT) Full text and rfc822 format available.

Bug Marked as found in versions 1.4.2-2. Request was from Josselin Mouette <joss@debian.org> to control@bugs.debian.org. (Sun, 25 Sep 2011 08:54:39 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Tue, 17 Jan 2012 00:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Gilbert <michael.s.gilbert@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Tue, 17 Jan 2012 00:51:04 GMT) Full text and rfc822 format available.

Message #16 received at 642750@bugs.debian.org (full text, mbox):

From: Michael Gilbert <michael.s.gilbert@gmail.com>
To: 642750-submitter@bugs.debian.org, 642750@bugs.debian.org, control <control@bugs.debian.org>, Thijs Kinkhorst <thijs@debian.org>
Subject: re: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platfor
Date: Mon, 16 Jan 2012 19:46:13 -0500
tag 642750 moreinfo
thanks

Hi, can you try webkit 1.6.1 or newer?  I don't have an itanium to be
able to test this.




Added tag(s) moreinfo. Request was from Michael Gilbert <michael.s.gilbert@gmail.com> to control@bugs.debian.org. (Tue, 17 Jan 2012 00:51:07 GMT) Full text and rfc822 format available.

Message sent on to Émeric Maschino <emeric.maschino@gmail.com>:
Bug#642750. (Tue, 17 Jan 2012 00:51:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Tue, 17 Jan 2012 20:27:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Émeric Maschino <emeric.maschino@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Tue, 17 Jan 2012 20:27:13 GMT) Full text and rfc822 format available.

Message #26 received at 642750@bugs.debian.org (full text, mbox):

From: Émeric Maschino <emeric.maschino@gmail.com>
To: Michael Gilbert <michael.s.gilbert@gmail.com>
Cc: 642750@bugs.debian.org, Thijs Kinkhorst <thijs@debian.org>
Subject: Re: Bug#642750: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platfor
Date: Tue, 17 Jan 2012 21:26:43 +0100
[Message part 1 (text/plain, inline)]
Hi,

Unfortunately, still the same issue. Please have a look at the attached gdb.txt.

This is with epiphany 3.2.1-2 and webkit 1.6.1-5+b1 currently in Debian Testing.

Hope this helps and let me know if you need more information.

     Émeric


Le 17 janvier 2012 01:46, Michael Gilbert
<michael.s.gilbert@gmail.com> a écrit :
> tag 642750 moreinfo
> thanks
>
> Hi, can you try webkit 1.6.1 or newer?  I don't have an itanium to be
> able to test this.
>
>
[gdb.txt (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Thu, 25 Oct 2012 21:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Émeric Maschino <emeric.maschino@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Thu, 25 Oct 2012 21:21:03 GMT) Full text and rfc822 format available.

Message #31 received at 642750@bugs.debian.org (full text, mbox):

From: Émeric Maschino <emeric.maschino@gmail.com>
To: Michael Gilbert <michael.s.gilbert@gmail.com>, 642750@bugs.debian.org, control@bugs.debian.org, Thijs Kinkhorst <thijs@debian.org>
Subject: Epiphany still unstable [ia64]: SIGSEGV in WebCore::toJSDOMWindow(WebCore::Frame*, WebCore::DOMWrapperWorld*)
Date: Thu, 25 Oct 2012 23:19:28 +0200
[Message part 1 (text/plain, inline)]
tags 642750 - moreinfo
thanks

Hi,

Please find attached an updated gdb stacktrace for libwebkitgtk-3.0.0
1.8.1-3.3 and epiphany-browser 3.4.2-2 currently in Debian "Wheezy"
Testing when following steps described in Message #5
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#5).

Stacktrace is different than with WebKit 1.4/1.6 (but root cause is
perhaps still the same).

Hope this helps and let me now if you need additional information.

Best regards,

     Emeric
[gdb.txt (text/plain, attachment)]

Removed tag(s) moreinfo. Request was from Émeric Maschino <emeric.maschino@gmail.com> to control@bugs.debian.org. (Thu, 25 Oct 2012 21:21:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Sun, 02 Dec 2012 19:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Sun, 02 Dec 2012 19:30:03 GMT) Full text and rfc822 format available.

Message #38 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: emeric.maschino@gmail.com
Cc: 642750@bugs.debian.org
Subject: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Date: Sun, 02 Dec 2012 20:28:00 +0100
[Message part 1 (text/plain, inline)]
severity 642750 grave
tags 642750 + patch
block 582774 by 642750
thanks



While working on this bug I realized that webkit has yet another bug  
that prevents it from working on ia64. I filed the separate bug#694971  
for that.

I built the libwebkitgtk-3.0-0 package which was configured with  
--enable-debug. (Wasn't possible with the initial 4GB of memory at  
all. After a memory upgrade to 16GB it took eleven-and-a-half hour on  
my box with the -j2 option.)

Just starting epiphany-browser showed a first hint what is going on:
ASSERTION FAILED: isCell()
../Source/JavaScriptCore/runtime/JSValueInlineMethods.h(491) :  
JSC::JSCell* JSC::JSValue::asCell() const

Webkit uses a variant data type JSValue, which it uses for anything  
that can be a thing on Java script. It can contain an integer number,  
a float number or a pointer to an object - this is 'cell'.

It turned out that the 'isCell()' assertion failed for a JSValue that  
just has been initialized as a pointer.

The arch determines how the JSValue is defined; there are two options  
(yet), one for any 32-bits arch, the other one for 64-bits archs.

You can see this in Source/JavaScriptCore/runtime/JSValue.h - JSValue  
defines an embedded data type 'EncodedValueDescriptor' for that:

#if USE(JSVALUE32_64)
    typedef int64_t EncodedJSValue;
#else
    typedef void* EncodedJSValue;
#endif

    union EncodedValueDescriptor {
        int64_t asInt64;
#if USE(JSVALUE32_64)
        double asDouble;
#elif USE(JSVALUE64)
        JSCell* ptr;
#endif

#if CPU(BIG_ENDIAN)
        struct {
            int32_t tag;
            int32_t payload;
        } asBits;
#else
        struct {
            int32_t payload;
            int32_t tag;
        } asBits;
#endif
    };

....

#if USE(JSVALUE32_64)
        /*
         * On 32-bit platforms USE(JSVALUE32_64) should be defined,  
and we use a NaN-encoded
         * form for immediates.
         *
         * The encoding makes use of unused NaN space in the IEEE754  
representation.  Any value
         * with the top 13 bits set represents a QNaN (with the sign  
bit set).  QNaN values
         * can encode a 51-bit payload.  Hardware produced and  
C-library payloads typically
         * have a payload of zero.  We assume that non-zero payloads  
are available to encode
         * pointer and integer values.  Since any 64-bit bit pattern  
where the top 15 bits are
         * all set represents a NaN with a non-zero payload, we can  
use this space in the NaN
         * ranges to encode other values (however there are also  
other ranges of NaN space that
         * could have been selected).
         *
         * For JSValues that do not contain a double value, the high  
32 bits contain the tag
         * values listed in the enums below, which all correspond to  
NaN-space. In the case of
         * cell, integer and bool values the lower 32 bits (the  
'payload') contain the pointer
         * integer or boolean value; in the case of all other tags  
the payload is 0.
         */
        enum { Int32Tag =        0xffffffff };
        enum { BooleanTag =      0xfffffffe };
        enum { NullTag =         0xfffffffd };
        enum { UndefinedTag =    0xfffffffc };
        enum { CellTag =         0xfffffffb };
        enum { EmptyValueTag =   0xfffffffa };
        enum { DeletedValueTag = 0xfffffff9 };

        enum { LowestTag =  DeletedValueTag };

        uint32_t tag() const;
        int32_t payload() const;
#elif USE(JSVALUE64)
        /*
         * On 64-bit platforms USE(JSVALUE64) should be defined, and  
we use a NaN-encoded
         * form for immediates.
         *
         * The encoding makes use of unused NaN space in the IEEE754  
representation.  Any value
         * with the top 13 bits set represents a QNaN (with the sign  
bit set).  QNaN values
         * can encode a 51-bit payload.  Hardware produced and  
C-library payloads typically
         * have a payload of zero.  We assume that non-zero payloads  
are available to encode
         * pointer and integer values.  Since any 64-bit bit pattern  
where the top 15 bits are
         * all set represents a NaN with a non-zero payload, we can  
use this space in the NaN
         * ranges to encode other values (however there are also  
other ranges of NaN space that
         * could have been selected).
         *
         * This range of NaN space is represented by 64-bit numbers  
begining with the 16-bit
         * hex patterns 0xFFFE and 0xFFFF - we rely on the fact that  
no valid double-precision
         * numbers will begin fall in these ranges.
         *
         * The top 16-bits denote the type of the encoded JSValue:
         *
         *     Pointer {  0000:PPPP:PPPP:PPPP
         *              / 0001:****:****:****
         *     Double  {         ...
         *              \ FFFE:****:****:****
         *     Integer {  FFFF:0000:IIII:IIII
         *
         * The scheme we have implemented encodes double precision  
values by performing a
         * 64-bit integer addition of the value 2^48 to the number.  
After this manipulation
         * no encoded double-precision value will begin with the  
pattern 0x0000 or 0xFFFF.
         * Values must be decoded by reversing this operation before  
subsequent floating point
         * operations my be peformed.
         *
         * 32-bit signed integers are marked with the 16-bit tag 0xFFFF.
         *
         * The tag 0x0000 denotes a pointer, or another form of  
tagged immediate. Boolean,
         * null and undefined values are represented by specific,  
invalid pointer values:
         *
         *     False:     0x06
         *     True:      0x07
         *     Undefined: 0x0a
         *     Null:      0x02
         *
         * These values have the following properties:
         * - Bit 1 (TagBitTypeOther) is set for all four values,  
allowing real pointers to be
         *   quickly distinguished from all immediate values,  
including these invalid pointers.
         * - With bit 3 is masked out (TagBitUndefined) Undefined and  
Null share the
         *   same value, allowing null & undefined to be quickly detected.
         *
         * No valid JSValue will have the bit pattern 0x0, this is  
used to represent array
         * holes, and as a C++ 'no value' result (e.g. JSValue() has  
an internal value of 0).
         */

        // These values are #defines since using static const  
integers here is a ~1% regression!

        // This value is 2^48, used to encode doubles such that the  
encoded value will begin
        // with a 16-bit pattern within the range 0x0001..0xFFFE.
        #define DoubleEncodeOffset 0x1000000000000ll
        // If all bits in the mask are set, this indicates an integer number,
        // if any but not all are set this value is a double precision number.
        #define TagTypeNumber 0xffff000000000000ll

        // All non-numeric (bool, null, undefined) immediates have bit 2 set.
        #define TagBitTypeOther 0x2ll
        #define TagBitBool      0x4ll
        #define TagBitUndefined 0x8ll
        // Combined integer value for non-numeric immediates.
        #define ValueFalse     (TagBitTypeOther | TagBitBool | false)
        #define ValueTrue      (TagBitTypeOther | TagBitBool | true)
        #define ValueUndefined (TagBitTypeOther | TagBitUndefined)
        #define ValueNull      (TagBitTypeOther)

        // TagMask is used to check for all types of immediate values  
(either number or 'other').
        #define TagMask (TagTypeNumber | TagBitTypeOther)

        // These special values are never visible to JavaScript code;  
Empty is used to represent
        // Array holes, and for uninitialized JSValues. Deleted is  
used in hash table code.
        // These values would map to cell types in the JSValue  
encoding, but not valid GC cell
        // pointer should have either of these values (Empty is null,  
deleted is at an invalid
        // alignment for a GC cell, and in the zero page).
        #define ValueEmpty   0x0ll
        #define ValueDeleted 0x4ll
#endif






USE(JSVALUE64) is true on ia64; USE(JSVALUE32_64) is false.

The code on a true USE(JSVALUE64) uses some sophisticated tricks in  
order to get everything in a 64-bits wide data type.
If you read the comment of the webkit source, you realize that this  
works as long the high 16-bits of the addresses of any allocated  
memory are cleared.
But when you look at the crash dumps above, you see a lot of addresses  
which have some upper bits set.
This is the reason why decoding of the variant data type fails - the  
mentioned failed assertion.

(If you think you have a Déjà vu, it is because the Mozilla Java  
script engine uses a similar trick on 64-bit archs, and has a similar  
problem on ia64, for example, see the archived bug#659186.)



The proposed patch defines a third option
USE(JSVALUE64W)
which we use *only* on ia64.
It uses an encapsulated union without any trick for the variant data  
type. This is portable but
- the data type is 128-bits wide,
- Enabling JIT compiler isn't possible - that's not that bad; ia64  
doesn't have a JIT compiler.

The patch is for the most recent libwebkitgtk-3.0-0 package of Wheezy.
The patch doesn'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 is 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.tar


The patches also fix bug#582774 (seed FTBFS on ia64).

Stephan



[ia64-wide-ptr.patch (application/octet-stream, attachment)]

Severity set to 'grave' from 'important' Request was from Stephan Schreiber <info@fs-driver.org> to control@bugs.debian.org. (Sun, 02 Dec 2012 19:30:07 GMT) Full text and rfc822 format available.

Added tag(s) patch. Request was from Stephan Schreiber <info@fs-driver.org> to control@bugs.debian.org. (Sun, 02 Dec 2012 19:30:07 GMT) Full text and rfc822 format available.

Added indication that bug 642750 blocks 582774 Request was from Stephan Schreiber <info@fs-driver.org> to control@bugs.debian.org. (Sun, 02 Dec 2012 19:30:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Sun, 02 Dec 2012 21:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to peter green <plugwash@p10link.net>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Sun, 02 Dec 2012 21:27:03 GMT) Full text and rfc822 format available.

Message #49 received at 642750@bugs.debian.org (full text, mbox):

From: peter green <plugwash@p10link.net>
To: info@fs-driver.org
Cc: 642750@bugs.debian.org
Subject: re: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Date: Sun, 02 Dec 2012 21:22:38 +0000
>
> The proposed patch defines a third option
> USE(JSVALUE64W)
> which we use *only* on ia64.
> It uses an encapsulated union without any trick for the variant data  
> type. This is portable but
> - the data type is 128-bits wide,
> - Enabling JIT compiler isn't possible - that's not that bad; ia64  
> doesn't have a JIT compiler.
>   
Is the type in question purely internal to webkit or is it also used by 
client applications? If the latter then presumablly a soname bump and 
hence a transition would be needed.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Mon, 03 Dec 2012 21:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Émeric Maschino <emeric.maschino@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Mon, 03 Dec 2012 21:27:03 GMT) Full text and rfc822 format available.

Message #54 received at 642750@bugs.debian.org (full text, mbox):

From: Émeric Maschino <emeric.maschino@gmail.com>
To: Stephan Schreiber <info@fs-driver.org>
Cc: 642750@bugs.debian.org
Subject: Re: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Date: Mon, 3 Dec 2012 22:24:28 +0100
Thanks Stephan for your hard work.

I just tested Epiphany with the updated packages that you provided in
[1]. Are they self-contained or is yet another updated package
missing?

Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report, albeit you don't have to
click again on Debian URL to make it crash. Simply going back to the
Google results page and waiting a little bit is sufficient to trigger
the crash.

And unfortunately, trying to get an informative stacktrace in gdb, I'm
now hitting the SIGTRAP issue [2] :-(

     Émeric


[1] http://www.fs-driver.org/debian-ia64/webkitgtk-debs.tar
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576



2012/12/2 Stephan Schreiber <info@fs-driver.org>:
> severity 642750 grave
> tags 642750 + patch
> block 582774 by 642750
> thanks
>
>
>
> While working on this bug I realized that webkit has yet another bug that
> prevents it from working on ia64. I filed the separate bug#694971 for that.
>
> I built the libwebkitgtk-3.0-0 package which was configured with
> --enable-debug. (Wasn't possible with the initial 4GB of memory at all.
> After a memory upgrade to 16GB it took eleven-and-a-half hour on my box with
> the -j2 option.)
>
> Just starting epiphany-browser showed a first hint what is going on:
> ASSERTION FAILED: isCell()
> ../Source/JavaScriptCore/runtime/JSValueInlineMethods.h(491) : JSC::JSCell*
> JSC::JSValue::asCell() const
>
> Webkit uses a variant data type JSValue, which it uses for anything that can
> be a thing on Java script. It can contain an integer number, a float number
> or a pointer to an object - this is 'cell'.
>
> It turned out that the 'isCell()' assertion failed for a JSValue that just
> has been initialized as a pointer.
>
> The arch determines how the JSValue is defined; there are two options (yet),
> one for any 32-bits arch, the other one for 64-bits archs.
>
> You can see this in Source/JavaScriptCore/runtime/JSValue.h - JSValue
> defines an embedded data type 'EncodedValueDescriptor' for that:
>
> #if USE(JSVALUE32_64)
>     typedef int64_t EncodedJSValue;
> #else
>     typedef void* EncodedJSValue;
> #endif
>
>     union EncodedValueDescriptor {
>         int64_t asInt64;
> #if USE(JSVALUE32_64)
>         double asDouble;
> #elif USE(JSVALUE64)
>         JSCell* ptr;
> #endif
>
> #if CPU(BIG_ENDIAN)
>         struct {
>             int32_t tag;
>             int32_t payload;
>         } asBits;
> #else
>         struct {
>             int32_t payload;
>             int32_t tag;
>         } asBits;
> #endif
>     };
>
> ....
>
> #if USE(JSVALUE32_64)
>         /*
>          * On 32-bit platforms USE(JSVALUE32_64) should be defined, and we
> use a NaN-encoded
>          * form for immediates.
>          *
>          * The encoding makes use of unused NaN space in the IEEE754
> representation.  Any value
>          * with the top 13 bits set represents a QNaN (with the sign bit
> set).  QNaN values
>          * can encode a 51-bit payload.  Hardware produced and C-library
> payloads typically
>          * have a payload of zero.  We assume that non-zero payloads are
> available to encode
>          * pointer and integer values.  Since any 64-bit bit pattern where
> the top 15 bits are
>          * all set represents a NaN with a non-zero payload, we can use this
> space in the NaN
>          * ranges to encode other values (however there are also other
> ranges of NaN space that
>          * could have been selected).
>          *
>          * For JSValues that do not contain a double value, the high 32 bits
> contain the tag
>          * values listed in the enums below, which all correspond to
> NaN-space. In the case of
>          * cell, integer and bool values the lower 32 bits (the 'payload')
> contain the pointer
>          * integer or boolean value; in the case of all other tags the
> payload is 0.
>          */
>         enum { Int32Tag =        0xffffffff };
>         enum { BooleanTag =      0xfffffffe };
>         enum { NullTag =         0xfffffffd };
>         enum { UndefinedTag =    0xfffffffc };
>         enum { CellTag =         0xfffffffb };
>         enum { EmptyValueTag =   0xfffffffa };
>         enum { DeletedValueTag = 0xfffffff9 };
>
>         enum { LowestTag =  DeletedValueTag };
>
>         uint32_t tag() const;
>         int32_t payload() const;
> #elif USE(JSVALUE64)
>         /*
>          * On 64-bit platforms USE(JSVALUE64) should be defined, and we use
> a NaN-encoded
>          * form for immediates.
>          *
>          * The encoding makes use of unused NaN space in the IEEE754
> representation.  Any value
>          * with the top 13 bits set represents a QNaN (with the sign bit
> set).  QNaN values
>          * can encode a 51-bit payload.  Hardware produced and C-library
> payloads typically
>          * have a payload of zero.  We assume that non-zero payloads are
> available to encode
>          * pointer and integer values.  Since any 64-bit bit pattern where
> the top 15 bits are
>          * all set represents a NaN with a non-zero payload, we can use this
> space in the NaN
>          * ranges to encode other values (however there are also other
> ranges of NaN space that
>          * could have been selected).
>          *
>          * This range of NaN space is represented by 64-bit numbers begining
> with the 16-bit
>          * hex patterns 0xFFFE and 0xFFFF - we rely on the fact that no
> valid double-precision
>          * numbers will begin fall in these ranges.
>          *
>          * The top 16-bits denote the type of the encoded JSValue:
>          *
>          *     Pointer {  0000:PPPP:PPPP:PPPP
>          *              / 0001:****:****:****
>          *     Double  {         ...
>          *              \ FFFE:****:****:****
>          *     Integer {  FFFF:0000:IIII:IIII
>          *
>          * The scheme we have implemented encodes double precision values by
> performing a
>          * 64-bit integer addition of the value 2^48 to the number. After
> this manipulation
>          * no encoded double-precision value will begin with the pattern
> 0x0000 or 0xFFFF.
>          * Values must be decoded by reversing this operation before
> subsequent floating point
>          * operations my be peformed.
>          *
>          * 32-bit signed integers are marked with the 16-bit tag 0xFFFF.
>          *
>          * The tag 0x0000 denotes a pointer, or another form of tagged
> immediate. Boolean,
>          * null and undefined values are represented by specific, invalid
> pointer values:
>          *
>          *     False:     0x06
>          *     True:      0x07
>          *     Undefined: 0x0a
>          *     Null:      0x02
>          *
>          * These values have the following properties:
>          * - Bit 1 (TagBitTypeOther) is set for all four values, allowing
> real pointers to be
>          *   quickly distinguished from all immediate values, including
> these invalid pointers.
>          * - With bit 3 is masked out (TagBitUndefined) Undefined and Null
> share the
>          *   same value, allowing null & undefined to be quickly detected.
>          *
>          * No valid JSValue will have the bit pattern 0x0, this is used to
> represent array
>          * holes, and as a C++ 'no value' result (e.g. JSValue() has an
> internal value of 0).
>          */
>
>         // These values are #defines since using static const integers here
> is a ~1% regression!
>
>         // This value is 2^48, used to encode doubles such that the encoded
> value will begin
>         // with a 16-bit pattern within the range 0x0001..0xFFFE.
>         #define DoubleEncodeOffset 0x1000000000000ll
>         // If all bits in the mask are set, this indicates an integer
> number,
>         // if any but not all are set this value is a double precision
> number.
>         #define TagTypeNumber 0xffff000000000000ll
>
>         // All non-numeric (bool, null, undefined) immediates have bit 2
> set.
>         #define TagBitTypeOther 0x2ll
>         #define TagBitBool      0x4ll
>         #define TagBitUndefined 0x8ll
>         // Combined integer value for non-numeric immediates.
>         #define ValueFalse     (TagBitTypeOther | TagBitBool | false)
>         #define ValueTrue      (TagBitTypeOther | TagBitBool | true)
>         #define ValueUndefined (TagBitTypeOther | TagBitUndefined)
>         #define ValueNull      (TagBitTypeOther)
>
>         // TagMask is used to check for all types of immediate values
> (either number or 'other').
>         #define TagMask (TagTypeNumber | TagBitTypeOther)
>
>         // These special values are never visible to JavaScript code; Empty
> is used to represent
>         // Array holes, and for uninitialized JSValues. Deleted is used in
> hash table code.
>         // These values would map to cell types in the JSValue encoding, but
> not valid GC cell
>         // pointer should have either of these values (Empty is null,
> deleted is at an invalid
>         // alignment for a GC cell, and in the zero page).
>         #define ValueEmpty   0x0ll
>         #define ValueDeleted 0x4ll
> #endif
>
>
>
>
>
>
> USE(JSVALUE64) is true on ia64; USE(JSVALUE32_64) is false.
>
> The code on a true USE(JSVALUE64) uses some sophisticated tricks in order to
> get everything in a 64-bits wide data type.
> If you read the comment of the webkit source, you realize that this works as
> long the high 16-bits of the addresses of any allocated memory are cleared.
> But when you look at the crash dumps above, you see a lot of addresses which
> have some upper bits set.
> This is the reason why decoding of the variant data type fails - the
> mentioned failed assertion.
>
> (If you think you have a Déją vu, it is because the Mozilla Java script
> engine uses a similar trick on 64-bit archs, and has a similar problem on
> ia64, for example, see the archived bug#659186.)
>
>
>
> The proposed patch defines a third option
> USE(JSVALUE64W)
> which we use *only* on ia64.
> It uses an encapsulated union without any trick for the variant data type.
> This is portable but
> - the data type is 128-bits wide,
> - Enabling JIT compiler isn't possible - that's not that bad; ia64 doesn't
> have a JIT compiler.
>
> The patch is for the most recent libwebkitgtk-3.0-0 package of Wheezy.
> The patch doesn'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 is 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.tar
>
>
> The patches also fix bug#582774 (seed FTBFS on ia64).
>
> Stephan
>
>
>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Tue, 04 Dec 2012 20:57:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Tue, 04 Dec 2012 20:57:08 GMT) Full text and rfc822 format available.

Message #59 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: Émeric Maschino <emeric.maschino@gmail.com>
Cc: 642750@bugs.debian.org
Subject: Re: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Date: Tue, 04 Dec 2012 21:53:59 +0100
Émeric Maschino wrote:

> Indeed, even with your updated packages, Epiphany still crashes with
> the scenario I described in this bug report

Hmm, the webkit thing seems to have at least yet another bug :-(. The  
bug doesn't occur on my most recent debug build of libwebkitgtk-3.0-0.
But I could reproduce the crash several times today with the release  
build. The crash was on different code locations and with completely  
different stack traces.
Further research is needed here...


> And unfortunately, trying to get an informative stacktrace in gdb, I'm
> now hitting the SIGTRAP issue [2] :-(

I don't believe that we would have much benefit of any stack trace on  
this bug.
I'm still using the Kernel 3.2.23 with the futex patch [2] compiled  
with GCC4.4. Yet another ia64 problem.

Stephan





Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Tue, 04 Dec 2012 20:57:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Tue, 04 Dec 2012 20:57:10 GMT) Full text and rfc822 format available.

Message #64 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: peter green <plugwash@p10link.net>
Cc: 642750@bugs.debian.org
Subject: Re: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Date: Tue, 04 Dec 2012 21:55:30 +0100
Peter Green wrote:

> >
> > The proposed patch defines a third option
> > USE(JSVALUE64W)
> > which we use *only* on ia64.
> > It uses an encapsulated union without any trick for the variant  
> data  > type. This is portable but
> > - the data type is 128-bits wide,
> > - Enabling JIT compiler isn't possible - that's not that bad; ia64  
>  > doesn't have a JIT compiler.
> >   Is the type in question purely internal to webkit or is it also  
> used by client applications? If the latter then presumablly a soname  
> bump and hence a transition would be needed.


The type is internal. Exported are only opaque pointer types.
Because I wasn't really sure, I diff'd the contents of
 libjavascriptcoregtk-3.0-dev_1.8.1-3.3_ia64.deb and
 libwebkitgtk-3.0-dev_1.8.1-3.3_ia64.deb
which were created with and without the patches.

Different were only some mysteric id in included html documentation  
files and the Debian/md5sums file.
All included .h files were identical.
The patches do not change the binary interface.

Stephan





Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Fri, 07 Dec 2012 21:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Fri, 07 Dec 2012 21:03:03 GMT) Full text and rfc822 format available.

Message #69 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: Émeric Maschino <emeric.maschino@gmail.com>
Cc: peter green <plugwash@p10link.net>, 642750@bugs.debian.org
Subject: Re: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Date: Fri, 07 Dec 2012 21:58:57 +0100
[Message part 1 (text/plain, inline)]
É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

[01-ia64-wide-ptr.patch (application/octet-stream, attachment)]
[02-ia64-use-system-malloc.patch (application/octet-stream, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Mon, 10 Dec 2012 10:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gustavo Noronha Silva <kov@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Mon, 10 Dec 2012 10:33:03 GMT) Full text and rfc822 format available.

Message #74 received at 642750@bugs.debian.org (full text, mbox):

From: Gustavo Noronha Silva <kov@debian.org>
To: Stephan Schreiber <info@fs-driver.org>, 642750@bugs.debian.org
Cc: Émeric Maschino <emeric.maschino@gmail.com>, peter green <plugwash@p10link.net>
Subject: Re: Bug#642750: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Date: Mon, 10 Dec 2012 10:58:00 +0100
Hey,

On Sex, 2012-12-07 at 21:58 +0100, Stephan Schreiber wrote:
> 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.

Thanks for the patches! I will include them in my next upload, do you
mind proposing them upstream, though? I don't feel like I know enough of
this bit of the code to propose them myself.

See http://www.webkit.org/coding/contributing.html

Cheers,

-- 
Gustavo Noronha Silva <kov@debian.org>
Debian




Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Sat, 15 Dec 2012 16:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Émeric Maschino <emeric.maschino@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Sat, 15 Dec 2012 16:45:03 GMT) Full text and rfc822 format available.

Message #79 received at 642750@bugs.debian.org (full text, mbox):

From: Émeric Maschino <emeric.maschino@gmail.com>
To: Stephan Schreiber <info@fs-driver.org>
Cc: 642750@bugs.debian.org
Subject: Re: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Date: Sat, 15 Dec 2012 17:42:11 +0100
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@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
>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Sat, 22 Dec 2012 10:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Sat, 22 Dec 2012 10:45:03 GMT) Full text and rfc822 format available.

Message #84 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: Gustavo Noronha Silva <kov@debian.org>
Cc: 642750@bugs.debian.org
Subject: Re: Bug#642750: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Date: Sat, 22 Dec 2012 11:43:00 +0100
Gustavo Noronha Silva wrote:

> Thanks for the patches! I will include them in my next upload, do you
> mind proposing them upstream, though? I don't feel like I know enough of
> this bit of the code to propose them myself.

Yes, I do - any assistance of you is appreciated.
I think, webkit 1.8.1 is an outdated version for the upstream; I would  
make more sense to make another patch for the most recent webkit 1.11.
Since there are some other difficult ia64 RC bugs to do and the  
porters are understaffed, I attempt to do it after the release of  
Wheezy.

Btw: It seems that fixing of epiphany/webkit isn't completed because  
it doesn't work satisfactory yet.

Regards
Stephan





Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Sat, 22 Dec 2012 10:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Sat, 22 Dec 2012 10:48:03 GMT) Full text and rfc822 format available.

Message #89 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: Émeric Maschino <emeric.maschino@gmail.com>
Cc: 642750@bugs.debian.org
Subject: Re: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Date: Sat, 22 Dec 2012 11:45:31 +0100
Émeric Maschino wrote:

> 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.

I couldn't reproduce the crash on the Google homepage.
But you are right: I experience it, too; Epiphany still crashes *sometimes*.

Obviously Epiphany/Webkit still has at least one more bug...



> Let me know if additional tests are welcomed.

I think further tests at the level of a user wouldn't have any benefit  
at the moment.
(Please could you test the patches for Iceweasel 10.0.11esr at next?)

Stephan





Added indication that bug 642750 blocks 697174 Request was from Paul Wise <pabs@debian.org> to control@bugs.debian.org. (Wed, 02 Jan 2013 07:45:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Wed, 02 Jan 2013 07:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Wed, 02 Jan 2013 07:51:03 GMT) Full text and rfc822 format available.

Message #96 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: emeric.maschino@gmail.com
Cc: 642750@bugs.debian.org
Subject: epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Date: Wed, 02 Jan 2013 08:48:02 +0100
I filed bug#697172 for yet another bug of webkit.
Furthermore, bug#697173 for a bug in the epiphany-browser package.
Furthermore, bug#697174 in order to enable seed on ia64.

I also realized that gnash seems to crash epiphany sometimes. I  
browsed through the Debian bug reports and found ones which blame  
gnash to make the webkit based browsers unstable - epiphany-bowser on  
Gnome and Konqueror on KDE:
bug#594822, 655839, 549309.
I removed both gnash and gnash-common from my computer and realized a  
real improvement of epiphany's behaviour.

But I still experienced some trouble, for example, a reproducable  
hang-up and a crash a few seconds subsequently: Enter www.kununu.de;  
enter a company name in the top right search edit box; enter; click on  
a company's name - hang-up, crash.
I tried Fedora 17 i386 on another box (epiphany-browser 3.4.3; webkit  
1.8.3; gnash isn't installed): same behaviour. It isn't an ia64  
specific bug.

I think epiphany-browser/webkit with all patches runs on ia64 as  
stable as on x86; this is the best we can do at the moment.


A summary of the patches we had so far:

webkit, this bug report
01-ia64-wide-ptr.patch
02-ia64-use-system-malloc.patch

webkit, bug#694971
large-mem-page.patch

webkit, bug#697172
thread-safe-icon-db.patch

seed, bug#582774
seed no longer FTBFS without any change

epiphany-browser, bug#697173
history-thread-startup-race.patch

epiphany-browser, bug#697174
enabling seed in debian/rules


If you want to test it, you can download the built debs:

http://www.fs-driver.org/debian-ia64/webkitgtk-debs-v3.tar
http://www.fs-driver.org/debian-ia64/seed-debs.tar
http://www.fs-driver.org/debian-ia64/epiphany-debs.tar

Remember to remove both gnash and gnash-common before you test it.

Stephan





Removed indication that bug 642750 blocks 697174 Request was from Stephan Schreiber <info@fs-driver.org> to control@bugs.debian.org. (Wed, 02 Jan 2013 17:18:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package libwebkitgtk-3.0-0. (Mon, 07 Jan 2013 20:39:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Émeric Maschino <emeric.maschino@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Mon, 07 Jan 2013 20:39:09 GMT) Full text and rfc822 format available.

Message #103 received at 642750@bugs.debian.org (full text, mbox):

From: Émeric Maschino <emeric.maschino@gmail.com>
To: Stephan Schreiber <info@fs-driver.org>
Cc: 642750@bugs.debian.org
Subject: Re: epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Date: Mon, 7 Jan 2013 21:34:56 +0100
Hi and happy new year,

I've tested latest patchset from Stephan.

Epiphany runs as great as with the v2 patchset.
I'm however still getting the curious Google homepage crash I was
talking about previously.
Uninstalling gnash didn't help.
But overall, Stephan work is a _huge_ improvement w.r.t. what we had before!
Kudos to him.

Best regards,

    Emeric


2013/1/2 Stephan Schreiber <info@fs-driver.org>:
> I filed bug#697172 for yet another bug of webkit.
> Furthermore, bug#697173 for a bug in the epiphany-browser package.
> Furthermore, bug#697174 in order to enable seed on ia64.
>
> I also realized that gnash seems to crash epiphany sometimes. I browsed
> through the Debian bug reports and found ones which blame gnash to make the
> webkit based browsers unstable - epiphany-bowser on Gnome and Konqueror on
> KDE:
> bug#594822, 655839, 549309.
> I removed both gnash and gnash-common from my computer and realized a real
> improvement of epiphany's behaviour.
>
> But I still experienced some trouble, for example, a reproducable hang-up
> and a crash a few seconds subsequently: Enter www.kununu.de; enter a company
> name in the top right search edit box; enter; click on a company's name -
> hang-up, crash.
> I tried Fedora 17 i386 on another box (epiphany-browser 3.4.3; webkit 1.8.3;
> gnash isn't installed): same behaviour. It isn't an ia64 specific bug.
>
> I think epiphany-browser/webkit with all patches runs on ia64 as stable as
> on x86; this is the best we can do at the moment.
>
>
> A summary of the patches we had so far:
>
> webkit, this bug report
> 01-ia64-wide-ptr.patch
> 02-ia64-use-system-malloc.patch
>
> webkit, bug#694971
> large-mem-page.patch
>
> webkit, bug#697172
> thread-safe-icon-db.patch
>
> seed, bug#582774
> seed no longer FTBFS without any change
>
> epiphany-browser, bug#697173
> history-thread-startup-race.patch
>
> epiphany-browser, bug#697174
> enabling seed in debian/rules
>
>
> If you want to test it, you can download the built debs:
>
> http://www.fs-driver.org/debian-ia64/webkitgtk-debs-v3.tar
> http://www.fs-driver.org/debian-ia64/seed-debs.tar
> http://www.fs-driver.org/debian-ia64/epiphany-debs.tar
>
> Remember to remove both gnash and gnash-common before you test it.
>
> Stephan
>
>



Bug reassigned from package 'libwebkitgtk-3.0-0' to 'src:webkit'. Request was from Michael Gilbert <mgilbert@debian.org> to control@bugs.debian.org. (Sun, 10 Feb 2013 19:15:04 GMT) Full text and rfc822 format available.

No longer marked as found in versions 1.4.2-2. Request was from Michael Gilbert <mgilbert@debian.org> to control@bugs.debian.org. (Sun, 10 Feb 2013 19:15:04 GMT) Full text and rfc822 format available.

Marked as found in versions webkit/1.8.1-3.3. Request was from Michael Gilbert <mgilbert@debian.org> to control@bugs.debian.org. (Sun, 10 Feb 2013 19:15:11 GMT) Full text and rfc822 format available.

Reply sent to Michael Gilbert <mgilbert@debian.org>:
You have taken responsibility. (Tue, 19 Feb 2013 07:21:03 GMT) Full text and rfc822 format available.

Notification sent to Émeric Maschino <emeric.maschino@gmail.com>:
Bug acknowledged by developer. (Tue, 19 Feb 2013 07:21:03 GMT) Full text and rfc822 format available.

Message #114 received at 642750-close@bugs.debian.org (full text, mbox):

From: Michael Gilbert <mgilbert@debian.org>
To: 642750-close@bugs.debian.org
Subject: Bug#642750: fixed in webkit 1.8.1-3.4
Date: Tue, 19 Feb 2013 07:18:33 +0000
Source: webkit
Source-Version: 1.8.1-3.4

We believe that the bug you reported is fixed in the latest version of
webkit, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 642750@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Gilbert <mgilbert@debian.org> (supplier of updated webkit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sat, 16 Feb 2013 21:46:48 +0000
Source: webkit
Binary: libjavascriptcoregtk-1.0-0 libjavascriptcoregtk-1.0-dev libjavascriptcoregtk-1.0-0-dbg gir1.2-javascriptcoregtk-1.0 libwebkitgtk-1.0-0 libwebkit-dev libwebkitgtk-dev libwebkitgtk-1.0-common libwebkitgtk-1.0-0-dbg gir1.2-webkit-1.0 libjavascriptcoregtk-3.0-0 libjavascriptcoregtk-3.0-dev libjavascriptcoregtk-3.0-0-dbg gir1.2-javascriptcoregtk-3.0 libwebkitgtk-3.0-0 libwebkitgtk-3.0-dev libwebkitgtk-3.0-common libwebkitgtk-3.0-0-dbg gir1.2-webkit-3.0
Architecture: source all amd64
Version: 1.8.1-3.4
Distribution: unstable
Urgency: medium
Maintainer: Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>
Changed-By: Michael Gilbert <mgilbert@debian.org>
Description: 
 gir1.2-javascriptcoregtk-1.0 - GObject introspection data for the GTK+-based JavaScriptCore libr
 gir1.2-javascriptcoregtk-3.0 - GObject introspection data for the GTK+-based JavaScriptCore libr
 gir1.2-webkit-1.0 - GObject introspection data for the WebKit library
 gir1.2-webkit-3.0 - GObject introspection data for the WebKit library
 libjavascriptcoregtk-1.0-0 - Javascript engine library for GTK+
 libjavascriptcoregtk-1.0-0-dbg - Javascript engine library for GTK+
 libjavascriptcoregtk-1.0-dev - Javascript engine library for GTK+
 libjavascriptcoregtk-3.0-0 - Javascript engine library for GTK+
 libjavascriptcoregtk-3.0-0-dbg - Javascript engine library for GTK+
 libjavascriptcoregtk-3.0-dev - Javascript engine library for GTK+
 libwebkit-dev - Transitional package for the development files of WebKitGTK+
 libwebkitgtk-1.0-0 - Web content engine library for GTK+
 libwebkitgtk-1.0-0-dbg - Web content engine library for GTK+ - Debugging symbols
 libwebkitgtk-1.0-common - Web content engine library for GTK+ - data files
 libwebkitgtk-3.0-0 - Web content engine library for GTK+
 libwebkitgtk-3.0-0-dbg - Web content engine library for GTK+ - Debugging symbols
 libwebkitgtk-3.0-common - Web content engine library for GTK+ - data files
 libwebkitgtk-3.0-dev - Web content engine library for GTK+ - Development files
 libwebkitgtk-dev - Web content engine library for GTK+ - Development files
Closes: 642750 651636 694971 697172
Changes: 
 webkit (1.8.1-3.4) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix wide pointer issues on ia64 (closes: #642750).
   * Make favicon database thread-safe (closes: #697172).
   * Support architectures with large page sizes (closes: #694971).
   * Compile with --disable-jit on armel, mipsel, and powerpc (closes: #651636).
Checksums-Sha1: 
 ac9ab7f514c2ba8ce77e3a130c35355f40e965db 4434 webkit_1.8.1-3.4.dsc
 4f93124e52dc69994fcaf4e7b477f950600f2d1b 62514 webkit_1.8.1-3.4.debian.tar.gz
 d0f28fa4a304175703d55eb80474652f2e93a02a 745304 libwebkitgtk-1.0-common_1.8.1-3.4_all.deb
 44c0d4a1c4f29c4f4d3cfa75f81880a52cfe10dd 745178 libwebkitgtk-3.0-common_1.8.1-3.4_all.deb
 659ff59f54bcedcb896c5d0ba25d08259f332f41 1004960 libjavascriptcoregtk-1.0-0_1.8.1-3.4_amd64.deb
 1ecaf3171f23f76c0407f14a6aa2d35a4f0754fb 32968 libjavascriptcoregtk-1.0-dev_1.8.1-3.4_amd64.deb
 3c044c4945037f880e87ea40d5d6b101adeb3594 19323784 libjavascriptcoregtk-1.0-0-dbg_1.8.1-3.4_amd64.deb
 7ae023e8fb599e2d34befbef0f2fbab3b8c51dec 20244 gir1.2-javascriptcoregtk-1.0_1.8.1-3.4_amd64.deb
 e4ea61b50e9502cad89e6b44ce1b97b847d1dc23 4757960 libwebkitgtk-1.0-0_1.8.1-3.4_amd64.deb
 6062a45990a6ecf51673fbc9ebb6914dcead653d 19908 libwebkit-dev_1.8.1-3.4_amd64.deb
 bdaaab35acbb29ec5b47c27d9d3b939a1ffe0ac3 210838 libwebkitgtk-dev_1.8.1-3.4_amd64.deb
 3a7acd5c17e384a501f1c62f6c7ce218004ee103 247632752 libwebkitgtk-1.0-0-dbg_1.8.1-3.4_amd64.deb
 1e7618101551cfbbb42439719eec7c7c87f427af 61806 gir1.2-webkit-1.0_1.8.1-3.4_amd64.deb
 adc918d54564ee7d5e5cceb6b5ea529d2b2386c7 1005020 libjavascriptcoregtk-3.0-0_1.8.1-3.4_amd64.deb
 8554c9f744aa5f980de99a2e148fecf2648e7efc 32944 libjavascriptcoregtk-3.0-dev_1.8.1-3.4_amd64.deb
 c1be176a7a693f16edf13ae1da1d6f870af79b57 19333542 libjavascriptcoregtk-3.0-0-dbg_1.8.1-3.4_amd64.deb
 0c6c0ec27d337977c8f2e9ad2ec1a7bdde467994 20254 gir1.2-javascriptcoregtk-3.0_1.8.1-3.4_amd64.deb
 1a7b46d2a010e00b2494c07912d2e8f684a55145 4754942 libwebkitgtk-3.0-0_1.8.1-3.4_amd64.deb
 85f72f4a979758b0bd5a45884fffe37b2e97f4c9 210676 libwebkitgtk-3.0-dev_1.8.1-3.4_amd64.deb
 094d6535f1adfaee1a4dcd1924fe0f629552d718 247559620 libwebkitgtk-3.0-0-dbg_1.8.1-3.4_amd64.deb
 c890338bc3631b23c3afadb7456020051d23bd00 61854 gir1.2-webkit-3.0_1.8.1-3.4_amd64.deb
Checksums-Sha256: 
 be535c4951934c606d595cc3f7b86c36bd5d5b6442af22d2a7e63cdc417732e0 4434 webkit_1.8.1-3.4.dsc
 2cb73b8d67ed0c9e9a9aebb68d43a7812eb0cc7bea2ea30ad9fc0b78487cc349 62514 webkit_1.8.1-3.4.debian.tar.gz
 6ed7b3d221cbe2e85e6acc5f666a0f0fc4ed4efe41c2ba177dc106490c877bd5 745304 libwebkitgtk-1.0-common_1.8.1-3.4_all.deb
 26f11a57ff8fac9d29386dd15d077cd93acbbf27678629c54eb0a010e5ffa994 745178 libwebkitgtk-3.0-common_1.8.1-3.4_all.deb
 67dfa0eb208b21f7936bde310fb5089106077ab862493a8597304880c061a884 1004960 libjavascriptcoregtk-1.0-0_1.8.1-3.4_amd64.deb
 c0af8c589b2bdf53bbea4a23578a576040e9b26bf16b9d45168d86dc1dc63ca4 32968 libjavascriptcoregtk-1.0-dev_1.8.1-3.4_amd64.deb
 0e4df4f459f0f1e6e927d9a130129dc80286f3435cf5886052a884551b52d987 19323784 libjavascriptcoregtk-1.0-0-dbg_1.8.1-3.4_amd64.deb
 46c28587fbef4cb8084858fab5062516d8b74fefd14e1ce5abcc6e2726b6fa50 20244 gir1.2-javascriptcoregtk-1.0_1.8.1-3.4_amd64.deb
 a8c0edb5f2c5e074370e69f2b4338ca813496a9d14e36f32902185ffa20aeee1 4757960 libwebkitgtk-1.0-0_1.8.1-3.4_amd64.deb
 95c9ebb31e828e954380d4353f7efe0944239f947dba56d00f5c712dc1ae3a77 19908 libwebkit-dev_1.8.1-3.4_amd64.deb
 06966385450c60bdce99f1bde1705ea014ffdcb7f35e1be867a1a8dea532acc0 210838 libwebkitgtk-dev_1.8.1-3.4_amd64.deb
 645ebbab5be7b8efbe4a47514e8059bbbd02118cc280eeb9566ccaaa91a81c18 247632752 libwebkitgtk-1.0-0-dbg_1.8.1-3.4_amd64.deb
 4c2efb2987a3fa63bd3ced42e7227d1f677cdc73b1d18ad61c2bf82cfbefa670 61806 gir1.2-webkit-1.0_1.8.1-3.4_amd64.deb
 900daea70cc7235d765331fd42d4242566936465d53081a7226486b466549ecd 1005020 libjavascriptcoregtk-3.0-0_1.8.1-3.4_amd64.deb
 9f3197d65983c37d4804f867dceff538b31a4091ffddd087cda512a261a00902 32944 libjavascriptcoregtk-3.0-dev_1.8.1-3.4_amd64.deb
 d92e11f7b75eb3ed6781d8745417d7afe7dfed2e2472931a29244419214dba7f 19333542 libjavascriptcoregtk-3.0-0-dbg_1.8.1-3.4_amd64.deb
 dbbaedb0e07265fe57abf19a2c9c284fc9c88720bbe8a60a240fddccfdc789d1 20254 gir1.2-javascriptcoregtk-3.0_1.8.1-3.4_amd64.deb
 c3665bae192e137ecf2741c53e93acc92d1c98a8ae25a2281b69928ed3d98ea9 4754942 libwebkitgtk-3.0-0_1.8.1-3.4_amd64.deb
 a2050fa34ef81c4cfe4934c5e2473960bcf89759bf12ab115eb1349d58ffd22b 210676 libwebkitgtk-3.0-dev_1.8.1-3.4_amd64.deb
 830651f60f38b9a25dd46644fd62434352a08f651276761776462e44def84feb 247559620 libwebkitgtk-3.0-0-dbg_1.8.1-3.4_amd64.deb
 9bd706c51d8cff41124b0e011929b04771fe59c4ce5f1abce43372d2f5780cf9 61854 gir1.2-webkit-3.0_1.8.1-3.4_amd64.deb
Files: 
 aea486efc065781e3684a75815722ecb 4434 web optional webkit_1.8.1-3.4.dsc
 97523d4030e19b8ba200bd8ba2ab7e7a 62514 web optional webkit_1.8.1-3.4.debian.tar.gz
 674b179c636be8923813f2ade75c611e 745304 libs optional libwebkitgtk-1.0-common_1.8.1-3.4_all.deb
 1f3884b72a3544fd9b700351559e381e 745178 libs optional libwebkitgtk-3.0-common_1.8.1-3.4_all.deb
 85a4e7ecc7cc8477b802e1bbb683927a 1004960 libs optional libjavascriptcoregtk-1.0-0_1.8.1-3.4_amd64.deb
 72e34fae0a00d385d9138d84ebdf8c94 32968 libdevel extra libjavascriptcoregtk-1.0-dev_1.8.1-3.4_amd64.deb
 952aaa0cf6fbabc6d6eaac378001e56d 19323784 debug extra libjavascriptcoregtk-1.0-0-dbg_1.8.1-3.4_amd64.deb
 51d627df66baddf42c0eea6d68d5bcef 20244 introspection optional gir1.2-javascriptcoregtk-1.0_1.8.1-3.4_amd64.deb
 e19b5615aad11073f1152f50a272c616 4757960 libs optional libwebkitgtk-1.0-0_1.8.1-3.4_amd64.deb
 eeccb3987ee6450624314bb30464a093 19908 oldlibs extra libwebkit-dev_1.8.1-3.4_amd64.deb
 67a90b05da9431082a3fe68d53e26c32 210838 libdevel extra libwebkitgtk-dev_1.8.1-3.4_amd64.deb
 983f75ef85d1d1b1759aadeb5f6a7ca1 247632752 debug extra libwebkitgtk-1.0-0-dbg_1.8.1-3.4_amd64.deb
 5b2109ec5b9d6faad51c586a1fe75252 61806 introspection optional gir1.2-webkit-1.0_1.8.1-3.4_amd64.deb
 9f477d544f88fd61b114df274dc5f8f1 1005020 libs optional libjavascriptcoregtk-3.0-0_1.8.1-3.4_amd64.deb
 70f963c779981b64e57bdbb07402bfc1 32944 libdevel extra libjavascriptcoregtk-3.0-dev_1.8.1-3.4_amd64.deb
 3161c26ee8e7ff87402b5c460759d3d7 19333542 debug extra libjavascriptcoregtk-3.0-0-dbg_1.8.1-3.4_amd64.deb
 65a88c6ac77f38a8f5daddda91a190ce 20254 introspection optional gir1.2-javascriptcoregtk-3.0_1.8.1-3.4_amd64.deb
 a1f720272118e073e4b47e29cd0f5087 4754942 libs optional libwebkitgtk-3.0-0_1.8.1-3.4_amd64.deb
 f6b55528788043f2dbac9f202d9f60ee 210676 libdevel extra libwebkitgtk-3.0-dev_1.8.1-3.4_amd64.deb
 6cec8d74fd66d48778de88db26f86ca0 247559620 debug extra libwebkitgtk-3.0-0-dbg_1.8.1-3.4_amd64.deb
 ad0671e9df702f78a95bcf747c24d65c 61854 introspection optional gir1.2-webkit-3.0_1.8.1-3.4_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQQcBAEBCAAGBQJRIxGEAAoJELjWss0C1vRz/wkgAIlj5qYPrev3rkrWL10+3v5+
p/1j3hFuxAj4qX5/ew6iTLY8MtrPbhkLFpbn1mFg6IQW0P4LcBJWSQF8TPYHPH6+
CRm+XTpQV5Yo+swbvP2U1gGTudJXwjsFS0DumxbTB2L1YEaPB4qgtqtjGeT6n40v
UzJYuDXGmdZiQrEoTU4MfRAuVOGmc3msV3dqxgfPohxAJtV5to9osLcORgTUJbcL
TBzhCyxJfQoUzM6e7Q8g8tdj7NQTMrLej7rjPj07uXs+lNTBdnedNrIyhm196Zbh
q09ZD+MLnZDgtNQSC9Q8v5zdTDtnZPURDsm6HDq7ayyMP2x950Vv2fuW+h21tmN1
9uogKBPrd8C7107a0+atz318j003An3+/Jiktr4Sx9UOXXi0MK2UFger0VoTqZYv
Usw9qKvrqRXAT2jH+eUyVjgxxNLNLtGwjwUa1gA98jU4Q7GQJ/RlsiCKHoOMJZ+Q
6USrLIkXjrJ8LOiss7odBv+rO1VD6imGp+nhJcCimKjgBrL4+Fxw21kdB+Kfnu5g
LE3YlSU2nvUQIOfU75f73YzSX4UTNGeP9BN3TbytGtXbTGtRg7EnVtnJnffgRItT
Grunu4f2ECrT0yW/cZNRMD1XI6KJlu04r4yxa6FXjjARdxTEyPnkcTrz+0ZugeGt
fG5WsDY2pj50cGs3vIPUCx8VnpVZfzIyt1KQZ4KKkwqBhOecG2DtXJHao4xOcU43
aw3IPzUiADS1SkNBKSQy/rDzImrJxThwwsCFtB+DTuyVvsXhj05EOqgeJ85ESrJg
zdpSjeVqdnn3Oft0Nd2fIA0D3fi3q5CooQddC2QXvFLYu+EA0Rbis+cxUgBY7pAh
hcL9IBNd8UAY4dbdBBjioxSni0E6SsmdtRDyFzRJk/O5DbcI9XXlnF4N9uRDmcTP
enZk+uEw0C7lNAxjYAupihhf1Q05yvdePrjYJE5P6UGRSCD67k3XqTaSXUcaGotC
ZEsrbnb+BpilRLZRMIYgO+jHousqlkUoml43hCXxS9rGpz3ldgRAXs8Dv7Q+8EGK
hW5cuO/yq9ihEU2jSschCNUYeaKeMXZbwssKgUB3ZFlvXeTnil3rqz6AlveUl/NQ
PIFn4ezVx+Xa+5NGIoRDIHZoAcM5H3re1KIruutJK302H9alUFwXPLcaO40Og3U3
HyChR58jP9FRYlDwHlSU/R43i8Mu6O0WKGZriv50ONB3MTgIDfyCq6GdCyGLXwPk
BMe7fR3D09000UksvWxvuVUV6Nrj99T1DT4FJ2M0iOSNHbdxMALXzSJANLBoC7Dw
QzSvMhk6Lcp0V6rmTaj1QYcuqdkcgT5duEuhsEkGMxXG0qnOszFs01CmRpGONO0=
=oCdZ
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package src:webkit. (Sat, 09 Mar 2013 14:06:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Sat, 09 Mar 2013 14:06:06 GMT) Full text and rfc822 format available.

Message #119 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: 642750@bugs.debian.org
Subject: GDB stops with sigtrap at 0 address on ia64 wheezy
Date: Sat, 09 Mar 2013 15:02:06 +0100
notfound 642750 src:linux/3.5.5-1~experimental.1
notfixed 642750 linux-image-3.0.0-2-mckinley/3.0.0-5
notfixed 642750 linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1
fixed 642750 3.2.35-2
thanks


The problem with GDB does no longer occur with Kernel 3.2.35-2. I  
don't have a clue why.
A user has confimred that on the debian-ia64@lists.debian.org list.

I filed a new bug#702641 for the asm register contraints problem above.

Please could you simply close this bug?

Stephan





Marked as fixed in versions webkit/3.2.35-2. Request was from Stephan Schreiber <info@fs-driver.org> to control@bugs.debian.org. (Sat, 09 Mar 2013 14:06:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package src:webkit. (Sat, 09 Mar 2013 14:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephan Schreiber <info@fs-driver.org>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Sat, 09 Mar 2013 14:33:03 GMT) Full text and rfc822 format available.

Message #126 received at 642750@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: 642750@bugs.debian.org
Subject: GDB stops with sigtrap at 0 address on ia64 wheezy
Date: Sat, 09 Mar 2013 15:29:27 +0100
I'm sorry. Wrong bug number.
Please, ignore my message.

Stephan





No longer marked as fixed in versions webkit/3.2.35-2. Request was from Stephan Schreiber <info@fs-driver.org> to control@bugs.debian.org. (Sat, 09 Mar 2013 14:36:05 GMT) Full text and rfc822 format available.

Changed Bug submitter to 'Émeric Maschino <emeric.maschino@gmail.com>' from 'Émeric Maschino <emeric.maschino@gmail.com>' Request was from Don Armstrong <don@debian.org> to control@bugs.debian.org. (Thu, 21 Mar 2013 21:28:50 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 19 Apr 2013 07:28:12 GMT) Full text and rfc822 format available.

Bug unarchived. Request was from Émeric MASCHINO <emeric.maschino@gmail.com> to control@bugs.debian.org. (Sun, 25 Aug 2013 12:30:24 GMT) Full text and rfc822 format available.

Bug reopened Request was from Émeric MASCHINO <emeric.maschino@gmail.com> to control@bugs.debian.org. (Sun, 25 Aug 2013 12:30:25 GMT) Full text and rfc822 format available.

No longer marked as fixed in versions webkit/1.8.1-3.4. Request was from Émeric MASCHINO <emeric.maschino@gmail.com> to control@bugs.debian.org. (Sun, 25 Aug 2013 12:30:25 GMT) Full text and rfc822 format available.

Marked as found in versions webkitgtk/2.0.4-2. Request was from Émeric MASCHINO <emeric.maschino@gmail.com> to control@bugs.debian.org. (Sun, 25 Aug 2013 13:27:11 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>:
Bug#642750; Package src:webkit. (Sun, 25 Aug 2013 13:33:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Émeric MASCHINO <emeric.maschino@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian WebKit Maintainers <pkg-webkit-maintainers@lists.alioth.debian.org>. (Sun, 25 Aug 2013 13:33:09 GMT) Full text and rfc822 format available.

Message #145 received at 642750@bugs.debian.org (full text, mbox):

From: Émeric MASCHINO <emeric.maschino@gmail.com>
To: 642750@bugs.debian.org
Subject: epiphany-browser once again unusable on ia64
Date: Sun, 25 Aug 2013 15:30:10 +0200
[Message part 1 (text/plain, inline)]
Hi,

With the switch from WebKit 1.8.1 to 2.0.4, instability is back on
IA-64: Epiphany simply can't open any URL without crashing (cf. the
attached gdb output when trying to go to http://www.gnome.org).

     Émeric
[gdb.txt (text/plain, attachment)]

Reply sent to Stephan Schreiber <info@fs-driver.org>:
You have taken responsibility. (Wed, 28 Aug 2013 19:03:04 GMT) Full text and rfc822 format available.

Notification sent to Émeric Maschino <emeric.maschino@gmail.com>:
Bug acknowledged by developer. (Wed, 28 Aug 2013 19:03:04 GMT) Full text and rfc822 format available.

Message #150 received at 642750-close@bugs.debian.org (full text, mbox):

From: Stephan Schreiber <info@fs-driver.org>
To: 642750-close@bugs.debian.org
Subject: epiphany-browser once again unusable on ia64
Date: Wed, 28 Aug 2013 20:52:03 +0200
Please stop that recycling of bug reports.
Epiphany/Webkit is a real buggy software and has a real poor user  
experience - on any arch. Thus, Epiphany is no longer installed as  
default on Debian.
We won't be able to fix it using ia64 machines.
I wouldn't invest any time on Webkit.

Stephan





Bug archived. Request was from Stephan Schreiber <info@fs-driver.org> to control@bugs.debian.org. (Wed, 28 Aug 2013 19:09:07 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 25 07:19:44 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.