Bug 89739

Summary: segfault if !getenv("HOME")
Product: [Retired] Red Hat Linux Reporter: David Woodhouse <dwmw2>
Component: fontconfigAssignee: Owen Taylor <otaylor>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-10 22:15:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
partial fix none

Description David Woodhouse 2003-04-27 11:41:19 UTC 
Description of problem:
Apps segfault if $HOME isn't in the environment, because FcStrCopyFilename calls
strlen() on the result of getenv() before checking it for NULL.

# unset HOME ; /usr/bin/bluepin asd asd
Segmentation fault


Fixing the segfault with the (soon to be) attached patch is only vaguely helpful
-- apps still fail to start...

# unset HOME ;
LD_LIBRARY_PATH=/usr/src/redhat/BUILD/fcpackage.2_1/fontconfig/src
/usr/bin/bluepin asd asd
No fonts found; this probably means that the fontconfig
library is not correctly configured. You may need to
edit the fonts.conf configuration file. More information
about fontconfig can be found in the fontconfig(3) manual
page and on http://fontconfig.org

Setting HOME to a bogus nonexistent directory makes the application work fine;
it's not that the directory is actually required.
Comment 1 David Woodhouse 2003-04-27 11:42:08 UTC 
Created attachment 91316 [details]
partial fix
Comment 2 Owen Taylor 2003-04-27 13:29:00 UTC 
Just out of couriousity - and to know how important a "functional"
fix is, when would programs be running without $HOME in the environment?
Is this a situation when using getpwuid() would work?
Comment 3 David Woodhouse 2003-04-27 13:49:40 UTC 
Not sure how common it'll be -- the example is a GUI dialog box invoked from a
deamon (it's in the bluez-utils package if you want to look closer) and is the
WrongThing anyway -- dbus or whatever will obsolete it soon, hopefully.

If it didn't work with 'HOME=/somebogusdir' and actually _needed_ the home
directory, I'd suggest that it isn't worth fixing. But since it does work like
that, it seems like it might be fairly simple to make it work with !HOME. 

I've worked around it in bluez-utils for now, just by setting HOME to "" in the
bluepin script.
Comment 4 Owen Taylor 2003-06-10 22:15:47 UTC 
Fixed upstream as of 2003/02/06, tests OK with fontconfig-2.2.1-1