Opened 6 years ago
Closed 6 years 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@… |
Description
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)
Change History (37)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
and a output of fc-cache -f --verbose
but all those needs to be from one of the crashing systems.
comment:3 by , 6 years ago
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 by , 6 years ago
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.
by , 6 years ago
Attachment: | 0073_01.TRP added |
---|
comment:5 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
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.
by , 6 years ago
Attachment: | 005B_01.TRP added |
---|
comment:8 by , 6 years ago
Priority: | major → 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 by , 6 years ago
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 by , 6 years ago
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.
by , 6 years ago
Attachment: | 0179_01.TRP added |
---|
by , 6 years ago
Attachment: | 1332_01.TRP added |
---|
comment:11 by , 6 years ago
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
D:/OS2/OS2.INI:
LIBC PANIC!!
_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
D:\USR\BIN\FC-CACHE.EXE
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.
Harald
comment:12 by , 6 years ago
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 by , 6 years ago
Cc: | added |
---|
comment:14 by , 6 years ago
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.
comment:15 by , 6 years ago
No popuplog entry. Debug files of fontconfig and freetype are installed now.
comment:16 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
if you can't use a later seamonkey try to add "SET FONTCONFIG_USE_MMAP=0" this should work as well
comment:19 by , 6 years ago
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 by , 6 years ago
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:22 by , 6 years ago
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.
comment:23 by , 6 years ago
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 by , 6 years ago
Cc: | added |
---|
comment:25 by , 6 years ago
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 by , 6 years ago
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:28 by , 6 years ago
Seems to be working fine here. Firefox 38 runs fine. The screensaver's cairo modules run and look fine.
Thanks
comment:29 by , 6 years ago
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 by , 6 years ago
For fontconfig, it appears that setting:
FONTCONFIG_USE_MMAP=0
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.
comment:31 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.