736435 - xulrunner-stub.exe crashes in gfxUserFontSet::OnLoadComplete when using CSS with @font-face

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[poppertd]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

1. Create a XULRunner application that uses @font-face CSS declaration to load a font from a URL.
2. Launch the application using xulrunner-stub.exe


Actual results:

The application crashes on startup.


Expected results:

The application should have started normally and used the applied font.  Launching the same application using xulrunner.exe -app path/to/application.ini works as expected.

Comment 1

[Scoobidiver (away)]

Your are using a version that is no longer maintained. Please update and report back.

Comment 2

[Benjamin Smedberg]

Also you need to be specific: what is the stack trace of the crash? You can a combination of your local debugging symbols and the Mozilla symbol server to debug the process and get a stack trace. https://developer.mozilla.org/En/Using_the_Mozilla_symbol_server

Comment 3

[poppertd]

Attachment: WinDbg Stack Trace

Comment 4

[poppertd]

Scoobidiver, this is a bug filed against XULRunner version 11.

Comment 5

[Scoobidiver (away)]

It seems a dupe of bug 730550 (same stack trace).
Does it happen with Aurora 13 or Nightly?

Comment 6

[poppertd]

It still happens with Aurora 13.0a2 (2012-03-17-04-20-20-mozilla-aurora).

Comment 7

[John Daggett (:jtd)]

I'm guessing this is bug 730550.  The fix there checks for t2embed but it doesn't assure that the proc address of t2embed functions are non-null (if a dummy lib is used for example).

Comment 8

[Scoobidiver (away)]

(In reply to John Daggett (:jtd) from comment #7)
> I'm guessing this is bug 730550.
Bug 730550 is fixed in Aurora 13 while this bug is not fixed in Aurora 13.

Comment 9

[John Daggett (:jtd)]

(In reply to Scoobidiver from comment #8)
> (In reply to John Daggett (:jtd) from comment #7)
> > I'm guessing this is bug 730550.
> Bug 730550 is fixed in Aurora 13 while this bug is not fixed in Aurora 13.

If you look carefully at the fix, it will prevent failure in the case that t2embed.dll is missing but not if it has been replaced by a dummy lib.  The list of dll's includes t2embed.dll and yet the crash occurs.

For anyone that can reproduce this, what is the size/date/version of the t2embed.dll?

I think we probably need to undo the changes that were originally made, such that if the proc pointers are null we fail gracefully.  The better fix would be to remove the dependence on t2embed.dll completely as it's no longer necessary since the sanitizer code rebuilds the font anyways.

Comment 10

[John Daggett (:jtd)]

i.e. undo the font loading code changes for both bug 730550 and bug 699247.

Comment 11

[Masatoshi Kimura [:emk]]

Attachment: Restore GetProcAddress check for t2embed library

This patch is not a simple backout in two ways.
1. Try to load t2embed library only once. Before bug 699247, library load was tried everytime gfxGDIFontList is initialized.
2. Fallback to AddFontMemResourceEx path if t2embed library or functions are unavailable.

Comment 12

[John Daggett (:jtd)]

Comment on attachment 606977 [details] [diff] [review]
Restore GetProcAddress check for t2embed library

r+, with adjustments to line lengths please

Comment 13

[Masatoshi Kimura [:emk]]

Attachment: Restore GetProcAddress check for t2embed library. r=jtd

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d4fa7d697295

Comment 15

[Mounir Lamouri (:mounir)]

https://hg.mozilla.org/mozilla-central/rev/d4fa7d697295

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Is it possible to create an automated test for our testsuite?