[PATCH:libXt 3/3] Convert ALLOCATE_LOCAL + sprintf to XtAsprintf
Cyril Brulebois
kibi at debian.org
Tue Mar 8 03:45:34 PST 2011
Alan Coopersmith <alan.coopersmith at oracle.com> (07/03/2011):
> Perhaps a difference in the setting of $HOME or one of the other
> environment variables that GetRootDirName checks for the homedir?
Indeed, '/' when starting from init, '/root' when starting later as
root. I tried unsetting a few variables (HOME, USER, etc.), but I
couldn't reproduce this behaviour after init; so I configured root's
homedir to be '/', and could reproduce the issue with just running
'xdm'. yay.
> I can't see why that would make XtAsprintf operate any differently
> though.
Now, both XtAsprintf and asprintf return the same path, which is
nice. But I *think* there's some side effect somewhere.
The core left behind says:
| Program terminated with signal 11, Segmentation fault.
| #0 XtOpenDisplay (app=0x0, displayName=0x9a0d788 ":0", applName=0x80660b9 "xlogin",
| className=0x80660b2 "Xlogin", urlist=0x0, num_urs=0, argc=0x8069ef0, argv=0x8067c2c)
| at ../../src/Display.c:313
| 313 UNLOCK_APP(app);
So, one may ask (and Julien did): “WTH would app be NULL as this point?”
The codepath, from XtOpenDisplay is (all of those under src/):
... XtAsprintf or asprintf
Initialize.c: CombineAppUserDefaults
Initialize.c: XtScreenDatabase
Initialize.c: _XtDisplayInitialize
Display.c: XtOpenDisplay
So, let's add a check in Display.c:
| XtOpenDisplay(…) {
| …
| fprintf(stderr, "[before init] app=%p\n", app);
| _XtDisplayInitialize(d, pd, applName, urlist, num_urs, argc, argv);
| fprintf(stderr, "[after init] app=%p\n", app);
| …
| }
(xdm.log has the output.)
And tada!
1. app is non-NULL before calling _XtDisplayInitialize
2. app is non-NULL (and the same value, woot) afterwards, if using
asprintf().
3. app is NULL afterwards, if using XtAsprintf().
KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110308/00ec6c9c/attachment.pgp>
More information about the xorg-devel
mailing list