Crash with Tumblr search on Debian Bullseye Topic is solved

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
Isengrim
Board Warrior
Board Warrior
Posts: 1325
Joined: 2015-09-08, 22:54
Location: 127.0.0.1
Contact:

Crash with Tumblr search on Debian Bullseye

Unread post by Isengrim » 2020-05-12, 19:53

I've been running into a CTD on Tumblr's search page. Example page. I have tested this on two Debian Bullseye installs and a Linux Mint 19.3 install, with multiple profiles (clean and not), both using Mr. Pusser's repo as well as a build of my own. So far I have only been able to reproduce on the Debian installs.

GDB backtrace below.

Code: Select all

Thread 1 "palemoon" received signal SIGSEGV, Segmentation fault.
MOZ_CrashOOL (aLine=aLine@entry=2988, 
    aReason=aReason@entry=0x555555578408 "(run->regs_mask[elm] & (1U << bit)) == 0")
    at /pale-moon/platform/mfbt/Assertions.cpp:33
33	  MOZ_REALLY_CRASH(aLine);
(gdb) backtrace
#0  MOZ_CrashOOL(int, char const*)
    (aLine=aLine@entry=2988, aReason=aReason@entry=0x555555578408 "(run->regs_mask[elm] & (1U << bit)) == 0") at /pale-moon/platform/mfbt/Assertions.cpp:33
#1  0x0000555555559863 in arena_run_reg_dalloc
    (bin=0x7ffff7900f38, bin=0x7ffff7900f38, size=448, ptr=0x7fffcb389a40, run=0x7fffcb388000)
    at /pale-moon/platform/memory/mozjemalloc/jemalloc.c:2988
#2  arena_dalloc_small
    (mapelm=0x7fffcb300cf8, ptr=0x7fffcb389a40, chunk=0x7fffcb300000, arena=0x7ffff7900200)
    at /pale-moon/platform/memory/mozjemalloc/jemalloc.c:4101
#3  arena_dalloc (ptr=0x7fffcb389a40, offset=563776)
    at /pale-moon/platform/memory/mozjemalloc/jemalloc.c:4228
#4  0x00007ffff6133baa in  () at /lib/x86_64-linux-gnu/libfontconfig.so.1
#5  0x00007ffff161e7a1 in gfxFontconfigFontEntry::gfxFontconfigFontEntry(nsAString_internal const&, unsigned short, short, unsigned char, unsigned char const*, FT_FaceRec_*) (this=
    0x7fffb7ffbe20, aFaceName=..., aWeight=<optimized out>, aStretch=<optimized out>, aStyle=<optimized out>, aData=0x7fffcc69d000 "", aFace=0x7fffbd3e0000)
    at /pale-moon/platform/gfx/thebes/gfxFcPlatformFontList.cpp:252
#6  0x00007ffff162104a in gfxFcPlatformFontList::MakePlatformFont(nsAString_internal const&, unsigned short, short, unsigned char, unsigned char const*, unsigned int)
    (this=<optimized out>, aFontName=..., aWeight=<optimized out>, aStretch=<optimized out>, aStyle=<optimized out>, aFontData=0x7fffcc69d000 "", aLength=78468)
    at /uxp-build-pm/dist/include/mozilla/mozalloc.h:191
#7  0x00007ffff168a96c in gfxUserFontEntry::LoadPlatformFont(unsigned char const*, unsigned int&)
    (this=0x7fffbcdf7560, aFontData=0x7fffb6a8c000 "wOFF", aLength=@0x7fffffffc6fc: 30896)
    at /pale-moon/platform/gfx/thebes/gfxUserFontSet.cpp:656
--Type <RET> for more, q to quit, c to continue without paging--c
#8  0x00007ffff168b982 in gfxUserFontEntry::FontDataDownloadComplete(unsigned char const*, unsigned int, nsresult) (this=0x7fffbcdf7560, aFontData=aFontData@entry=0x7fffb6a8c000 "wOFF", aLength=<optimized out>, aLength@entry=30896, aDownloadStatus=aDownloadStatus@entry=nsresult::NS_OK) at /pale-moon/platform/gfx/thebes/gfxUserFontSet.cpp:754
#9  0x00007ffff28c7d96 in nsFontFaceLoader::OnStreamComplete(nsIStreamLoader*, nsISupports*, nsresult, unsigned int, unsigned char const*) (this=0x7fffbad29c40, aLoader=0x7fffb84f5be0, aContext=<optimized out>, aStatus=nsresult::NS_OK, aStringLen=30896, aString=0x7fffb6a8c000 "wOFF") at /uxp-build-pm/dist/include/mozilla/RefPtr.h:316
#10 0x00007ffff0e4058f in mozilla::net::nsStreamLoader::OnStopRequest(nsIRequest*, nsISupports*, nsresult) (this=0x7fffb84f5be0, request=0x7fffbbfd2048, ctxt=0x0, aStatus=nsresult::NS_OK) at /uxp-build-pm/dist/include/nsCOMPtr.h:1055
#11 0x00007ffff1023d74 in nsCORSListenerProxy::OnStopRequest(nsIRequest*, nsISupports*, nsresult) (this=0x7fffb84f5c40, aRequest=<optimized out>, aContext=<optimized out>, aStatusCode=<optimized out>) at /uxp-build-pm/dist/include/nsCOMPtr.h:766
#12 0x00007ffff104f9fc in mozilla::net::nsHttpChannel::OnStopRequest(nsIRequest*, nsISupports*, nsresult) (this=0x7fffbbfd2000, request=<optimized out>, ctxt=<optimized out>, status=nsresult::NS_OK) at /uxp-build-pm/dist/include/nsCOMPtr.h:1055
#13 0x00007ffff0e29459 in nsInputStreamPump::OnStateStop() (this=this@entry=0x7fffaf343f20) at /uxp-build-pm/dist/include/nsCOMPtr.h:1055
#14 0x00007ffff0e296bf in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7fffaf343f20, stream=<optimized out>) at /pale-moon/platform/netwerk/base/nsInputStreamPump.cpp:433
#15 0x00007ffff0d98a8c in nsInputStreamReadyEvent::Run() (this=0x7fffba114ac0) at /pale-moon/platform/xpcom/io/nsStreamUtils.cpp:95
#16 0x00007ffff0db2f3c in nsThread::ProcessNextEvent(bool, bool*) (aResult=0x7fffffffca7f, aMayWait=<optimized out>, this=0x7ffff7849360) at /pale-moon/platform/xpcom/threads/nsThread.cpp:1141
#17 nsThread::ProcessNextEvent(bool, bool*) (this=0x7ffff7849360, aMayWait=<optimized out>, aResult=0x7fffffffca7f) at /pale-moon/platform/xpcom/threads/nsThread.cpp:1077
#18 0x00007ffff0dd641a in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aThread@entry=0x7ffff7849360, aMayWait=aMayWait@entry=false) at /pale-moon/platform/xpcom/glue/nsThreadUtils.cpp:356
#19 0x00007ffff10aa382 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7fffefca0440, aDelegate=0x7ffff78aa0b0) at /pale-moon/platform/ipc/glue/MessagePump.cpp:96
#20 0x00007ffff1089df5 in MessageLoop::RunInternal() (this=<optimized out>) at /uxp-build-pm/dist/include/mozilla/RefPtr.h:316
#21 MessageLoop::RunHandler() (this=<optimized out>) at /pale-moon/platform/ipc/chromium/src/base/message_loop.cc:225
#22 MessageLoop::Run() (this=<optimized out>) at /pale-moon/platform/ipc/chromium/src/base/message_loop.cc:205
#23 0x00007ffff2703728 in nsBaseAppShell::Run() (this=0x7fffddd15f80) at /pale-moon/platform/widget/nsBaseAppShell.cpp:153
#24 0x00007ffff2dc0fce in nsAppStartup::Run() (this=0x7fffddd1c1f0) at /uxp-build-pm/dist/include/nsCOMPtr.h:766
#25 0x00007ffff2df8a64 in XREMain::XRE_mainRun() (this=this@entry=0x7fffffffcce0) at /uxp-build-pm/dist/include/nsCOMPtr.h:766
#26 0x00007ffff2df9313 in XREMain::XRE_main(int, char**, nsXREAppData const*) (this=this@entry=0x7fffffffcce0, argc=argc@entry=4, argv=argv@entry=0x7fffffffe068, aAppData=aAppData@entry=0x7fffffffcf10) at /pale-moon/platform/toolkit/xre/nsAppRunner.cpp:3996
#27 0x00007ffff2df95da in XRE_main(int, char**, nsXREAppData const*, uint32_t) (argc=4, argv=0x7fffffffe068, aAppData=0x7fffffffcf10, aFlags=<optimized out>) at /pale-moon/platform/toolkit/xre/nsAppRunner.cpp:4078
#28 0x000055555555a6ba in do_main(int, char**, char**, nsIFile*) (argc=4, argv=0x7fffffffe068, envp=<optimized out>, xreDirectory=0x7ffff7878a80) at /pale-moon/palemoon/app/nsBrowserApp.cpp:255
#29 0x0000555555559a29 in main(int, char**, char**) (argc=4, argv=0x7fffffffe068, envp=0x7fffffffe090) at /pale-moon/palemoon/app/nsBrowserApp.cpp:379
The first thing that comes to mind is that all the builds I've tested on were compiled with GCC 9.3... could that be the culprit?
a.k.a. Ascrod
Linux Mint 19.3 Cinnamon (64-bit), Debian Bullseye (64-bit), Windows 7 (64-bit)
"As long as there is someone who will appreciate the work involved in the creation, the effort is time well spent." ~ Tetsuzou Kamadani, Cave Story

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2189
Joined: 2018-05-05, 13:29

Re: Crash with Tumblr search on Debian Bullseye

Unread post by vannilla » 2020-05-12, 20:08

I'm using GCC 9.3 too and it works like a charm, though I'm not on Debian.
The backtrace says the culprit is in fontconfig or anyway in something related to fonts.

User avatar
Isengrim
Board Warrior
Board Warrior
Posts: 1325
Joined: 2015-09-08, 22:54
Location: 127.0.0.1
Contact:

Re: Crash with Tumblr search on Debian Bullseye

Unread post by Isengrim » 2020-05-13, 02:31

vannilla wrote:
2020-05-12, 20:08
I'm using GCC 9.3 too and it works like a charm, though I'm not on Debian.
What distro?
a.k.a. Ascrod
Linux Mint 19.3 Cinnamon (64-bit), Debian Bullseye (64-bit), Windows 7 (64-bit)
"As long as there is someone who will appreciate the work involved in the creation, the effort is time well spent." ~ Tetsuzou Kamadani, Cave Story

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35593
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Crash with Tumblr search on Debian Bullseye

Unread post by Moonchild » 2020-05-13, 05:49

Looks like the crash happens here:

Code: Select all

    // Use fontconfig to fill out the pattern from the FTFace.
    // The "file" argument cannot be nullptr (in fontconfig-2.6.0 at
    // least). The dummy file passed here is removed below.
    //
    // When fontconfig scans the system fonts, FcConfigGetBlanks(nullptr)
    // is passed as the "blanks" argument, which provides that unexpectedly
    // blank glyphs are elided.  Here, however, we pass nullptr for
    // "blanks", effectively assuming that, if the font has a blank glyph,
    // then the author intends any associated character to be rendered
    // blank.
    mFontPattern = FcFreeTypeQueryFace(mFTFace, ToFcChar8Ptr(""), 0, nullptr); ***CRASH***
This is a call out to fontconfig (external code) resulting in a double-free afaict (but the debug trace didn't include the fontconfig source location) so it seems it deallocates something passed into it. Perhaps it's related to this obligatory "file" argument that cannot be null?
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Isengrim
Board Warrior
Board Warrior
Posts: 1325
Joined: 2015-09-08, 22:54
Location: 127.0.0.1
Contact:

Re: Crash with Tumblr search on Debian Bullseye

Unread post by Isengrim » 2020-05-13, 10:54

I think you're right, the issue appears to lie with fontconfig. It looks like we're not the only consumers affected, either:

https://bugzilla.mozilla.org/show_bug.cgi?id=1633467
https://gitlab.freedesktop.org/fontconf ... issues/237
https://bugs.debian.org/cgi-bin/bugrepo ... bug=959800

Per one of the bug report comments, setting gfx.downloadable_fonts.enabled to false should temporarily sidestep the problem until a patch is issued.

Thanks for looking into it. I'll watch for an update to the lib and report back.
a.k.a. Ascrod
Linux Mint 19.3 Cinnamon (64-bit), Debian Bullseye (64-bit), Windows 7 (64-bit)
"As long as there is someone who will appreciate the work involved in the creation, the effort is time well spent." ~ Tetsuzou Kamadani, Cave Story

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35593
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Crash with Tumblr search on Debian Bullseye

Unread post by Moonchild » 2020-05-13, 11:07

Yeah definitely something on the fontconfig end (and confirmed by Mozilla to be a double free). Seems it affects bullseye and sid.
I read through some of the relevant info and I don't think there's anything we can really do here on our end; it just needs to get fixed in Debian.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35593
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Crash with Tumblr search on Debian Bullseye

Unread post by Moonchild » 2020-05-18, 14:04

Seems the fix has been merged upstream in fontconfig so an update of the lib should call this fixed.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Isengrim
Board Warrior
Board Warrior
Posts: 1325
Joined: 2015-09-08, 22:54
Location: 127.0.0.1
Contact:

Re: Crash with Tumblr search on Debian Bullseye

Unread post by Isengrim » 2020-05-19, 02:50

Yep, after an update and a restart of the browser I can confirm it's fixed.

Thanks again. :thumbup:
a.k.a. Ascrod
Linux Mint 19.3 Cinnamon (64-bit), Debian Bullseye (64-bit), Windows 7 (64-bit)
"As long as there is someone who will appreciate the work involved in the creation, the effort is time well spent." ~ Tetsuzou Kamadani, Cave Story

Locked