1304355 - SIGSEGV in gfxFontUtils::DecodeFontName

Status: RESOLVED DUPLICATE of bug 757366

(Core :: Graphics: Text, defect, P3)

Description

[Bodo Thiesen]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160919030455

Steps to reproduce:

Create new user account, start firefox.


Actual results:

Program received signal SIGSEGV, Segmentation fault.
0x00007fefe404db5a in gfxFontUtils::DecodeFontName(char const*, int, unsigned int, unsigned int, unsigned int, nsAString_internal&) ()
   from /usr/lib64/firefox/libxul.so
(gdb) bt
#0  0x00007fefe404db5a in gfxFontUtils::DecodeFontName(char const*, int, unsigned int, unsigned int, unsigned int, nsAString_internal&) ()
   from /usr/lib64/firefox/libxul.so
#1  0x00007fefe4050eb9 in gfxFontUtils::ReadNames(char const*, unsigned int, unsigned int, int, int, nsTArray<nsString>&) [clone .part.245] ()
   from /usr/lib64/firefox/libxul.so
#2  0x00007fefe4059434 in gfxFontUtils::ReadCanonicalName(char const*, unsigned int, unsigned int, nsString&) () from /usr/lib64/firefox/libxul.so
#3  0x00007fefe4059659 in gfxFontUtils::GetFullNameFromTable(hb_blob_t*, nsAString_internal&) () from /usr/lib64/firefox/libxul.so
#4  0x00007fefe40599be in gfxFontUtils::GetFullNameFromSFNT(unsigned char const*, unsigned int, nsAString_internal&) () from /usr/lib64/firefox/libxul.so
#5  0x00007fefe408e6f2 in gfxUserFontEntry::LoadPlatformFont(unsigned char const*, unsigned int&) () from /usr/lib64/firefox/libxul.so
#6  0x00007fefe4092056 in gfxUserFontEntry::FontDataDownloadComplete(unsigned char const*, unsigned int, nsresult) () from /usr/lib64/firefox/libxul.so
#7  0x00007fefe58b353c in nsFontFaceLoader::OnStreamComplete(nsIStreamLoader*, nsISupports*, nsresult, unsigned int, unsigned char const*) ()
   from /usr/lib64/firefox/libxul.so
#8  0x00007fefe32cc312 in nsStreamLoader::OnStopRequest(nsIRequest*, nsISupports*, nsresult) () from /usr/lib64/firefox/libxul.so
#9  0x00007fefe3433bd2 in nsCORSListenerProxy::OnStopRequest(nsIRequest*, nsISupports*, nsresult) () from /usr/lib64/firefox/libxul.so
#10 0x00007fefe346a47a in mozilla::net::nsHttpChannel::OnStopRequest(nsIRequest*, nsISupports*, nsresult) () from /usr/lib64/firefox/libxul.so
#11 0x00007fefe32a6af4 in nsInputStreamPump::OnStateStop() () from /usr/lib64/firefox/libxul.so
#12 0x00007fefe32a6f6f in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () from /usr/lib64/firefox/libxul.so
#13 0x00007fefe31d453f in nsInputStreamReadyEvent::Run() () from /usr/lib64/firefox/libxul.so
#14 0x00007fefe31ee06a in nsThread::ProcessNextEvent(bool, bool*) () from /usr/lib64/firefox/libxul.so
#15 0x00007fefe32276aa in NS_ProcessNextEvent(nsIThread*, bool) () from /usr/lib64/firefox/libxul.so
#16 0x00007fefe3599e6a in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /usr/lib64/firefox/libxul.so
#17 0x00007fefe3560f2c in MessageLoop::Run() () from /usr/lib64/firefox/libxul.so
#18 0x00007fefe56b3b68 in nsBaseAppShell::Run() () from /usr/lib64/firefox/libxul.so
#19 0x00007fefe62394de in nsAppStartup::Run() () from /usr/lib64/firefox/libxul.so
#20 0x00007fefe629d8fa in XREMain::XRE_mainRun() () from /usr/lib64/firefox/libxul.so
#21 0x00007fefe629e484 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /usr/lib64/firefox/libxul.so
#22 0x00007fefe629e7f4 in XRE_main () from /usr/lib64/firefox/libxul.so
#23 0x00000000004057d9 in do_main(int, char**, char**, nsIFile*) ()
#24 0x0000000000405060 in main ()

Comment 1

[:Gijs (he/him)]

What source are you compiling from, what does your mozconfig look like, and does this happen when using a mozilla.org build with crashreporting turned on?

Comment 2

[Bodo Thiesen]

> What source are you compiling from,

Gentoo ebuild, uses some patchset (didn't realize before), I hope it's not responsible. Going to file this bug on Gentoo bugtracker, letting them decide, it they caused it.

Marking it as invalid for now, they (or you) can reopen it, if they (or you) believe this not to be their fault.

> what does your mozconfig look like,

Tried to check, what exactly you do mean, but first Google hit to https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Configuring_Build_Options made firefox crash again ...

So, to be short: Gentoo default build.

> and does this happen when using a mozilla.org build with crashreporting turned on?

Hard to test when Firefox crashes upon accessing mozilla.org. Anyways: It seems, the problem only happens there (and developer.*) for now, beause many other other tabs got successfully restored on crash recovery.

Comment 3

[Bodo Thiesen]

FYI: Gentoo Bug: https://bugs.gentoo.org/show_bug.cgi?id=594710

Comment 4

[Bodo Thiesen]

Just realized, I still have a differnt browser installed.

Yes, mozilla.org build crashed too.

Comment 5

[:Gijs (he/him)]

(In reply to Bodo Thiesen from comment #4)
> Just realized, I still have a differnt browser installed.
> 
> Yes, mozilla.org build crashed too.

Then can you post a crashreport ID from about:crashes from that build? Does the crash happen on a fresh profile?

Comment 6

[Bodo Thiesen]

> Then can you post a crashreport ID from about:crashes from that build?

Mozilla gives me:

The address isn’t valid

The URL is not valid and cannot be loaded.

    Web addresses are usually written like http://www.example.com/
    Make sure that you’re using forward slashes (i.e. /).

> Does the crash happen on a fresh profile?

From my initial report:

| Steps to reproduce:
| 
| Create new user account, start firefox.

In the mean time, I figured out, that accessing mozilla.org triggers the bug (see above) and is independent from profile (happens in main profile and in new user account).

Comment 7

[Bodo Thiesen]

Sorry, just tried 48.0.1 (had 49.0 running, and about:crashes error comes from there):

| Gesendete Absturzberichte
| 
| Es wurden noch keine Absturzberichte versendet.

(no crash reports have been sent yet.)

Comment 8

[:Gijs (he/him)]

(In reply to Bodo Thiesen from comment #7)
> Sorry, just tried 48.0.1 (had 49.0 running, and about:crashes error comes
> from there):
> 
> | Gesendete Absturzberichte
> | 
> | Es wurden noch keine Absturzberichte versendet.
> 
> (no crash reports have been sent yet.)

So, I'm confused, the official mozilla.org build crashed but no crash reports were sent? Have you disabled crash reports in about:preferences#advanced under "Data Choices" ? Can you enable it and produce a crash report with the official build?

Comment 9

[Bodo Thiesen]

On Gentoo bug tracker (https://bugs.gentoo.org/show_bug.cgi?id=594710), Torsten Kaiser pointed out, that this issue might be a DUP of: https://bugzilla.mozilla.org/show_bug.cgi?id=757366

As of the missing crash report, at this moment I'm not perfectly sure, that I actually tested the moz.org build (I thought I did, but now I double checked it and I can't reproduce the bug with moz.org build any longer).

So, it may very well be a Gentoo specific issue.

I'm compiling with gcc 4.9.3, from .comment section of the ELF, I susprect, that gcc 4.4.6 and gcc 4.8.5 was used in building. Going to recompile using 4.8.5 I'll report back here once I know, whether this fixes the issue.