Groups > linux.debian.bugs.dist > #1112373 > unrolled thread

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

Started by	Sebastian Krzyszkowiak <dos@dosowisko.net>
First post	2022-08-07 22:30 +0200
Last post	2022-09-30 11:10 +0200
Articles	20 on this page of 26 — 3 participants

Back to article view | Back to linux.debian.bugs.dist

  Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Sebastian Krzyszkowiak <dos@dosowisko.net> - 2022-08-07 22:30 +0200
    Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Sebastian Krzyszkowiak <dos@dosowisko.net> - 2022-08-07 22:50 +0200
    Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-08-15 13:00 +0200
      Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Sebastian Krzyszkowiak <dos@dosowisko.net> - 2022-08-17 01:10 +0200
        Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-08-17 12:40 +0200
          Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-16 03:40 +0200
            Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-09-20 17:50 +0200
              Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Sebastian Krzyszkowiak <dos@dosowisko.net> - 2022-09-29 18:30 +0200
              Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Sebastian Krzyszkowiak <dos@dosowisko.net> - 2022-09-30 13:10 +0200
                Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-09-30 15:30 +0200
                Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-10-03 06:10 +0200
                  Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-10-03 12:20 +0200
            Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-09-21 13:00 +0200
              Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-22 00:50 +0200
                Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-09-23 00:50 +0200
                  Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-25 06:50 +0200
                    Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-09-26 02:10 +0200
                      Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-26 02:30 +0200
                        Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-09-26 09:50 +0200
                          Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-27 03:20 +0200
                            Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-27 07:10 +0200
                              Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-28 02:10 +0200
                                Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-09-29 13:30 +0200
                                  Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-30 06:30 +0200
                                    Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Dominique MARTINET <dominique.martinet@atmark-techno.com> - 2022-09-30 10:10 +0200
                                      Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64 Alberto Garcia <berto@igalia.com> - 2022-09-30 11:10 +0200

Page 1 of 2 [1] 2 Next page →

#1112373 — Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

From	Sebastian Krzyszkowiak <dos@dosowisko.net>
Date	2022-08-07 22:30 +0200
Subject	Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64
Message-ID	<ERV4l-gEw6-5@gated-at.bofh.it>

Package: libwebkit2gtk-4.0-37
Version: 2.36.3-1~deb11u1
Severity: important
X-Debbugs-Cc: dos@dosowisko.net, team@security.debian.org

Dear Maintainer,

since 2.36.0-3~deb11u1, webkit2gtk in bullseye has been almost unusable on
arm64 computers, crashing a lot when navigating between pages.

An easy way to reproduce is to navigate to https://news.ycombinator.com/
and click some link (for example, "new" or "login"); or navigate to
https://mobile.twitter.com/ which makes it crash right away. Crashes
are reproducible in both GNOME Web and in MiniBrowser shipped by
webkit2gtk package.

This has been seen on various machines and in downstream distros like PureOS
as well (https://source.puri.sm/Librem5/debs/epiphany/-/issues/38)

Example backtrace:

[🡕] Process 14397 (WebKitNetworkPr) of user 1000 dumped core.
                                                   
Stack trace of thread 14397:
#0  0x0000ffff914f92ac __GI_raise (libc.so.6 + 0x372ac)
#1  0x0000ffff914e5ea0 __GI_abort (libc.so.6 + 0x23ea0)
#2  0x0000ffff93f89c50 _Z16WTFCrashWithInfoiPKcS0_i (libjavascriptcoregtk-4.0.so.18 + 0x198c50)
#3  0x0000ffff94f2a138 _ZN3WTF10StackTrace17captureStackTraceEii (libjavascriptcoregtk-4.0.so.18 + 0x1139138)
#4  0x0000ffff94f05a30 WTFReleaseLogStackTrace (libjavascriptcoregtk-4.0.so.18 + 0x1114a30)
#5  0x0000ffff97f02988 _ZN7WebCore13internalErrorERKN3WTF3URLE (libwebkit2gtk-4.0.so.37 + 0x214a988)
#6  0x0000ffff966038e0 _ZN6WebKit29NetworkConnectionToWebProcess12preconnectToESt8optionalIN3WTF16ObjectIdentifierIN7WebCore14ResourceLoaderEEEEONS_29NetworkResourceLoadParametersE (libwebkit2gtk-4.0.so.37 + 0x84b8e0)
#7  0x0000ffff964e0eb8 _ZN6WebKit29NetworkConnectionToWebProcess46didReceiveNetworkConnectionToWebProcessMessageERN3IPC10ConnectionERNS1_7DecoderE (libwebkit2gtk-4.0.so.37 + 0x728eb8)
#8  0x0000ffff9676eb70 _ZN3IPC10Connection15dispatchMessageESt10unique_ptrINS_7DecoderESt14default_deleteIS2_EE (libwebkit2gtk-4.0.so.37 + 0x9b6b70)
#9  0x0000ffff9676ef08 _ZN3IPC10Connection26dispatchOneIncomingMessageEv (libwebkit2gtk-4.0.so.37 + 0x9b6f08)
#10 0x0000ffff94f28ad0 _ZN3WTF7RunLoop11performWorkEv (libjavascriptcoregtk-4.0.so.18 + 0x1137ad0)
#11 0x0000ffff94f819f4 _ZZN3WTF7RunLoopC1EvEN3$_18__invokeEPv (libjavascriptcoregtk-4.0.so.18 + 0x11909f4)
#12 0x0000ffff94f80d88 _ZN3WTF7RunLoop3$_08__invokeEP8_GSourcePFiPvES4_ (libjavascriptcoregtk-4.0.so.18 + 0x118fd88)
#13 0x0000ffff91a53ab4 g_main_dispatch (libglib-2.0.so.0 + 0x53ab4)
#14 0x0000ffff91a53e5c g_main_context_iterate (libglib-2.0.so.0 + 0x53e5c)
#15 0x0000ffff91a541b0 g_main_loop_run (libglib-2.0.so.0 + 0x541b0)
#16 0x0000ffff94f81384 _ZN3WTF7RunLoop3runEv (libjavascriptcoregtk-4.0.so.18 + 0x1190384)
#17 0x0000ffff9674287c _ZN6WebKit20AuxiliaryProcessMainINS_22NetworkProcessMainSoupEEEiiPPc (libwebkit2gtk-4.0.so.37 + 0x98a87c)
#18 0x0000ffff914e6218 __libc_start_main (libc.so.6 + 0x24218)
#19 0x0000000000400874 $x (WebKitNetworkProcess + 0x874)
#20 0x0000000000400874 $x (WebKitNetworkProcess + 0x874)

[🡕] Process 14382 (WebKitWebProces) of user 1000 dumped core.
                                                   
Stack trace of thread 2:
#0  0x0000ffff854082ac __GI_raise (libc.so.6 + 0x372ac)
#1  0x0000ffff853f4ea0 __GI_abort (libc.so.6 + 0x23ea0)
#2  0x0000ffff87e98c50 _Z16WTFCrashWithInfoiPKcS0_i (libjavascriptcoregtk-4.0.so.18 + 0x198c50)
#3  0x0000ffff88e39138 _ZN3WTF10StackTrace17captureStackTraceEii (libjavascriptcoregtk-4.0.so.18 + 0x1139138)
#4  0x0000ffff88e14a30 WTFReleaseLogStackTrace (libjavascriptcoregtk-4.0.so.18 + 0x1114a30)
#5  0x0000ffff8be11988 _ZN7WebCore13internalErrorERKN3WTF3URLE (libwebkit2gtk-4.0.so.37 + 0x214a988)
#6  0x0000ffff8a9c1824 _ZN6WebKit17WebLoaderStrategy30internallyFailedLoadTimerFiredEv (libwebkit2gtk-4.0.so.37 + 0xcfa824)
#7  0x0000ffff88e90aa0 _ZZN3WTF7RunLoop9TimerBaseC1ERS0_EN3$_38__invokeEPv (libjavascriptcoregtk-4.0.so.18 + 0x1190aa0)
#8  0x0000ffff88e8fd88 _ZN3WTF7RunLoop3$_08__invokeEP8_GSourcePFiPvES4_ (libjavascriptcoregtk-4.0.so.18 + 0x118fd88)
#9  0x0000ffff85962ab4 g_main_dispatch (libglib-2.0.so.0 + 0x53ab4)
#10 0x0000ffff85962e5c g_main_context_iterate (libglib-2.0.so.0 + 0x53e5c)
#11 0x0000ffff859631b0 g_main_loop_run (libglib-2.0.so.0 + 0x541b0)
#12 0x0000ffff88e90384 _ZN3WTF7RunLoop3runEv (libjavascriptcoregtk-4.0.so.18 + 0x1190384)
#13 0x0000ffff8aa7b2b4 _ZN6WebKit20AuxiliaryProcessMainINS_17WebProcessMainGtkEEEiiPPc (libwebkit2gtk-4.0.so.37 + 0xdb42b4)
#14 0x0000ffff853f5218 __libc_start_main (libc.so.6 + 0x24218)
#15 0x0000000000400874 $x (WebKitWebProcess + 0x874)
#16 0x0000000000400874 $x (WebKitWebProcess + 0x874)


-- System Information:
Debian Release: 11.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.15.52-rockchip64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  bubblewrap                      0.4.1-3
ii  gstreamer1.0-plugins-base       1.18.4-2
ii  gstreamer1.0-plugins-good       1.18.4-2
ii  libatk1.0-0                     2.36.0-2
ii  libc6                           2.31-13+deb11u3
ii  libcairo-gobject2               1.16.0-5
ii  libcairo2                       1.16.0-5
ii  libegl1                         1.3.2-1
ii  libenchant-2-2                  2.2.15-1
ii  libfontconfig1                  2.13.1-4.2
ii  libfreetype6                    2.10.4+dfsg-1+deb11u1
ii  libgcc-s1                       10.2.1-6
ii  libgcrypt20                     1.8.7-6
ii  libgdk-pixbuf-2.0-0             2.42.2+dfsg-1
ii  libgles2                        1.3.2-1
ii  libglib2.0-0                    2.66.8-1
ii  libgpg-error0                   1.38-2
ii  libgstreamer-gl1.0-0            1.18.4-2
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0               1.18.4-2.1
ii  libgtk-3-0                      3.24.24-4+deb11u2
ii  libharfbuzz-icu0                2.7.4-1
ii  libharfbuzz0b                   2.7.4-1
ii  libhyphen0                      2.8.8-7
ii  libicu67                        67.1-7
ii  libjavascriptcoregtk-4.0-18     2.36.3-1~deb11u1
ii  libjpeg62-turbo                 1:2.0.6-4
ii  liblcms2-2                      2.12~rc1-2
ii  libmanette-0.2-0                0.2.5-1
ii  libnotify4                      0.7.9-3
ii  libopenjp2-7                    2.4.0-3
ii  libpango-1.0-0                  1.48.2-1
ii  libpangocairo-1.0-0             1.48.2-1
ii  libpng16-16                     1.6.37-3
ii  libseccomp2                     2.5.1-1+deb11u1
ii  libsecret-1-0                   0.20.4-2
ii  libsoup2.4-1                    2.72.0-2
ii  libsqlite3-0                    3.34.1-3
ii  libstdc++6                      10.2.1-6
ii  libsystemd0                     247.3-7
ii  libtasn1-6                      4.16.0-2
ii  libwayland-client0              1.18.0-2~exp1.1
ii  libwayland-egl1                 1.18.0-2~exp1.1
ii  libwayland-server0              1.18.0-2~exp1.1
ii  libwebp6                        0.6.1-2.1
ii  libwebpdemux2                   0.6.1-2.1
ii  libwoff1                        1.0.2-1+b1
ii  libwpe-1.0-1                    1.10.0-2
ii  libwpebackend-fdo-1.0-1         1.8.0-1
ii  libx11-6                        2:1.7.2-1
ii  libxcomposite1                  1:0.4.5-1
ii  libxdamage1                     1:1.1.5-2
ii  libxml2                         2.9.10+dfsg-6.7+deb11u2
ii  libxrender1                     1:0.9.10-1
ii  libxslt1.1                      1.1.34-4
ii  libxt6                          1:1.2.0-1
ii  xdg-dbus-proxy                  0.1.2-2
ii  zlib1g                          1:1.2.11.dfsg-2+deb11u1

Versions of packages libwebkit2gtk-4.0-37 recommends:
ii  gstreamer1.0-gl           1.18.4-2
ii  gstreamer1.0-libav        1.18.4-3
ii  gstreamer1.0-plugins-bad  1.18.4-3
ii  libgl1-mesa-dri           21.2.1-2
ii  xdg-desktop-portal-gtk    1.8.0-1

Versions of packages libwebkit2gtk-4.0-37 suggests:
pn  gstreamer1.0-alsa  <none>

-- no debconf information

[toc] | [next] | [standalone]

#1112375

From	Sebastian Krzyszkowiak <dos@dosowisko.net>
Date	2022-08-07 22:50 +0200
Message-ID	<ERVnH-gECl-1@gated-at.bofh.it>
In reply to	#1112373

For the record, I've just realized that the system I reported it from
was lacking bullseye-security updates, but I've checked it now on a
fully up-to-date arm64 system with webkit2gtk 2.36.4-1~deb11u1 and
it's still crashing in the same way.

[toc] | [prev] | [next] | [standalone]

#1113143

From	Alberto Garcia <berto@igalia.com>
Date	2022-08-15 13:00 +0200
Message-ID	<EUFZ7-Jbb-1@gated-at.bofh.it>
In reply to	#1112373

On Sun, Aug 07, 2022 at 10:24:45PM +0200, Sebastian Krzyszkowiak wrote:

> since 2.36.0-3~deb11u1, webkit2gtk in bullseye has been almost
> unusable on arm64 computers, crashing a lot when navigating between
> pages.

Hello,

I'm going to publish 2.36.6-1~deb11u1 this week. It contains a number
of crash fixes and I would appreciate if you could verify whether the
problem still happens with it.

Thanks,

Berto

[toc] | [prev] | [next] | [standalone]

#1113359

From	Sebastian Krzyszkowiak <dos@dosowisko.net>
Date	2022-08-17 01:10 +0200
Message-ID	<EVdR7-13MF-11@gated-at.bofh.it>
In reply to	#1113143

On 8/15/22, Alberto Garcia <berto@igalia.com> wrote:
> On Sun, Aug 07, 2022 at 10:24:45PM +0200, Sebastian Krzyszkowiak wrote:
>
>> since 2.36.0-3~deb11u1, webkit2gtk in bullseye has been almost
>> unusable on arm64 computers, crashing a lot when navigating between
>> pages.
>
> Hello,
>
> I'm going to publish 2.36.6-1~deb11u1 this week. It contains a number
> of crash fixes and I would appreciate if you could verify whether the
> problem still happens with it.
>
> Thanks,
>
> Berto

Hi Berto,

I've just tried 2.36.6-1~deb11u1 and it still crashes the same way.

Note that these crashes seem exclusive to backports; as far as I'm
aware they don't happen on bookworm at all.

Cheers,
Sebastian

[toc] | [prev] | [next] | [standalone]

#1113394

From	Alberto Garcia <berto@igalia.com>
Date	2022-08-17 12:40 +0200
Message-ID	<EVoCR-1acS-7@gated-at.bofh.it>
In reply to	#1113359

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=244026

On Wed, Aug 17, 2022 at 01:01:46AM +0200, Sebastian Krzyszkowiak wrote:
> > I'm going to publish 2.36.6-1~deb11u1 this week. It contains a number
> > of crash fixes and I would appreciate if you could verify whether the
> > problem still happens with it.
> >
> I've just tried 2.36.6-1~deb11u1 and it still crashes the same way.
> 
> Note that these crashes seem exclusive to backports; as far as I'm
> aware they don't happen on bookworm at all.

Thanks, I just forwarded the bug upstream, I'll try to reproduce it
myself this or next week.

Berto

[toc] | [prev] | [next] | [standalone]

#1117394

From	Dominique MARTINET <dominique.martinet@atmark-techno.com>
Date	2022-09-16 03:40 +0200
Message-ID	<F68uJ-7OU3-7@gated-at.bofh.it>
In reply to	#1113394

Hi,

Alberto Garcia wrote on Wed, Aug 17, 2022 at 10:31:22AM +0000:
> Thanks, I just forwarded the bug upstream, I'll try to reproduce it
> myself this or next week.

I've also been observing similar crashes on aarch64 bullseye package
and using bookworm is not an option for me (thanks to proprietary
drivers...)


The traces are slightly different:

/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000ffff7cfdfaa0 in __GI_abort () at abort.c:79
#2  0x0000ffff7fa8ac50 in WTFCrashWithInfo(int, char const*, char const*, int) () at WTF/Headers/wtf/Assertions.h:741
#3  0x0000ffff80a2d5a8 in captureStackTrace () at ../Source/WTF/wtf/StackTrace.cpp:79
#4  0x0000ffff80a08ea0 in WTFReleaseLogStackTrace () at ../Source/WTF/wtf/Assertions.cpp:592
#5  0x0000ffff83c06550 in internalError () at ../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0x0000ffff820e8d1c in preconnectTo () at ../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:735
#7  0x0000ffff81fc62f4 in callMemberFunctionImpl<WebKit::NetworkConnectionToWebProcess, void (WebKit::NetworkConnectionToWebProcess::*)(std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters&&), std::tuple<std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters>, 0, 1> () at ../Source/WebKit/Platform/IPC/HandleMessage.h:125
#8  callMemberFunction<WebKit::NetworkConnectionToWebProcess, void (WebKit::NetworkConnectionToWebProcess::*)(std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters&&), std::tuple<std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters>, std::integer_sequence<unsigned long, 0, 1> > () at ../Source/WebKit/Platform/IPC/HandleMessage.h:131
#9  handleMessage<Messages::NetworkConnectionToWebProcess::PreconnectTo, WebKit::NetworkConnectionToWebProcess, void (WebKit::NetworkConnectionToWebProcess::*)(std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters&&)> () at ../Source/WebKit/Platform/IPC/HandleMessage.h:196
#10 didReceiveNetworkConnectionToWebProcessMessage () at DerivedSources/WebKit/NetworkConnectionToWebProcessMessageReceiver.cpp:479
#11 0x0000ffff822543d0 in dispatchMessage () at ../Source/WebKit/Platform/IPC/Connection.cpp:1134
#12 0x0000ffff82254768 in dispatchOneIncomingMessage () at ../Source/WebKit/Platform/IPC/Connection.cpp:1203
#13 0x0000ffff80a2bf40 in operator() () at ../Source/WTF/wtf/Function.h:82
#14 performWork () at ../Source/WTF/wtf/RunLoop.cpp:133
#15 0x0000ffff80a85190 in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:80
#16 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:79
#17 0x0000ffff80a84524 in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#18 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#19 0x0000ffff7d551ab4 in g_main_context_dispatch () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#20 0x0000ffff7d551e5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#21 0x0000ffff7d5521b0 in g_main_loop_run () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#22 0x0000ffff80a84b20 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#23 0x0000ffff822280d8 in run () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:70
#24 AuxiliaryProcessMain<WebKit::NetworkProcessMainSoup> () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:96
#25 0x0000ffff7cfdfe18 in __libc_start_main (main=0x400878 <__wrap_main>, argc=3, argv=0xfffff1c90058, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:308
    #26 0x0000000000400874 in _start ()


/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000ffff99831aa0 in __GI_abort () at abort.c:79
#2  0x0000ffff9c2dcc50 in WTFCrashWithInfo(int, char const*, char const*, int) () at WTF/Headers/wtf/Assertions.h:741
#3  0x0000ffff9d27f5a8 in captureStackTrace () at ../Source/WTF/wtf/StackTrace.cpp:79
#4  0x0000ffff9d25aea0 in WTFReleaseLogStackTrace () at ../Source/WTF/wtf/Assertions.cpp:592
#5  0x0000ffffa0458550 in internalError () at ../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0x0000ffff9edead30 in internallyFailedLoadTimerFired () at ../Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:495
#7  0x0000ffff9d2d723c in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:177
#8  __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:169
#9  0x0000ffff9d2d6524 in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#10 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#11 0x0000ffff99da3ab4 in g_main_context_dispatch () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#12 0x0000ffff99da3e5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#13 0x0000ffff99da41b0 in g_main_loop_run () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#14 0x0000ffff9d2d6b20 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#15 0x0000ffff9eea47c4 in run () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:70
#16 AuxiliaryProcessMain<WebKit::WebProcessMainGtk> () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:96
#17 0x0000ffff99831e18 in __libc_start_main (main=0x400878 <__wrap_main>, argc=3, argv=0xfffff7b85168, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:308
    #18 0x0000000000400874 in _start ()



hopefully the root of the problem is the same and having debug symbols
installed will help pinpoint what's wrong.

(a likely reason it's different is I run with WEBKIT_FORCE_SANDBOX=0
because the sandbox forbids access to GPU driver /dev non-standard
node... but honestly at this point it could be completely different,
I wasn't sure if I should open a new bug report or not :/)

I've downloaded the sources and will start looking into it as free time
permits.


Thanks,
-- 
Dominique Martinet

[toc] | [prev] | [next] | [standalone]

#1117994

From	Alberto Garcia <berto@igalia.com>
Date	2022-09-20 17:50 +0200
Message-ID	<F7NFv-8SrG-5@gated-at.bofh.it>
In reply to	#1117394

On Fri, Sep 16, 2022 at 10:18:32AM +0900, Dominique MARTINET wrote:

> Alberto Garcia wrote on Wed, Aug 17, 2022 at 10:31:22AM +0000:
> > Thanks, I just forwarded the bug upstream, I'll try to reproduce it
> > myself this or next week.
> 
> I've also been observing similar crashes on aarch64 bullseye package
> and using bookworm is not an option for me (thanks to proprietary
> drivers...)
> 
> 
> The traces are slightly different:

Sorry for the late reply, and thanks! I think the traces are useful,
I added them to the upstream bug report and I'll try to discuss them
with the development team.

By the way 2.38.0 just came out, it'll probably be backported soon to
bullseye.

Berto

[toc] | [prev] | [next] | [standalone]

#1119264

From	Sebastian Krzyszkowiak <dos@dosowisko.net>
Date	2022-09-29 18:30 +0200
Message-ID	<Fb4A9-aUNL-7@gated-at.bofh.it>
In reply to	#1117994

On Tue, Sep 20, 2022 at 5:44 PM Alberto Garcia <berto@igalia.com> wrote:
> By the way 2.38.0 just came out, it'll probably be backported soon to
> bullseye.

Hi Alberto,

the patch that sets setAllowsServerPreconnect does not fix the
original issue, however, this one does:
https://github.com/WebKit/WebKit/pull/4790

With this applied on top of your recent backport of 2.38.0, WebKit
becomes somewhat usable on arm64 in bullseye. It still crashes on some
pages (such as Twitter), but in a different way (somewhere in JSC)
which probably deserves a separate issue.

Cheers,
Sebastian

[toc] | [prev] | [next] | [standalone]

#1119346

From	Sebastian Krzyszkowiak <dos@dosowisko.net>
Date	2022-09-30 13:10 +0200
Message-ID	<Fbm42-b5gi-11@gated-at.bofh.it>
In reply to	#1117994

On Fri, Sep 30, 2022 at 11:05 AM Alberto Garcia <berto@igalia.com> wrote:
> Can you check if it works for you? If it does then I'll switch back to
> gcc for the next upload.

I have tested your unpatched-gcc build on my machines and it appears
perfectly usable - haven't managed to make it crash so far.

I can still see some backtraces showing up in logs due to preconnect
attempts, so applying PR 4790 will likely still be a good idea, but it
doesn't bring down the whole process anymore.

Cheers,
Sebastian

[toc] | [prev] | [next] | [standalone]

#1119357

From	Alberto Garcia <berto@igalia.com>
Date	2022-09-30 15:30 +0200
Message-ID	<Fbofv-b6rd-1@gated-at.bofh.it>
In reply to	#1119346

Control: tags -1 pending

On Fri, Sep 30, 2022 at 01:01:55PM +0200, Sebastian Krzyszkowiak wrote:

> > Can you check if it works for you? If it does then I'll switch
> > back to gcc for the next upload.
> 
> I have tested your unpatched-gcc build on my machines and it appears
> perfectly usable - haven't managed to make it crash so far.

Ok, then the next backport will use gcc instead of clang for arm64
(unfortunately gcc still crashes on amd64).

Thanks!

Berto

[toc] | [prev] | [next] | [standalone]

#1119656

From	Dominique MARTINET <dominique.martinet@atmark-techno.com>
Date	2022-10-03 06:10 +0200
Message-ID	<FckWd-bH2j-1@gated-at.bofh.it>
In reply to	#1119346

Hi Alberto, Sebastian,

Sebastian Krzyszkowiak wrote on Thu, Sep 29, 2022 at 06:15:56PM +0200:
> the patch that sets setAllowsServerPreconnect does not fix the
> original issue, however, this one does:
> https://github.com/WebKit/WebKit/pull/4790
> 
> With this applied on top of your recent backport of 2.38.0, WebKit
> becomes somewhat usable on arm64 in bullseye. It still crashes on some
> pages (such as Twitter), but in a different way (somewhere in JSC)
> which probably deserves a separate issue.

Thank you for finding this other PR -- I can confirm that fixes the
original issue which crashed almost immediately on any page, and also
confirm there are leftover crashes with a clang build on this patch.

Here's the backtrace I get:
(gdb) bt
#0  codeBlock () at ../Source/JavaScriptCore/interpreter/RegisterInlines.h:41
#1  codeBlock () at ../Source/JavaScriptCore/interpreter/CallFrameInlines.h:62
#2  operationArithNegateProfiledOptimize () at ../Source/JavaScriptCore/jit/JITOperations.cpp:3361
#3  0x0000ffff74148358 in ?? ()
#4  0x0000ffff2ed44080 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

unfortunately it looks like gdb doesn't manage to unwind it properly (or
indeed corrupted), so that might be difficult to debug.

Since gcc build appears to fix the issue I think that's the way to go
for bullseye, at least until we understand where that makes a
difference...

Sebastian Krzyszkowiak wrote on Fri, Sep 30, 2022 at 01:01:55PM +0200:
> I can still see some backtraces showing up in logs due to preconnect
> attempts, so applying PR 4790 will likely still be a good idea, but it
> doesn't bring down the whole process anymore.

I agree on principle; out of curiousity where did you see these logs?
I do not see anything on stdout/stderr with the gcc build, but I would
assume this to be logged elsewhere or perhaps only if some magic env var
is set?

Thanks,
-- 
Dominique

[toc] | [prev] | [next] | [standalone]

#1119680

From	Alberto Garcia <berto@igalia.com>
Date	2022-10-03 12:20 +0200
Message-ID	<FcqIi-bKwI-9@gated-at.bofh.it>
In reply to	#1119656

On Mon, Oct 03, 2022 at 01:07:09PM +0900, Dominique MARTINET wrote:
> Since gcc build appears to fix the issue I think that's the way to
> go for bullseye, at least until we understand where that makes a
> difference...

gcc is the default compiler that we use for WebKit in Debian, the only
reason why it wasn't being used in bullseye in this case it's because
of this bug:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008098

I narrowed this one down as much as possible, we should probably
report it upstream but I didn't have the chance to do it yet.

Berto

[toc] | [prev] | [next] | [standalone]

#1118100

From	Alberto Garcia <berto@igalia.com>
Date	2022-09-21 13:00 +0200
Message-ID	<F85Cp-93vy-1@gated-at.bofh.it>
In reply to	#1117394

On Fri, Sep 16, 2022 at 10:18:32AM +0900, Dominique MARTINET wrote:
> The traces are slightly different:
> 
> /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x0000ffff7cfdfaa0 in __GI_abort () at abort.c:79
> #2  0x0000ffff7fa8ac50 in WTFCrashWithInfo(int, char const*, char const*, int) () at WTF/Headers/wtf/Assertions.h:741
> #3  0x0000ffff80a2d5a8 in captureStackTrace () at ../Source/WTF/wtf/StackTrace.cpp:79
> #4  0x0000ffff80a08ea0 in WTFReleaseLogStackTrace () at ../Source/WTF/wtf/Assertions.cpp:592
> #5  0x0000ffff83c06550 in internalError () at ../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
> #6  0x0000ffff820e8d1c in preconnectTo () at ../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:735

Hello Dominique,

do you think you can try this patch?

   https://bug-244026-attachments.webkit.org/attachment.cgi?id=462492&action=diff&format=raw&headers=1

If you have problems / are unsure about how to build WebKit I can
provide packages for you. Just let me know.

Berto

[toc] | [prev] | [next] | [standalone]

#1118187

From	Dominique MARTINET <dominique.martinet@atmark-techno.com>
Date	2022-09-22 00:50 +0200
Message-ID	<F8gHw-9aeZ-1@gated-at.bofh.it>
In reply to	#1118100

Hi Alberto,

Alberto Garcia wrote on Wed, Sep 21, 2022 at 12:54:22PM +0200:
> On Fri, Sep 16, 2022 at 10:18:32AM +0900, Dominique MARTINET wrote:
> > The traces are slightly different:
> > 
> > /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
> > (gdb) bt
> > #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > #1  0x0000ffff7cfdfaa0 in __GI_abort () at abort.c:79
> > #2  0x0000ffff7fa8ac50 in WTFCrashWithInfo(int, char const*, char const*, int) () at WTF/Headers/wtf/Assertions.h:741
> > #3  0x0000ffff80a2d5a8 in captureStackTrace () at ../Source/WTF/wtf/StackTrace.cpp:79
> > #4  0x0000ffff80a08ea0 in WTFReleaseLogStackTrace () at ../Source/WTF/wtf/Assertions.cpp:592
> > #5  0x0000ffff83c06550 in internalError () at ../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
> > #6  0x0000ffff820e8d1c in preconnectTo () at ../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:735
> 
> do you think you can try this patch?
> 
>    https://bug-244026-attachments.webkit.org/attachment.cgi?id=462492&action=diff&format=raw&headers=1

Thanks!

> If you have problems / are unsure about how to build WebKit I can
> provide packages for you. Just let me know.

I'm definitely unsure about how to build WebKit, but that can be
fixed... I might need to find somewhere with a bit more memory though,
been trying to build the 2.38 release yesterday and build got OOM killed
even with -j1 on a VM with 6GB of ram :/

If you have time to build a package you might be faster than me, so I'd
appreciate it :)

-- 
Dominique

[toc] | [prev] | [next] | [standalone]

#1118354

From	Alberto Garcia <berto@igalia.com>
Date	2022-09-23 00:50 +0200
Message-ID	<F8Db3-9obp-1@gated-at.bofh.it>
In reply to	#1118187

On Thu, Sep 22, 2022 at 07:45:29AM +0900, Dominique MARTINET wrote:

> If you have time to build a package you might be faster than me, so
> I'd appreciate it :)

Hi, I built two sets of packages, the unpatched vanilla version of
2.38.0 and the one with the patch I mentioned in my previous comment:

https://people.debian.org/~berto/files/webkitgtk-2.38.0-arm64/

Can you test them both and tell me if things get better?

Thanks!

Berto

[toc] | [prev] | [next] | [standalone]

#1118609

From	Dominique MARTINET <dominique.martinet@atmark-techno.com>
Date	2022-09-25 06:50 +0200
Message-ID	<F9rKx-9U7u-1@gated-at.bofh.it>
In reply to	#1118354

Hi,

Alberto Garcia wrote on Fri, Sep 23, 2022 at 12:38:58AM +0200:
> I built two sets of packages, the unpatched vanilla version of
> 2.38.0 and the one with the patch I mentioned in my previous comment:
> 
> https://people.debian.org/~berto/files/webkitgtk-2.38.0-arm64/
> 
> Can you test them both and tell me if things get better?

Thanks!
You were indeed faster than me... But it looks like these packages were
built for debian testing/bookworm (require libc6 >= 2.34), so I cannot
test easily due to proprietary libGL and other drivers woes.

(I actually do have some frankendebian version for testing, I'll give it
a try on Monday, but this will not necessarily have the same problems as
what I had reported here on stable/bullseye)


I should get access to a beefier machine at work and will resume my
building attempts there, and report with both tests (the packages you
provided on bookworm and stable package with patch) hopefully by the end
of Monday.

-- 
Dominique

[toc] | [prev] | [next] | [standalone]

#1118749

From	Alberto Garcia <berto@igalia.com>
Date	2022-09-26 02:10 +0200
Message-ID	<F9JR7-a5jE-1@gated-at.bofh.it>
In reply to	#1118609

On Sun, Sep 25, 2022 at 01:40:32PM +0900, Dominique MARTINET wrote:

> > https://people.debian.org/~berto/files/webkitgtk-2.38.0-arm64/

> You were indeed faster than me... But it looks like these packages were
> built for debian testing/bookworm (require libc6 >= 2.34), so I cannot
> test easily due to proprietary libGL and other drivers woes.

Argh, you're right, my fault!!

I just uploaded the packages built for bullseye, same URL, the patched
ones are available already, the unpatched ones soon.

Berto

[toc] | [prev] | [next] | [standalone]

#1118750

From	Dominique MARTINET <dominique.martinet@atmark-techno.com>
Date	2022-09-26 02:30 +0200
Message-ID	<F9Kat-a5pZ-1@gated-at.bofh.it>
In reply to	#1118749

Alberto Garcia wrote on Mon, Sep 26, 2022 at 12:00:04AM +0000:
> I just uploaded the packages built for bullseye, same URL, the patched
> ones are available already, the unpatched ones soon.

Thanks!

I've tried the patched variant, it seems to fail in the same place?

Here's the new trace with adjusted lines:
----
/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000ffff817b3aa0 in __GI_abort () at abort.c:79
#2  0x0000ffff8427958c in WTFCrashWithInfo(int, char const*, char const*, int) () at WTF/Headers/wtf/Assertions.h:754
#3  0x0000ffff8525db20 in captureStackTrace () at ../Source/WTF/wtf/StackTrace.cpp:79
#4  0x0000ffff85232d18 in WTFReleaseLogStackTrace () at ../Source/WTF/wtf/Assertions.cpp:602
#5  0x0000ffff884e8934 in internalError () at ../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0x0000ffff869e6c14 in preconnectTo () at ../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:733
#7  0x0000ffff8689baf8 in callMemberFunctionImpl<WebKit::NetworkConnectionToWebProcess, void (WebKit::NetworkConnectionToWebProcess::*)(std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters&&), std::tuple<std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters>, 0, 1> () at ../Source/WebKit/Platform/IPC/HandleMessage.h:131
#8  callMemberFunction<WebKit::NetworkConnectionToWebProcess, void (WebKit::NetworkConnectionToWebProcess::*)(std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters&&), std::tuple<std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters>, std::integer_sequence<unsigned long, 0, 1> > () at ../Source/WebKit/Platform/IPC/HandleMessage.h:137
#9  handleMessage<Messages::NetworkConnectionToWebProcess::PreconnectTo, WebKit::NetworkConnectionToWebProcess, void (WebKit::NetworkConnectionToWebProcess::*)(std::optional<WTF::ObjectIdentifier<WebCore::ResourceLoader> >, WebKit::NetworkResourceLoadParameters&&)> () at ../Source/WebKit/Platform/IPC/HandleMessage.h:259
#10 didReceiveNetworkConnectionToWebProcessMessage () at DerivedSources/WebKit/NetworkConnectionToWebProcessMessageReceiver.cpp:357
#11 0x0000ffff86b3ff1c in dispatchMessage () at ../Source/WebKit/Platform/IPC/Connection.cpp:1150
#12 0x0000ffff86b402b4 in dispatchOneIncomingMessage () at ../Source/WebKit/Platform/IPC/Connection.cpp:1219
#13 0x0000ffff8525c4b0 in operator() () at ../Source/WTF/wtf/Function.h:82
#14 performWork () at ../Source/WTF/wtf/RunLoop.cpp:133
#15 0x0000ffff852b5570 in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:80
#16 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:79
#17 0x0000ffff852b48f4 in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#18 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#19 0x0000ffff81d25ab4 in g_main_context_dispatch () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#20 0x0000ffff81d25e5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#21 0x0000ffff81d261b0 in g_main_loop_run () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#22 0x0000ffff852b4ef8 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#23 0x0000ffff86b11004 in run () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:71
#24 AuxiliaryProcessMain<WebKit::NetworkProcessMainSoup> () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:97
#25 0x0000ffff817b3e18 in __libc_start_main (main=0x400878 <__wrap_main>, argc=3, argv=0xffffcfa17918, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:308
#26 0x0000000000400874 in _start ()



/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000ffffa0afdaa0 in __GI_abort () at abort.c:79
#2  0x0000ffffa35c358c in WTFCrashWithInfo(int, char const*, char const*, int) () at WTF/Headers/wtf/Assertions.h:754
#3  0x0000ffffa45a7b20 in captureStackTrace () at ../Source/WTF/wtf/StackTrace.cpp:79
#4  0x0000ffffa457cd18 in WTFReleaseLogStackTrace () at ../Source/WTF/wtf/Assertions.cpp:602
#5  0x0000ffffa7832934 in internalError () at ../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0x0000ffffa61e6f6c in internallyFailedLoadTimerFired () at ../Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:503
#7  0x0000ffffa45ff61c in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:177
#8  __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:169
#9  0x0000ffffa45fe8f4 in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#10 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#11 0x0000ffffa106fab4 in g_main_context_dispatch () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#12 0x0000ffffa106fe5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#13 0x0000ffffa10701b0 in g_main_loop_run () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#14 0x0000ffffa45feef8 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#15 0x0000ffffa62a1aac in run () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:71
#16 AuxiliaryProcessMain<WebKit::WebProcessMainGtk> () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:97
#17 0x0000ffffa0afde18 in __libc_start_main (main=0x400878 <__wrap_main>, argc=3, argv=0xffffc73c1cc8, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:308
#18 0x0000000000400874 in _start ()
----

Since the patched variant does not resolve the problem I'm not going to
bother with the unpatched -- please ask if you'd like me to try anyway.


Meanwhile I'm continuing my quest to build webkit, pdebuild failed on an
intermediate ldd command because of improper argument escaping, I'll
retry out of the debian build chroot this time so I can iterate
faster...


Thanks!
-- 
Dominique

[toc] | [prev] | [next] | [standalone]

#1118776

From	Alberto Garcia <berto@igalia.com>
Date	2022-09-26 09:50 +0200
Message-ID	<F9R2h-aaix-5@gated-at.bofh.it>
In reply to	#1118750

On Mon, Sep 26, 2022 at 09:21:45AM +0900, Dominique MARTINET wrote:
> Alberto Garcia wrote on Mon, Sep 26, 2022 at 12:00:04AM +0000:
> > I just uploaded the packages built for bullseye, same URL, the patched
> > ones are available already, the unpatched ones soon.
> 
> Thanks!
> 
> I've tried the patched variant, it seems to fail in the same place?

Ok, thanks. I uploaded the unpatched version, although I suspect it's
not going to make any difference.

Berto

[toc] | [prev] | [next] | [standalone]

#1118907

From	Dominique MARTINET <dominique.martinet@atmark-techno.com>
Date	2022-09-27 03:20 +0200
Message-ID	<Fa7qp-ak9K-7@gated-at.bofh.it>
In reply to	#1118776

Alberto Garcia wrote on Mon, Sep 26, 2022 at 07:44:24AM +0000:
> > I've tried the patched variant, it seems to fail in the same place?
> 
> Ok, thanks. I uploaded the unpatched version, although I suspect it's
> not going to make any difference.

I agree it shouldn't make any difference : I tried anyway, and can
confirm I hit the same trace.

I've also finally finished building yesterday (the last failure I was
referring to wasn't the badly escaped argument -- that was just a
warning -- but ldd segfaulting on qemu-user aarch64 on the webkit so,
presumably because it is too big? I've replaced it with a wrapper around
lddtree and could finish building...), but unfortunately I run into a
different crash before I can test this; I suspect this is due to my
build options, I will try to get closer to the deb package options...
(Or I guess I could actually build the deb package now I have ldd figured
out, but allowing partial builds would be great for actual development...)


I'll report again when/if I make progress, thanks for the follow up and
packages :)

-- 
Dominique

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

Contents

#1112373 — Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

#1112375

#1113143

#1113359

#1113394

#1117394

#1117994

#1119264

#1119346

#1119357

#1119656

#1119680

#1118100

#1118187

#1118354

#1118609

#1118749

#1118750

#1118776

#1118907