Opened 3 weeks ago

Closed 7 days ago

#210 closed defect (fixed)

Firefox crashes with fontconfig-2.13.1-2

Reported by: dryeo Owned by:
Priority: Feedback pending Milestone:
Component: fontconfig Version:
Severity: highest Keywords: crash
Cc: dave.r.yeo@…, lgrosenthal@…, steve53@…


I've been getting reports (3 so far) of the Mozilla apps crashing after updating to the latest fontconfig. These are all on eCS or Warp v4 systems. The trp is an INT 3 trap (mozalloc_abort), looking at the memory dumps, I see lines like

0012DE40 : 524F4241 75203A54 6C62616E 6F742065 : ABORT: unable to
 0012DE50 : 6E696620 20612064 62617375 6620656C :  find a usable f
 0012DE60 : 20746E6F 72657328 3A296669 6C696620 : ont (serif): fil
 0012DE70 : 3A442065 6573552F 642F7372 2F6B696D : e D:/Users/dmik/
 0012DE80 : 626D7072 646C6975 4955422F 6D2F444C : rpmbuild/BUILD/m
 0012DE90 : 6C697A6F 6F2D616C 462D3273 46455249 : ozilla-os2-FIREF
 0012DEA0 : 345F584F 5F395F35 72736530 4C45525F : OX_45_9_0esr_REL
 0012DEB0 : 45534145 32534F5F 3241475F 7866672F : EASE_OS2_GA2/gfx
 0012DEC0 : 6568742F 2F736562 54786667 52747865 : /thebes/gfxTextR
 0012DED0 : 632E6E75 202C7070 656E696C 36383120 : un.cpp, line 186

With fc-match.exe serif outputting

K:\usr\bin>fc-match serif
DejaVuSerif.ttf: "DejaVu Serif" "Book

I can reproduce this by editing fonts.conf to only point to an eCS install x:\psfonts.
Firefox etc works fine on an AOS install where I get

K:\etc\fonts>fc-match serif
verase.ttf: "Bitstream Vera Serif" "Roman"

Attachments (6)

0073_01.TRP (88.4 KB) - added by dwgras 3 weeks ago.
005B_01.TRP (167.6 KB) - added by dryeo 3 weeks ago.
0179_01.TRP (58.2 KB) - added by haraldkamm 3 weeks ago.
1332_01.TRP (63.7 KB) - added by haraldkamm 3 weeks ago.
263D_01.TRP (63.3 KB) - added by haraldkamm 2 weeks ago.
Seamonkey 2.35 continues to trap
95E4_01.TRP (100.0 KB) - added by dryeo 13 days ago.
Rebuilt FF trp though FF runs.

Download all attachments as: .zip

Change History (37)

comment:1 Changed 3 weeks ago by diver

when does it crash? when starting ffox or during the session? I ask because I can't reproduce it and some testers can't either. using eCS that is.

comment:2 Changed 3 weeks ago by diver

and a output of fc-cache -f --verbose
but all those needs to be from one of the crashing systems.

comment:3 Changed 3 weeks ago by dryeo

All reports are that the browser will not start. I can't reproduce today, typo? and will ask the users for the output. 2 are on the newsgroup and one on os2world. The os2world user is actually running AOS, need to verify that he rebooted and still had the crash.

comment:4 Changed 3 weeks ago by diver

As usually they have to install the debug files for Mozilla and fontconfig, let it trap and attach the trp file. This might lead to something. And yes after s update a reboot is most probably need. As fontconfig is locked mostly.

Changed 3 weeks ago by dwgras

comment:5 Changed 3 weeks ago by dwgras

fontconfig must not be locked. I do not have to reboot for the version to work or not work. Even after intallaing the latest version and rebooting, FF will not start. It traps. The trap uploaded is 0073_01.trp. Using YUM to install the previous version, FF works fine without a reboot.

I am using ArcaOS 5.03.
David Graser

comment:6 Changed 3 weeks ago by dryeo

Fontconfig will be locked if anything, such as the browser has it open. Doesn't usually matter unless the upgrade changes fonts.conf, which will get updated and may make the older fontconfig unhappy.

comment:7 Changed 3 weeks ago by dryeo

Here's a trp report post by Dave Parsons on the newsgroup. It is against the last Bitwise build of Firefox. There's no need for fontconfig debug package as it doesn't crash, these problems started when updating according to the posts.

Changed 3 weeks ago by dryeo

comment:8 Changed 3 weeks ago by diver

  • Priority changed from major to Feedback pending

this fontconfig release changed a whole lot in fonts.conf. so w/o a reboot it might still use the old dll and read the new fonts.conf, which might lead to anything. So please update fontconfig, reboot and try again. As none of my testers can reproduce it with our firefox I suspect a reboot will fix it.

comment:9 Changed 3 weeks ago by dryeo

David Graser reported on OS2World that after downgrading, upgrading about 4 or 5 times and rebooting inbetween, suddenly Firefox is working for him. Don't think he is cc'ed.
Wonder if on some systems fonts.conf or some of the symlinks don't correctly upgrade.

comment:10 Changed 3 weeks ago by diver

I doubt he rebooted between all his tests. And when he uses the mozturbo thinggy fontconfig is for sure loaded. I tend to mark this case as not reproducable.

Changed 3 weeks ago by haraldkamm

Changed 3 weeks ago by haraldkamm

comment:11 Changed 3 weeks ago by haraldkamm

I surely rebooted between my tests and I don't use the "mozturbo thingy". I have attached two trap-files.

fc-cache doesn't work:

[D:\OS2UTIL\OS2COM]fc-cache -f --verbose 2>&1 | tee out
_um_free_maybe_lock: Tried to free block twice - block=20042960 lock=0x1
pid=0x0197 ppid=0x018e tid=0x0001 slot=0x0107 pri=0x0200 mc=0x0000 ps=0x0010
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

The external process was cancelled by a Ctrl+Break or another process.

The previous fontconfig worked as expected, all the problems appeared after having done the upgrade.


comment:12 Changed 3 weeks ago by diver

You need to install the debug files of fontconfig. And use fc-cache for tests. Is there any popuplog entry. What System do you have? All installed by rpm?

comment:13 Changed 2 weeks ago by lewisr

  • Cc lgrosenthal@… added

comment:14 Changed 2 weeks ago by haraldkamm

The cache file in \var\cache\fontconfig was read-only. I have an updated Warp 4 / eCS system. Everything was installed using rpm. Seamonkey 2.35 continues to trap, 2.42.9 works.

Changed 2 weeks ago by haraldkamm

Seamonkey 2.35 continues to trap

comment:15 Changed 2 weeks ago by haraldkamm

No popuplog entry. Debug files of fontconfig and freetype are installed now.

comment:16 Changed 2 weeks ago by diver

oh when the old seamonkey traps I know why. This is a regression we can't fix. As old seamonkey doesn't use libcx our mmap implementation doesn't work. sorry. you need to use the later seamonkey then.

comment:17 Changed 2 weeks ago by dmik

According to the last TRP this is exactly what Silvan is talking about. Our mmap implementation (used in many Unix libraries we port) requires the exe to be built against the LIBCx import library (-lcx in gcc). No way to make it work otherwise. This basically means that it’s forbidden to use newer DLLs with old software. Look for newer builds of it if you want it to work.

comment:18 Changed 2 weeks ago by diver

if you can't use a later seamonkey try to add "SET FONTCONFIG_USE_MMAP=0" this should work as well

comment:19 Changed 2 weeks ago by diver

this set fontconfig_use_mmap might not solve your issue. as freetype is now also mmap enabled. so all apps build w/o libcx (or old libcx) and using freetype/fontconfig might crash and need a rebuild. how many that are I have no idea.

comment:20 Changed 2 weeks ago by haraldkamm

Thanks for this illumination. I would prefer to use the old Seamonkey, but apparently there is no chance to do so. I don't think that Dave will do a rebuild of Seamonkey 2.35 against the LIBCx import library.

comment:21 Changed 13 days ago by dryeo

@haralkamm, I'm hoping to rebuild SeaMonkey? 2.35

comment:22 Changed 13 days ago by dryeo

So rebuilt FF38.8.0esr_RELEASE_OS2_Beta_7 linking against libcx. mach run fails like

[C:\work\comm-esr-38\mozilla]python mach run
 0:06.88 c:/work/comm-esr-38/mozilla/obj-fb/dist/bin/firefox.exe -no-remote -profile c:/work/comm-esr-38/mozilla/obj-fb/tmp/scratch_user
Couldn't load xul.dll (OS/2 error 2, faulty module: MOZALLOC).

Running from dist/bin after setting BEGINLIBPATH AND LIBPATHSTRICT and mozturbo files unloaded results in the attached trp in freetype and then the browser comes up and seems to run fine. Weird.
BTW, there's a conflict between fontconfig debug package and debuginfo package, debug package was left installed after upgrade.

Changed 13 days ago by dryeo

Rebuilt FF trp though FF runs.

comment:23 Changed 12 days ago by diver

this debug vs debuginfo thinggy is known. This is because we changed names long ago. And the debug package has no Obsoletes tag to the old names. So if old ones are around those have to be removed by hand.

comment:24 Changed 10 days ago by stevenhl

  • Cc steve53@… added

comment:25 Changed 9 days ago by dryeo

The main issue is actually freetype rather then fontconfig, though the new fontconfig needs to be installed with the browser closed and a reboot due to incompatible fonts.conf getting picked up by the DLL in memory.
Another issue with freetype-2.10.0-1 is that it breaks the screensavers cairo modules, it seems to crash and leave the mouse pointer invisible and the preview pane locks the WPS. CairoClock? is a good example of a failing module. It is linked against the Cairo RPM while the screensaver is built with OpenWatcom?.

Today I downloaded freetype-2.10.0-1.oc00.src.rpm and rebuilt the DLL with --disable-mmap and replaced the RPM DLL. This fixed all issues, 38ESR browsers start and run, screensaver displays Cairoclock.
I'd suggest disabling mmap in freetype for now, at least until more stuff is rebuilt with the new libcx.

comment:26 Changed 8 days ago by diver

as a interims fix I will do it soon. But mind you fontconfig also uses mmap. But only if files are larger. It seems we don't have such large files atm.

comment:27 Changed 8 days ago by diver

new rpm uploaded. please test

comment:28 Changed 8 days ago by dryeo

Seems to be working fine here. Firefox 38 runs fine. The screensaver's cairo modules run and look fine.

comment:29 Changed 8 days ago by lewisr

I can confirm that all Mozilla apps shipped with ArcaOS 5.0.3 (FF 38.8, SM 2.35, TB 38.8) start and run fine with freetype-2.10.0-2.

All Cairo-based screensaver modules seem to work fine, as well, with no loss of mouse pointer (Clock, RSS, Shapes).

comment:30 Changed 8 days ago by lewisr

For fontconfig, it appears that setting:


in CONFIG.SYS should disable any attempted use of mmap for the cache files. I do not know if this is the only use for mmap in fontconfig, but it's a pretty good guess that it is.

Source: fonts-conf(5)

Edit: Silvan, I missed your earlier mention of this.

Last edited 8 days ago by lewisr (previous) (diff)

comment:31 Changed 7 days ago by diver

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.