Last Comment Bug 736435 - xulrunner-stub.exe crashes in gfxUserFontSet::OnLoadComplete when using CSS with @font-face
: xulrunner-stub.exe crashes in gfxUserFontSet::OnLoadComplete when using CSS w...
Status: RESOLVED FIXED
: crash
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla14
Assigned To: Masatoshi Kimura [:emk]
:
Mentors:
: 739083 (view as bug list)
Depends on: 731894
Blocks: 699247 730550
  Show dependency treegraph
 
Reported: 2012-03-16 04:35 PDT by poppertd
Modified: 2012-11-10 11:15 PST (History)
8 users (show)
ryanvm: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
WinDbg Stack Trace (48.95 KB, text/plain)
2012-03-16 16:52 PDT, poppertd
no flags Details
Restore GetProcAddress check for t2embed library (7.26 KB, patch)
2012-03-18 08:55 PDT, Masatoshi Kimura [:emk]
jd.bugzilla: review+
Details | Diff | Review
Restore GetProcAddress check for t2embed library. r=jtd (7.46 KB, patch)
2012-03-19 07:04 PDT, Masatoshi Kimura [:emk]
VYV03354: review+
Details | Diff | Review

Description poppertd 2012-03-16 04:35:54 PDT
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) 2012-03-16 06:51:45 PDT
Your are using a version that is no longer maintained. Please update and report back.
Comment 2 Benjamin Smedberg [:bsmedberg] 2012-03-16 07:58:09 PDT
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 2012-03-16 16:52:38 PDT
Created attachment 606790 [details]
WinDbg Stack Trace
Comment 4 poppertd 2012-03-16 16:54:27 PDT
Scoobidiver, this is a bug filed against XULRunner version 11.
Comment 5 Scoobidiver (away) 2012-03-16 23:43:53 PDT
It seems a dupe of bug 730550 (same stack trace).
Does it happen with Aurora 13 or Nightly?
Comment 6 poppertd 2012-03-17 16:11:48 PDT
It still happens with Aurora 13.0a2 (2012-03-17-04-20-20-mozilla-aurora).
Comment 7 John Daggett (:jtd) 2012-03-18 04:45:06 PDT
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) 2012-03-18 05:37:25 PDT
(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) 2012-03-18 06:45:09 PDT
(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) 2012-03-18 06:48:04 PDT
i.e. undo the font loading code changes for both bug 730550 and bug 699247.
Comment 11 Masatoshi Kimura [:emk] 2012-03-18 08:55:23 PDT
Created attachment 606977 [details] [diff] [review]
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) 2012-03-18 17:07:28 PDT
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] 2012-03-19 07:04:12 PDT
Created attachment 607147 [details] [diff] [review]
Restore GetProcAddress check for t2embed library. r=jtd
Comment 14 Ryan VanderMeulen [:RyanVM] 2012-03-19 15:54:39 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/d4fa7d697295
Comment 15 Mounir Lamouri (:mounir) 2012-03-20 03:51:00 PDT
https://hg.mozilla.org/mozilla-central/rev/d4fa7d697295
Comment 16 Scoobidiver (away) 2012-03-26 00:33:38 PDT
*** Bug 739083 has been marked as a duplicate of this bug. ***
Comment 17 Ryan VanderMeulen [:RyanVM] 2012-11-10 11:15:16 PST
Is it possible to create an automated test for our testsuite?

Note You need to log in before you can comment on or make changes to this bug.