Page 1 of 1

Crash with Tumblr search on Debian Bullseye

Posted: 2020-05-12, 19:53
by Isengrim
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?

Re: Crash with Tumblr search on Debian Bullseye

Posted: 2020-05-12, 20:08
by vannilla
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.

Re: Crash with Tumblr search on Debian Bullseye

Posted: 2020-05-13, 02:31
by Isengrim
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?

Re: Crash with Tumblr search on Debian Bullseye

Posted: 2020-05-13, 05:49
by Moonchild
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?

Re: Crash with Tumblr search on Debian Bullseye

Posted: 2020-05-13, 10:54
by Isengrim
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.

Re: Crash with Tumblr search on Debian Bullseye

Posted: 2020-05-13, 11:07
by Moonchild
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.

Re: Crash with Tumblr search on Debian Bullseye

Posted: 2020-05-18, 14:04
by Moonchild
Seems the fix has been merged upstream in fontconfig so an update of the lib should call this fixed.

Re: Crash with Tumblr search on Debian Bullseye

Posted: 2020-05-19, 02:50
by Isengrim
Yep, after an update and a restart of the browser I can confirm it's fixed.

Thanks again. :thumbup: