294879 - Firefox crashes when printing on CUPS printer [@ libfreetype.so.6 + 0xe2de] [@ nsFontMetricsPS::~nsFontMetricsPS]

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Christophe Jacquet]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050517 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050517 Firefox/1.0+

When printing to a CUPS printer, Firefox shows the progress dialog and then
crashes. Note that the document gets printed anyway.

This seems to be reproducible for any web page (even for about:blank).

Reproducible: Always

Steps to Reproduce:
1. Open a web page
2. Choose File > Print
3. Select a CUPS printer and click "Print"

Actual Results:  
Firefox shows the progress dialog and crashes, but the document gets printed anyway.

Expected Results:  
Firefox should not crash.

I'm using a Linux Gentoo distribution.

Comment 1

[Anders Conbere]

WFM

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Firefox/1.0.4

Comment 2

[Christophe Jacquet]

WFM with Firefox 1.0.x too.

I forgot to mention that the problem arises with TRUNK builds.

Another precision: I'm using CUPS 1.1.20.

Comment 3

[Christophe Jacquet]

Update: I can reproduce the same behaviour with "Postscript/Default" too.

Comment 4

[Kenneth Herron]

The printing code in Firefox 1.0.x has significant differences from the trunk.
It's not surprising that they'd behave differently.

I don't see any likely crash reports in talkback-public. Christophe, could you
try to reproduce this with a current mozilla.org trunk build? If this is
specific to the gentoo firefox distribution, then you should report it to them
first.

Alternately, could you try to get a stack trace and attach it to this bug?

Comment 5

[Christophe Jacquet]

The bug still arises with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050522 Firefox/1.0+

I had Talkback report a stack trace with ID TB6054113K
(http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6054113K).

Comment 6

[timeless]

Incident ID: 6054113
Stack Signature	libc.so.6 + 0x63210 (0xb7596210) 4efb1eff
Product ID	FirefoxTrunk
Build ID	2005052214
Trigger Time	2005-05-22 23:51:36.0
Platform	LinuxIntel
Operating System	Linux 2.6.10
Module	libc.so.6 + (00063210)
URL visited	http://www.mozilla.org/projects/deerpark/
User Comments	I tried to print a page and Firefox crashed.
Since Last Crash	0 sec
Total Uptime	0 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	N/A
Stack Trace 	
libc.so.6 + 0x63210 (0xb7596210)
libc.so.6 + 0x630aa (0xb75960aa)
libc.so.6 + 0x61d8f (0xb7594d8f)
libfreetype.so.6 + 0xe2de (0xb77782de)
nsFontMetricsPS::~nsFontMetricsPS() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/gfx/src/ps/nsFontMetricsPS.cpp,
line 106]
nsFontMetricsPS::Release() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/gfx/src/ps/nsFontMetricsPS.cpp,
line 135]
nsFontCache::Flush() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/gfx/src/nsDeviceContext.cpp,
line 728]
nsFontCache::~nsFontCache() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/gfx/src/nsDeviceContext.cpp,
line 593]
nsFontCachePS::~nsFontCachePS()
DeviceContextImpl::~DeviceContextImpl() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/gfx/src/nsDeviceContext.cpp,
line 89]
nsDeviceContextPS::~nsDeviceContextPS() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/gfx/src/ps/nsDeviceContextPS.cpp,
line 102]
DeviceContextImpl::Release() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/gfx/src/nsDeviceContext.cpp,
line 54]
nsCOMPtr_base::~nsCOMPtr_base() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/build/nsCOMPtr.cpp,
line 81]
nsPrintData::~nsPrintData() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/layout/printing/nsPrintData.cpp,
line 160]
nsPrintEngine::Destroy() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/layout/printing/nsPrintEngine.cpp,
line 282]
DocumentViewerImpl::OnDonePrinting() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/layout/base/nsDocumentViewer.cpp,
line 4035]
HandlePLEvent() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/layout/printing/nsPrintEngine.cpp,
line 4573]
PL_HandleEvent() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/plevent.c,
line 699]
PL_ProcessPendingEvents() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/plevent.c,
line 633]
nsEventQueueImpl::ProcessPendingEvents() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/nsEventQueue.cpp,
line 421]
event_processor_callback() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 67]

Comment 7

[Christophe Jacquet]

I could test this build on Ubuntu 2005.04, and it does not crash. Maybe it is a
bug in libfreetype (version 2.1.5 on my Gentoo distribution, 2.1.7 on my Ubuntu
distribution) and it is not directly Firefox's fault.

Comment 8

[mrsteven]

It also crashes with freetype 2.1.9 on Gentoo Linux, so I think it is a bug in
firefox. Disabling font.Freetype2.printing in about:config helps.

Comment 9

[Christophe Jacquet]

(In reply to comment #8)
> It also crashes with freetype 2.1.9 on Gentoo Linux, so I think it is a bug in
> firefox. Disabling font.Freetype2.printing in about:config helps.

Confirming all this.

Comment 10

[Felix Braun]

I'm another Gentoo-user that observes the same behaviour (including the work
around by disabling freetype2 for printing) on Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.7.10) Gecko/20050722 Firefox/1.0.6 which I compiled myself. My
system uses freetype-2.1.10.

Note that the Gentoo-bug (http://bugs.gentoo.org/show_bug.cgi?id=72902) seems to
indicate that official Firefox builds downloaded form mozilla.org do not exhibit
this problem. I haven't verified this though.

When printing into a file with freetype2 enabled, one part of the print file has
already been saved when firefox crashes. I will attach this partial print output
soon.

Comment 11

[Felix Braun]

Attachment: partial printout of "about:" with freetype2 printing enabled

Comment 12

[Adam Guthrie]

*** Bug 352840 has been marked as a duplicate of this bug. ***

Comment 13

[Bob Lord]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060916 BonEcho/2.0

I see that this bug report's Version is set to Trunk, but I see this crash on FF2.0 daily builds.

Severity -> Blocker

Comment 14

[Bob Lord]

Still seeing this crash.  Is someone working on it?

Comment 15

[Vladimir Lushnikov]

Can confirm this fully.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060918 Firefox/2.0 (built and checked out sometime at Mon Sep 18 22:50 2006)

OS: Gentoo Linux 2006.1 (2.6.17-gentoo-r8, gcc-4.1.1, glibc-2.4, freetype-2.1.10-r2)

Comment 16

[Stuart Parmenter]

-> 1.8 branch since we don't use any of the code in the stacks on the trunk anymore.

Comment 17

[Mike Schroepfer]

This doesn't meet the criteria for an RC2:

http://developer.mozilla.org/devnews/index.php/2006/09/15/mozilla-18-branch-closed-for-firefox-2-release-candidate-1/

If you get patch we can fix in a follow-on release.

Comment 18

[Bob Lord]

Does that mean FF2 will ship with this serious regression?

Crash on print would seem to be a show-stopper.

Comment 19

[timeless]

we crash on printing or print preview on windows all the time :), i don't see why linux is special ;-)

Comment 20

[Vladimir Lushnikov]

The problem is, a few days before 18th September, it didn't crash.

Comment 21

[Bob Lord]

(In reply to comment #19)
> we crash on printing or print preview on windows all the time :), i don't see
> why linux is special ;-)

I haven't seen a crash on Windows. 

This regression *will* be fixed for FF2.0, right???

Comment 22

[Vladimir Lushnikov]

I've just re-installed Gentoo from scratch, and this still seems to be happening.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060923 Firefox/2.0

The source code was checked out roundabout 13:00 GMT today.

Here is the relevant output of the command line (if needed, I can probably recompile with debug symbols if someone tells me how)

---

Program /usr/lib/mozilla-firefox/firefox-bin (pid = 4297) received signal 11.
Stack:
nsProfileLock::FatalSignalHandler(int)+0x00000080 [/usr/lib/mozilla-firefox/firefox-bin +0x0001F240]
__kernel_sigreturn+0x00000000 [ +0x00000420]
nsFontMetricsPS::~nsFontMetricsPS()+0x00000090 [/usr/lib/mozilla-firefox/components/libgfxps.so +0x00013090]
UNKNOWN [/usr/lib/mozilla-firefox/components/libgfxps.so +0x00011CD4]
nsFontCache::Flush()+0x00000045 [/usr/lib/mozilla-firefox/libgkgfx.so +0x0000F885]
nsFontCache::~nsFontCache()+0x0000004B [/usr/lib/mozilla-firefox/libgkgfx.so +0x0000FA1B]
nsFontCachePS::~nsFontCachePS()+0x0000002D [/usr/lib/mozilla-firefox/components/libgfxps.so +0x0000F0ED]
DeviceContextImpl::~DeviceContextImpl()+0x00000088 [/usr/lib/mozilla-firefox/libgkgfx.so +0x00010688]
nsDeviceContextPS::~nsDeviceContextPS()+0x000001B7 [/usr/lib/mozilla-firefox/components/libgfxps.so +0x0000EEB7]
DeviceContextImpl::Release()+0x00000087 [/usr/lib/mozilla-firefox/libgkgfx.so +0x0000F807]
UNKNOWN [/usr/lib/mozilla-firefox/components/libgfxps.so +0x0000DD6D]
nsPrintData::~nsPrintData()+0x0000034F [/usr/lib/mozilla-firefox/components/libgklayout.so +0x003FC31F]
nsPrintEngine::Destroy()+0x000000CF [/usr/lib/mozilla-firefox/components/libgklayout.so +0x003EDDAF]
DocumentViewerImpl::OnDonePrinting()+0x00000153 [/usr/lib/mozilla-firefox/components/libgklayout.so +0x00234803]
HandlePLEvent(PLEvent*)+0x0000002B [/usr/lib/mozilla-firefox/components/libgklayout.so +0x003EA9CB]
PL_HandleEvent+0x0000004C [/usr/lib/mozilla-firefox/libxpcom_core.so +0x000B5C5C]
PL_ProcessPendingEvents+0x000000A5 [/usr/lib/mozilla-firefox/libxpcom_core.so +0x000B6045]
UNKNOWN [/usr/lib/mozilla-firefox/libxpcom_core.so +0x000B9454]
UNKNOWN [/usr/lib/mozilla-firefox/components/libwidget_gtk2.so +0x00022575]
UNKNOWN [/usr/lib/libglib-2.0.so.0 +0x00054E0F]
g_main_context_dispatch+0x00000181 [/usr/lib/libglib-2.0.so.0 +0x0002B851]
UNKNOWN [/usr/lib/libglib-2.0.so.0 +0x0002E8CF]
g_main_loop_run+0x000001B7 [/usr/lib/libglib-2.0.so.0 +0x0002EC87]
gtk_main+0x000000C1 [/usr/lib/libgtk-x11-2.0.so.0 +0x0012BAB1]
UNKNOWN [/usr/lib/mozilla-firefox/components/libwidget_gtk2.so +0x00022992]
UNKNOWN [/usr/lib/mozilla-firefox/components/libtoolkitcomps.so +0x0001FB16]
UNKNOWN [/usr/lib/mozilla-firefox/firefox-bin +0x0000D455]
UNKNOWN [/usr/lib/mozilla-firefox/firefox-bin +0x00004E4F]
__libc_start_main+0x000000D8 [/lib/libc.so.6 +0x00015878]

---

Relevant libraries:

freetype 2.1.10-r2
gtk 2.10.3

---

In my opinion, this bug is a show-stopper and should be fixed as soon as possible - e.g. http://bugzilla.gnome.org/show_bug.cgi?id=356632

Comment 23

[Vladimir Lushnikov]

(In reply to comment #22)
> I've just re-installed Gentoo from scratch, and this still seems to be
> happening.

Sorry, another thing to mention that CUPS prints the page (correctly).

Comment 24

[Kai Engert (:KaiE:)]

I just tested using today's Firefox 1.8 branch build
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060925 BonEcho/2.0

I tested both Fedora Core 5 and 6 prerelease, one of both is probably what Bob is using.

I tried to print the about: page on both system
I tried to print to a CUPS printer, but "to file" and direct.
I tried to print to postscript/default to a file.

I confirmed my about:config has font.Freetype2.printing enabled (true).

I never crashed.

Comment 25

[Andrew Schultz]

this doesn't block development

> Here is the relevant output of the command line (if needed, I can probably
> recompile with debug symbols if someone tells me how)

You can get debug symbols by compiling with --enable-debug and without --enable-strip.  The fact that you got the stack on the commandline suggests you already compiled with --enable-debug and without --enable-strip.  You probably just need to attach gdb after the crash (there's a line that says this after the stack).  Execute the "bt" command once you're in gdb to get a stacktrace with symbols (add the output as an attachment (Create a New Attachment).  However it looks like you're getting a double-free, so gdb probably won't be all that much help.  You might try using valgrind instead.

(install valgrind)
[path_to_firefox]/run-mozilla.sh /usr/bin/valgrind --tool=memcheck --log-file=valgrind.log [path_to_firefox]/firefox-bin

Comment 26

[Vladimir Lushnikov]

Recompiled with debug USE flag. Trunk build as usual. Around 23:00 GMT

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060925 Firefox/2.0

Running firefox on command line and printing:

Program /usr/lib/mozilla-firefox/firefox-bin (pid = 30995) received signal 11.
Stack:
nsProfileLock::FatalSignalHandler(int)+0x00000080 [/usr/lib/mozilla-firefox/firefox-bin +0x0001F250]
__kernel_sigreturn+0x00000000 [ +0x00000420]
nsFontMetricsPS::~nsFontMetricsPS()+0x00000090 [/usr/lib/mozilla-firefox/components/libgfxps.so +0x000130A0]
UNKNOWN [/usr/lib/mozilla-firefox/components/libgfxps.so +0x00011CE4]
nsFontCache::Flush()+0x00000045 [/usr/lib/mozilla-firefox/libgkgfx.so +0x0000F8A5]
nsFontCache::~nsFontCache()+0x0000004B [/usr/lib/mozilla-firefox/libgkgfx.so +0x0000FA3B]
nsFontCachePS::~nsFontCachePS()+0x0000002D [/usr/lib/mozilla-firefox/components/libgfxps.so +0x0000F0FD]
DeviceContextImpl::~DeviceContextImpl()+0x00000088 [/usr/lib/mozilla-firefox/libgkgfx.so +0x000106A8]
nsDeviceContextPS::~nsDeviceContextPS()+0x000001B7 [/usr/lib/mozilla-firefox/components/libgfxps.so +0x0000EEC7]
DeviceContextImpl::Release()+0x00000087 [/usr/lib/mozilla-firefox/libgkgfx.so +0x0000F827]
UNKNOWN [/usr/lib/mozilla-firefox/components/libgfxps.so +0x0000DD7D]
nsPrintData::~nsPrintData()+0x0000034F [/usr/lib/mozilla-firefox/components/libgklayout.so +0x003FC36F]
nsPrintEngine::Destroy()+0x000000CF [/usr/lib/mozilla-firefox/components/libgklayout.so +0x003EDDFF]
DocumentViewerImpl::OnDonePrinting()+0x00000153 [/usr/lib/mozilla-firefox/components/libgklayout.so +0x00234853]
HandlePLEvent(PLEvent*)+0x0000002B [/usr/lib/mozilla-firefox/components/libgklayout.so +0x003EAA1B]
PL_HandleEvent+0x0000004C [/usr/lib/mozilla-firefox/libxpcom_core.so +0x000B5C7C]
PL_ProcessPendingEvents+0x000000A5 [/usr/lib/mozilla-firefox/libxpcom_core.so +0x000B6065]
UNKNOWN [/usr/lib/mozilla-firefox/libxpcom_core.so +0x000B9474]
UNKNOWN [/usr/lib/mozilla-firefox/components/libwidget_gtk2.so +0x00022585]
UNKNOWN [/usr/lib/libglib-2.0.so.0 +0x00054E0F]
g_main_context_dispatch+0x00000181 [/usr/lib/libglib-2.0.so.0 +0x0002B851]
UNKNOWN [/usr/lib/libglib-2.0.so.0 +0x0002E8CF]
g_main_loop_run+0x000001B7 [/usr/lib/libglib-2.0.so.0 +0x0002EC87]
gtk_main+0x000000C1 [/usr/lib/libgtk-x11-2.0.so.0 +0x0012BAB1]
UNKNOWN [/usr/lib/mozilla-firefox/components/libwidget_gtk2.so +0x000229A2]
UNKNOWN [/usr/lib/mozilla-firefox/components/libtoolkitcomps.so +0x0001FB26]
UNKNOWN [/usr/lib/mozilla-firefox/firefox-bin +0x0000D465]
UNKNOWN [/usr/lib/mozilla-firefox/firefox-bin +0x00004E5F]
__libc_start_main+0x000000D8 [/lib/libc.so.6 +0x00015878]

And then running gdb and bk:

gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7579446 in nanosleep () from /lib/libc.so.6
#2  0xb757926b in sleep () from /lib/libc.so.6
#3  0x0806689a in ah_crap_handler ()
#4  0x08067250 in nsProfileLock::FatalSignalHandler ()
#5  <signal handler called>
#6  0xb74d0aa7 in FcCharSetDestroy () from /usr/lib/libfontconfig.so.1
#7  0xadf940a0 in nsFontMetricsPS::~nsFontMetricsPS () from /usr/lib/mozilla-firefox/components/libgfxps.so
#8  0xadf92ce4 in nsFontPSXft::DrawString () from /usr/lib/mozilla-firefox/components/libgfxps.so
#9  0xb6e508a5 in nsFontCache::Flush () from /usr/lib/mozilla-firefox/libgkgfx.so
#10 0xb6e50a3b in nsFontCache::~nsFontCache () from /usr/lib/mozilla-firefox/libgkgfx.so
#11 0xadf900fd in nsFontCachePS::~nsFontCachePS () from /usr/lib/mozilla-firefox/components/libgfxps.so
#12 0xb6e516a8 in DeviceContextImpl::~DeviceContextImpl () from /usr/lib/mozilla-firefox/libgkgfx.so
#13 0xadf8fec7 in nsDeviceContextPS::~nsDeviceContextPS () from /usr/lib/mozilla-firefox/components/libgfxps.so
#14 0xb6e50827 in DeviceContextImpl::Release () from /usr/lib/mozilla-firefox/libgkgfx.so
#15 0xadf8ed7d in nsFontCachePS::CreateFontMetricsInstance () from /usr/lib/mozilla-firefox/components/libgfxps.so
#16 0xb540436f in nsPrintData::~nsPrintData () from /usr/lib/mozilla-firefox/components/libgklayout.so
#17 0xb53f5dff in nsPrintEngine::Destroy () from /usr/lib/mozilla-firefox/components/libgklayout.so
#18 0xb523c853 in DocumentViewerImpl::OnDonePrinting () from /usr/lib/mozilla-firefox/components/libgklayout.so
#19 0xb53f2a1b in HandlePLEvent () from /usr/lib/mozilla-firefox/components/libgklayout.so
#20 0xb7e9bc7c in PL_HandleEvent () from /usr/lib/mozilla-firefox/libxpcom_core.so
#21 0xb7e9c065 in PL_ProcessPendingEvents () from /usr/lib/mozilla-firefox/libxpcom_core.so
#22 0xb7e9f474 in nsEventQueueImpl::CheckForDeactivation () from /usr/lib/mozilla-firefox/libxpcom_core.so
#23 0xb6585585 in nsCOMPtr<nsITimer>::assign_from_helper () from /usr/lib/mozilla-firefox/components/libwidget_gtk2.so
#24 0xb785fe0f in g_io_channel_unix_get_fd () from /usr/lib/libglib-2.0.so.0
#25 0xb7836851 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#26 0xb78398cf in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#27 0xb7839c87 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#28 0xb7b5dab1 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#29 0xb65859a2 in nsAppShell::ReleaseGlobals () from /usr/lib/mozilla-firefox/components/libwidget_gtk2.so
#30 0xb6438b26 in nsAppStartup::AttemptingQuit () from /usr/lib/mozilla-firefox/components/libtoolkitcomps.so
#31 0x08055465 in ?? ()
#32 0x081b4270 in ?? ()
#33 0x08067fd0 in _IO_stdin_used ()
#34 0x00000000 in ?? ()


I'm surprised by two things. First, why is it calling profile lock? And secondly, what's the ah_crap_handler? :P

The same appears on a clean profile folder.

Comment 27

[timeless]

geckos have profiles, and they don't want second processes touching the files in their profiles, because if something did, they'd get data corruption. they do this by creating a file (the profile lock file). but how do you know that a profile is really locked/in use? what happens if it crashes? well, if it crashes, you hope that somehow the lock doesn't stick around, otherwise your app would refuse to use the profile. the way to do this is to install a signal handler (called ah_crap_handler) which responds to crashes, what it does is kill the lock and reraise the signal. the result is that you can debug the crash and if you don't, there's no lock, so you can use the profile the next time you run the application.

Comment 28

[Vladimir Lushnikov]

Attachment: Valgrind log on 20060925 firefox

The valgrind log on firefox as suggested.

Comment 29

[Vladimir Lushnikov]

Attachment: Output of command line on Firefox 20060925

Output of command line - not sure if needed but...

Comment 30

[Vladimir Lushnikov]

(In reply to comment #27)
> geckos have profiles, ... so you can use the profile the next
> time you run the application.
> 

I think I'm stating the obvious - but that seems to be a sub-optimal solution. (Perhaps better OS support for debugging is needed...) I've attached the valgrind log - Firefox ran very slowly!

Comment 31

[Kai Engert (:KaiE:)]

What does it mean when Valgrind says "Invalid read of size 4" ?

The real problem is probably:

==12175==  Address 0xDADB0E8 is 96 bytes inside a block of size 716 free'd
==12175==    at 0x402118C: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==12175==    by 0x4BA3BCC: (within /usr/lib/libfreetype.so.6.3.8)
==12175==    by 0x4BA3FE9: ft_mem_free (in /usr/lib/libfreetype.so.6.3.8)
==12175==    by 0x4BA7216: (within /usr/lib/libfreetype.so.6.3.8)
==12175==    by 0x4BA72A2: FT_Done_Face (in /usr/lib/libfreetype.so.6.3.8)
==12175==    by 0xDD860D5: nsXftType1Generator::~nsXftType1Generator() (in /usr/lib/mozilla-firefox/components/libgfxps.so)
==12175==    by 0xDD814B4: (within /usr/lib/mozilla-firefox/components/libgfxps.so)
==12175==    by 0x415F8A5: (within /usr/lib/mozilla-firefox/libxpcom_core.so)
==12175==    by 0x414FDCE: PL_DHashTableEnumerate (in /usr/lib/mozilla-firefox/libxpcom_core.so)
==12175==    by 0x415F9C9: nsHashtable::Reset(int (*)(nsHashKey*, void*, void*), void*) (in /usr/lib/mozilla-firefox/libxpcom_core.so)
==12175==    by 0xDD82E43: nsDeviceContextPS::~nsDeviceContextPS() (in /usr/lib/mozilla-firefox/components/libgfxps.so)
==12175==    by 0x57B0826: DeviceContextImpl::Release() (in /usr/lib/mozilla-firefox/libgkgfx.so)

I also saw in the log file that you have a library /usr/lib/libuim.so on your system, which I do not have. I installed the uim package and restarted cups, but still no crash.

Maybe this crash only occurs when some asian-language-input-daemons are installed and running. Those might come by default with Fedora Core, I might have uninstalled or stopped them.

Comment 32

[Andrew Schultz]

Comment on attachment 240166 [details]
Valgrind log on 20060925 firefox

Ah, I just realized you're invoking firefox from the installed location... You'll get a bit more symbol info if you launch firefox from dist/bin in the source tree

Comment 33

[Andrew Schultz]

> What does it mean when Valgrind says "Invalid read of size 4" ?

It means it was trying to read memory it shouldn't have.  Either because it was reading past the end of the chunk of allocated memory, because the memory was already freed or because the address did not correspond to any allocated memory (one of each of those in the log :)).

Comment 34

[Vladimir Lushnikov]

(In reply to comment #32)
> (From update of attachment 240166 [details] [edit])
> Ah, I just realized you're invoking firefox from the installed location...
> You'll get a bit more symbol info if you launch firefox from dist/bin in the
> source tree
> 

I'll try that. I forgot to say something - Thunderbird (1_8_BRANCH) does not crash on printing emails. In theory, they use the same code base for printing, no?

Comment 35

[Bob Lord]

(In reply to comment #34)
> I'll try that. I forgot to say something - Thunderbird (1_8_BRANCH) does not
> crash on printing emails. In theory, they use the same code base for printing,
> no?

Thunderbird [version 2 beta 1 (20060926)] crashes for me in the same way.  I filed bug 354353 this morning.

Comment 36

[Vladimir Lushnikov]

(In reply to comment #35)
> (In reply to comment #34)
> > I'll try that. I forgot to say something - Thunderbird (1_8_BRANCH) does not
> > crash on printing emails. In theory, they use the same code base for printing,
> > no?
> 
> Thunderbird [version 2 beta 1 (20060926)] crashes for me in the same way.  I
> filed bug 354353 this morning.
> 

version 2 beta 1 (20060923) does not crash for me... I'm reluctant to update now - but will try to confirm with latest.

Comment 37

[Alexander Sack]

this bug is due to wrong reference handling in mozilla code. You destroy a resource in destructor that you don't have a reference on. Old fontconfig lib did not remove resources that had no reference. New fontconfig does.

As fontconfig reference semantics are messy, this is understandable ... will attach a patch.

Comment 38

[Alexander Sack]

Attachment: Patch v1

Comment 39

[timeless]

Comment on attachment 240320 [details] [diff] [review]
Patch v1

please please use cvs diff.

this patch is wrong, it will leak fc_charset when new nsXftEntry(set->fonts[i]); fails 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/src/ps/nsFontMetricsPS.cpp&rev=1.60&mark=985,989-991,995#964

since you're here, you should probably fix the oom crash here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/src/ps/nsFontMetricsPS.cpp&rev=1.60&mark=993,994#964

(be sure not to leak xftEntry if new fontps fails :)

fwiw http://209.85.129.104/search?q=cache:Nm_Xrb__YvkJ:www.fontconfig.org/fontconfig-devel/r527.html+FcPatternGetCharSet&hl=en&ct=clnk&cd=7&client=firefox-a does indeed confirm that it's not a reference we own.

for technical bonus points, fpi.fontps->AppendElement can fail, at which point you're responsible for cleaning up the object that you didn't manage to get into the array :).

personally i'd consider only addrefing after i've done all the other creations that might fail, but, that's just me (either way you have n things that you need to clean up y ways).

Comment 40

[timeless]

since asac basically volunteered to touch this function, i think perhaps we should try to make it mostly correct so we don't have to revisit it later.

864/867 kinda scare me
i think all early returns after 867 from this function are very dangerous.

personally i don't like marking something as initialized until i'm actually done initializing it.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/src/ps/nsFontMetricsPS.cpp&rev=1.60&mark=820,864-867,875,889,900,922,925,931,946,949,952,855#850

I really don't understand 820,864-867 at all. i've tried a couple of times to figure it out, there's a while loop 829/1004, but afaik you can only run  833-853 twice and 869 once. so i think refactoring 833-853 as a function might mean you could get rid of the file loop and replace it with two calls to the refactored code.

875 probably counts as buggy since you crash on line 889
900 should probably be written w/ .AssignLiteral()
922 has an extra ; for good measure or no good measure
i presume  NS_AddFFRE on 925 and  NS_AddLangGroup on 931 can fail
also 936, 946,
http://www.fontconfig.org/fontconfig-devel/r422.html
doesn't explicitly say it, but i bet FcBool means that FcPatternAddInteger on 949, 952 can fail

http://www.fontconfig.org/fontconfig-devel/r2057.html similarly for FcConfigSubstitute on 955

biggest nit, line 855, it'd be nice if you would rewrite the comment in English.

Comment 41

[Adam Guthrie]

I think we might need to fix nsFontMetricsXft.cpp, too, according to the stack in bug 354353.

Comment 42

[Kai Engert (:KaiE:)]

I'm now able to reproduce this crash, on Fedora Core 6 prerelease, using Firefox 2 latest nightly, printing a complex page. (I don't crash printing the about page)

Comment 43

[Kai Engert (:KaiE:)]

I have renamed the attachment "a fix for this" and gave it the new name "Patch v1".

As I said in comment 42, I am now able to reproduce the crash.

@Alexander: Thanks a lot for your patch. It fixes the crash for me!


So, we have a working fix for a crash, but when timeless looked at it, he concludes this introduces a memory leak.
Timeless at the same time made several other proposal on how the related code could be improved.


IMHO, as a first step of action, we should attempt to produce a good fix for the crasher, in order to get it into FF 2 as soon as possible.

I'm happy to add another two lines of code so that we don't introduce a new leak.


I propose that timeless' code improvement requests should be addressed in a separate bug - or at least a separate patch and delayed until the crash is fixed.

Comment 44

[Alexander Sack]

(In reply to comment #43)
> I have renamed the attachment "a fix for this" and gave it the new name "Patch
> v1".
> 
> As I said in comment 42, I am now able to reproduce the crash.
> 
> @Alexander: Thanks a lot for your patch. It fixes the crash for me!
> 
> 
> So, we have a working fix for a crash, but when timeless looked at it, he
> concludes this introduces a memory leak.
> Timeless at the same time made several other proposal on how the related code
> could be improved.
> 
> 
> IMHO, as a first step of action, we should attempt to produce a good fix for
> the crasher, in order to get it into FF 2 as soon as possible.
> 
> I'm happy to add another two lines of code so that we don't introduce a new
> leak.
> 
> 
> I propose that timeless' code improvement requests should be addressed in a
> separate bug - or at least a separate patch and delayed until the crash is
> fixed.
> 

I would be happy to improve this patch to "just fix the crash" and remove potential leaks ... for the other improvements suggested by timeless, I just won't be able to get to it until mid nov, as I will go on back-packing tour soon.

Opening a new bug for them is a good idea imo.

As I said on IRC, I don't see that this fix introduces a NEW memory leak. The point is that in old fontconfig lib the font resources were *never* freed at all. The destroy call in destructor was just uneffective. 

So to summarize ... the total sum of memory leaked will always be smaller with this patch + new fontconfig than without patch + old fontconfig.

However, I will try to take a look how we can prevent the error case to leak here.

Comment 45

[Kai Engert (:KaiE:)]

Attachment: (postponed) Patch v2

This patch changes the patch to not introduce a new leak, it addresses several of timeless' proposals from comment 39.

Timeless, are you willing not to veto this patch?

Comment 46

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

If you want something in for Firefox 2, you're probably better off with just Patch v1.

But Patch v2 really doesn't address many of the issues, including the leaks.

(Is FcCharSetCopy guaranteed to return its argument?  Its current implementation always does.  If so, why bother checking for null?)

Comment 47

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 240320 [details] [diff] [review]
Patch v1

r=dbaron.  I think we should get this in ASAP and address the other issues soon.

Comment 48

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(And note that in reality this doesn't introduce any new leaks, even on out-of-memory, since FcCharSetCopy is just a reference counting function.)

Comment 49

[Kai Engert (:KaiE:)]

Comment on attachment 240320 [details] [diff] [review]
Patch v1

Based on dbaron's recommendation I'm removing the obsolete flag on this patch. I support the idea to get this patch in.

Comment 50

[Kai Engert (:KaiE:)]

(In reply to comment #16)
> -> 1.8 branch since we don't use any of the code in the stacks on the trunk
> anymore.

Stuart, the patch applies cleanly to current trunk - I conclude the patch makes sense for the trunk as well.

Comment 51

[Mike Schroepfer]

Comment on attachment 240320 [details] [diff] [review]
Patch v1

Sorry - this is too late for FF2...

Comment 52

[Alexander Sack]

Comment on attachment 240320 [details] [diff] [review]
Patch v1

Please consider for next 1.8.0 branch release, as this makes printing with xft impossible.

Comment 53

[Mike Hommey [:glandium]]

(In reply to comment #51)
> (From update of attachment 240320 [details] [diff] [review] [edit])
> Sorry - this is too late for FF2...
> 

Too late to fix a crasher in firefox 2 ? What kind of QA is this ?

Comment 54

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 240320 [details] [diff] [review]
Patch v1

I'm going to approve this for 1.8.1, since:
 * this code affects Unix printing only
 * it's just an increment of a reference count on an object known not to be null

Comment 55

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checked in to trunk and MOZILLA_1_8_BRANCH.

Comment 56

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(I'd file a followup bug on the issues timeless raised, but I really doubt anybody will care about leak-on-out-of-memory issues in code that's 1.8-branch-only.)

Comment 57

[Bob Lord]

It works!  Thanks so much!!!

Comment 58

[Daniel Veditz [:dveditz]]

Comment on attachment 240320 [details] [diff] [review]
Patch v1

approved for 1.8.0 branch, a=dveditz for drivers.

(it'd be nice if people didn't wait until right before a major release to ram through fixes for their year-old pet peeves. Not that I'm not happy there's a fix, but why not fix it six months ago?)

Comment 59

[Alexander Sack]

(In reply to comment #58)
> (From update of attachment 240320 [details] [diff] [review] [edit])
> approved for 1.8.0 branch, a=dveditz for drivers.
> 
> (it'd be nice if people didn't wait until right before a major release to ram
> through fixes for their year-old pet peeves. Not that I'm not happy there's a
> fix, but why not fix it six months ago?)
> 

Because we ran into this bug not before 2 weeks ago. Sorry.

Comment 60

[Daniel Veditz [:dveditz]]

Fix checked into MOZILLA_1_8_0_BRANCH

Comment 61

[Jay Patel [:jay]]

If someone seeing this on the 1.8.0 branch can verify this fix with a recent nightly, please do and replace the fixed1.8.0.8 keyword with verified1.8.0.8.  Thanks!

Comment 62

[Behdad Esfahbod]

*** Bug 357859 has been marked as a duplicate of this bug. ***

Comment 63

[Andrew Schultz]

The same stack (comment 6) is appearing in bug 335353.  Were there lingering issues here?

Comment 64

[Kenneth Herron]

(In reply to comment #63)
> The same stack (comment 6) is appearing in bug 335353.  Were there lingering
> issues here?

Talkback ID TB25059278Z referenced in bug 335353 comment 3 is from a copy of FF 1.5 with a build ID of 2006090918. That's before the patch for this bug was checked in.

Comment 65

[Adam Guthrie]

*** Bug 335353 has been marked as a duplicate of this bug. ***

Comment 66

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 336435 has been marked as a duplicate of this bug. ***