670080 - Crash on Google searching for ¯\_(ツ)_/¯

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, defect)

Description

[Justin Dolske [:Dolske]]

Attachment: Screenshot of the search suggestion involved in crash

So I ran across this new emoticon on reddit that looked neat -- ¯\_(ツ)_/¯

I was curious about its origins, so went to Google it. And my browser crashed. "Weird, oh well," I shrugged, exactly like the emoticon. Restarted browser, Googled it again, crashed. Uh-oh.

Oddly I'm not getting the Crash Reporter to come up (separate bug?), but I get some useful info from the console output of my a-few-days-old debug build as well as the OS X "This application has unexpectedly exited" thing (with the debug build).

STR
1) Launch browser with clean profile
2) Go to google.com
3) In the search field, enter: ¯\_(ツ)_/¯
4) Press down-arrow to select Google's 1st search suggestion result
5) Crash.

console output:

firefox-bin(3153,0x7fff70dc7cc0) malloc: *** error for object 0x14879b438: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap

OS X crash stack: (partial, will attach the full cut'n'paste):

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib             	0x00007fff87d130b6 __kill + 10
1   libSystem.B.dylib             	0x00007fff87db39f6 abort + 83
2   libSystem.B.dylib             	0x00007fff87da262d szone_error + 519
3   libSystem.B.dylib             	0x00007fff87cc9a46 tiny_malloc_from_free_list + 715
4   libSystem.B.dylib             	0x00007fff87cc8abd szone_malloc_should_clear + 242
5   libSystem.B.dylib             	0x00007fff87cc898a malloc_zone_malloc + 82
6   libSystem.B.dylib             	0x00007fff87cc6c88 malloc + 44
7   XUL                           	0x0000000102912a7b _moz_cairo_font_options_create + 18 (cairo-font-options.c:107)
8   XUL                           	0x000000010281d34b GetRoundOffsetsToPixels(gfxContext*, int*, int*) + 117 (gfxHarfBuzzShaper.cpp:934)
9   XUL                           	0x000000010281d573 gfxHarfBuzzShaper::SetGlyphsFromRun(gfxContext*, gfxTextRun*, _hb_buffer_t*, unsigned int, unsigned int) + 427 (gfxHarfBuzzShaper.cpp:1022)
10  XUL                           	0x000000010281ec47 gfxHarfBuzzShaper::InitTextRun(gfxContext*, gfxTextRun*, unsigned short const*, unsigned int, unsigned int, int) + 2537 (gfxHarfBuzzShaper.cpp:897)
...

This is a debug OS X build from hg changeset 320e5abc6f5a.

Comment 1

[Justin Dolske [:Dolske]]

Attachment: Full OS X "Problem Report"

Comment 2

[Lucas Adamski [:ladamski]]

Coolest.  Bug.  Ever.  Except it doesn't crash for me. ¯\_(ツ)_/¯

Comment 3

[Bob Clary [:bc] (inactive)]

On Mac OS X 10.5 with debug builds from yesterday and this morning I don't crash with or without a new profile and with or without MallocScribble set.

lots of

WARNING: Break suggested inside cluster!: file /work/mozilla/builds/nightly/mozilla/gfx/thebes/gfxFont.cpp, line 3162

followed by several 

WARNING: Ended font run in the middle of a cluster: 'end == aSource->GetLength() || aSource->IsClusterStart(end)', file /work/mozilla/builds/nightly/mozilla/gfx/thebes/gfxFont.cpp, line 4230
WARNING: Started font run in the middle of a cluster: 'aSource->IsClusterStart(start)', file /work/mozilla/builds/nightly/mozilla/gfx/thebes/gfxFont.cpp, line 4228

though.

Comment 4

[Justin Dolske [:Dolske]]

Yeah, I'm getting the same with an updated debug build now.

Comment 5

[Daniel Veditz [:dveditz]]

Do you know how old your previous crashing release build was? The same "few days old" as your debug build? Would be worth looking at the changesets that have landed to see if it makes sense that this stopped crashing.

Comment 6

[Daniel Veditz [:dveditz]]

dolske: if you go back to the build that originally crashed you does it still crash? Since you were able to file this report it's not the mere string ¯\_(ツ)_/¯ so maybe it was something in the page snippets included in the Google search results. Those might have changed since (in which case the rest of us are searching in vain for the crash) or the differences might even be due to search result personalization.

Comment 7

[Daniel Veditz [:dveditz]]

Jonathan: please take a look and let us know if this is still a problem, or even whether the warnings bclary saw are related to the original problem.

Comment 8

[Jonathan Kew [:jfkthame]]

I don't think the warnings are significant; these occur fairly often with "weird" mixtures of Unicode characters, when font-matching tends to pull individual characters from several fonts depending on their exact repertoire.

I haven't been able to reproduce the actual crash here. It's difficult to be sure whether it indicates a bug in our gfx or cairo code (probably not at the exact point of the crash, but an earlier use-after-free error), or a problem in the lower-level Apple font code that's damaging the heap and leading to the malloc crash.

When I put that string into Google, I notice that the first search suggestion is a variant that uses "isolated" combining marks - i.e. diacritics that occur without appropriate base characters to apply to. This shouldn't be a problem per se - we have code specifically to handle this - but it does mean that we're hitting a less-common and more-complex code path when we're handling that string; perhaps the problem relates to this. Jesse already fuzzes a bunch of stuff like this, though, so that doesn't directly lead us to any STR.

I doubt that anything has landed recently that would fix whatever the underlying problem here is, but it's going to be hard to make any progress unless someone can reproduce it with some consistency. dolske, any chance of reproducing with your old build?

Comment 9

[Jonathan Kew [:jfkthame]]

FWIW, I tried a debug build from changeset 320e5abc6f5a (as per comment #0), and ran it with MallocScribble and MallocGuardEdges, but no crash....

Reproducing this could easily be dependent on several variables, including the exact contents of Google's search suggestions (which may change) and other snippets on the page, as well as the particular fonts present on the user's system.

Comment 10

[Daniel Veditz [:dveditz]]

Those were my worries in comment 6, too. Time to close WFM and unhide?

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to comment #10)
> Those were my worries in comment 6, too. Time to close WFM and unhide?

I'd kinda like to hear an update from dolske before we decide anything, if he's had a chance to do any further testing?

Comment 12

[Daniel Veditz [:dveditz]]

Just talked to dolske, he can't reproduce it anymore either.

   ¯\_(ツ)_/¯