5:59 p.m.
PATCH 21.5
On Thu, May 8, 2014 at 6:41 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
This is the bug. I don't understand how this would happen. All
objects passed to Ffc_* function should be created with one of the
four functions calling fc_config_create_using in font-mgr.c. Perhaps
fontconfig can return NULL in some cases, but it shouldn't unless
maybe there's an ENOMEM in there?
More than that I can't say for a few hours. I'll take a look at the
backtrace and see if I can figure out how such a thing occurred.
Here is what happened. In fc_config_create_using, we wrap the
fc_config object as a Lisp object *twice*. One reference goes onto a
weak list and the other is returned. The next time we garbage
collect, the weak reference is collected, and the finalizer
(finalize_fc_config) is called, which sets fccfgPtr to NULL.
Meanwhile, the strong reference is still live....
The fix is to wrap the fc_config object once and use the same
reference everywhere, like so:
diff -r 2d20d57d4e7b src/ChangeLog
--- a/src/ChangeLog Wed May 07 13:33:50 2014 -0600
+++ b/src/ChangeLog Wed May 14 10:53:21 2014 -0600
＠＠ -1,3 +1,9 ＠＠
+2014-05-14 Jerry James <james(a)xemacs.org>
+
+ * src/font-mgr.c (fc_config_create_using): wrap the fc_config
+ object as a Lisp object only once, so the strong and weak
+ references refer to the same object.
+
2014-01-27 Michael Sperber <mike(a)xemacs.org>
* symbols.c (Fdefine_function): Allow optional `docstring'
diff -r 2d20d57d4e7b src/font-mgr.c
--- a/src/font-mgr.c Wed May 07 13:33:50 2014 -0600
+++ b/src/font-mgr.c Wed May 14 10:53:21 2014 -0600
＠＠ -526,11 +526,13 ＠＠
}
{
+ Lisp_Object cfg;
fc_config *fccfg = XFC_CONFIG (ALLOC_NORMAL_LISP_OBJECT (fc_config));
fccfg->fccfgPtr = fc;
- configs = Fcons (wrap_fc_config (fccfg), configs);
+ cfg = wrap_fc_config (fccfg);
+ configs = Fcons (cfg, configs);
XWEAK_LIST_LIST (Vfc_config_weak_list) = configs;
- return wrap_fc_config (fccfg);
+ return cfg;
}
}
Regards,
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:06 p.m.
On Wed, May 14, 2014 at 10:59 AM, Jerry James <james(a)xemacs.org> wrote:
PATCH 21.5
Well, that was a bunch of nonsense. Ignore this patch. I was
thinking that wrap_foo worked differently than it does. It's
essentially just converting the pointer into an integer, so the two
wrap_fc_config() calls should produce the same value.
Still, it seems likely that garbage collection has something to do
with this, doesn't it? That's the only way I can see the fccfgPtr
field being set to NULL. Maybe we are missing a gcpro somewhere.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:13 p.m.
Jerry James writes:
PATCH 21.5
Thank you!
Here is what happened.
Nice work, Sherlock! Ship it.
In fc_config_create_using, we wrap the fc_config object as a Lisp
object *twice*. One reference goes onto a weak list and the other
is returned.
But these are different objects only in the case of --with-union-type,
right? Was the XEmacs where this happens built that way? In a
--with-union-type=no, wrap_fc_config just casts the pointer to
(Lisp_Object).
This *is* a bug, and your patch does fix that bug. I just want to
make sure there aren't more of them running around.
Unfortunately, we do this all over the place. Eg, in
src/EmacsFrame.c:EmacsFrameSetValues we wrap the same frame object
about 9 times!
Need to sleep, though, so not tonight.... Volunteers?
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:29 p.m.
On Wed, May 14, 2014 at 12:06 PM, Jerry James <james(a)xemacs.org> wrote:
Still, it seems likely that garbage collection has something to do
with this, doesn't it? That's the only way I can see the fccfgPtr
field being set to NULL. Maybe we are missing a gcpro somewhere.
No, I was even more confused than was evident at first. I confused
patterns and configs in my original email. It turns out that this is
a known bug, and it has already been fixed in mercurial. The problem
is that FcNameParse() (called in Ffc_name_parse) can return NULL. But
we check for that now:
if (!fcpat->fcpatPtr)
/* #### Is this the best API? Could return a symbol or similar. */
invalid_argument ("unparseable Fc font name", name);
So I either need to apply the existing patch to the 21.5.34 release
and rebuild for Fedora, or start agitating for a 21.5.35 release. :-)
Hmm, our website claims that 21.5.33 is the latest release.
Side note: the name that FcNameParse() chokes on in the case of the
Fedora bug is:
"DejaVu Sans Mono-12:familylang=en:style=Book:stylelang=en:fullname=DejaVu
Sans
Mono:fullnamelang=en:slant=0:weight=80:width=100:pixelsize=16:spacing=100:foundry=unknown:antialias=True:hintstyle=2:hinting=True:verticallayout=False:autohint=False:globaladvance=True:file=/usr/share/fonts/dejavu/DejaVuSansMono.ttf:index=0:outline=True:scalable=True:dpi=96:rgba=5:scale=1:minspace=False:charset=
|>^1!|>^1!P0oWQ
|>^1!|>^1!|>^1!!!!%#|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>]!ox9ao]!!!)$|>^1!|>^0s|>Ul<|>^1!|>^1!z~Ef{P)di*!!t|u!!!.%|>^1!|>^1!!BB..;wnZH|>[gE|>^0{|>XZQ|>T)%!!!1&|>^1!|>^1!|>^1!!#>r?(0~]4%tT<~|>YRc#?>K%!!!4(8?MWi|>J~~{ma}P|>^0~!!!;)
!!!7)RimPQ$WUr)#F+zml8K9E!BT>Y9WNHO!!!W5#?3E%!!!Q3
{y]9#+~x?1!!$8i !!!W5
|>T)!/?6HF!!#$Dr;]W3q~F^z(1+e4%&T#Byf*＠＠{{B$~
!!#(E{}$34|>VCi|;{>WxJnq%S~^q^5^*vQ9;.pf#%k.{!!#+F9Bx6P|>^1!^{M＠P9WIli|>^1!|97t]w)J%tP+*+*!!#0G|>TE*M9v*pP0o~>|<;7s/?1rs#%lql
!!#3H1Q.o1!!$eu|<lZy
|>T)!|>^1!|>^1!|>^1!!!#6I|3|1＠9Ugvp|>^0~|>]1c|;$OI!!!!iz~FsO!!&cU!!#9Jx4B>+P#X02qsus$1r.a#yiR*a!!&TQ!!)n<
!!#>K !!!!+
!!#AL|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!!!#DM|>^1!{{K.!|>^1!|>^1!/?+uU!!B7)
!!#GN|>]fO|>^+~Ow1gH!)pSh{}$35P0fQP!!!#4!!!0A!!#MP %rpV9!!#PQ
!!&TR !!!K1 !!#SR$W1pK !!#VS yDUyF !!#]UPN0cS!!$>N
!!(w|ysiAJ!!!$| !!FcS!!!1& !!+fv !!!!G !!+u{!!!!)
|>6r||>^1!gm&i!!!$/f w0TUs!!+~~ |9.n]|>^1!|>^1!|>^1!ZK#{t!!.%!
3lbtU!!5[S #?>K& !!5aT |>T)!|>^1!!!!!4 !!5dU
|5n[<:lang=aa|af|ar|ast|av|ay|az-az|az-ir|bm|be|bg|bi|bin|br|bs|bua|ca|ce|ch|chm|co|cs|cv|cy|da|de|el|en|eo|es|et|eu|fa|fi|fj|fo|fr|ff|fur|fy|ga|gd|gl|gn|gv|ha|haw|ho|hr|hu|hy|ia|ig|id|ie|ik|io|is|it|ka|kaa|ki|kk|kl|ku-am|kum|kv|kw|ky|la|lb|lez|ln|lt|lv|mg|mh|mi|mk|mo|mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|os|pl|pt|rm|ro|ru|sah|sco|se|sel|shs|sk|sl|sm|sma|smj|smn|so|sq|sr|ss|st|sv|sw|tk|tl|tn|to|tr|ts|tt|tw|tyv|uk|uz|ve|vo|vot|wa|wen|wo|xh|yap|yo|zu|ak|an|ber-dz|crh|csb|ee|fat|fil|hsb|ht|hz|jv|kab|kj|kr|ku-tr|kwm|lg|li|mn-mn|ms|na|ng|nv|pap-an|pap-aw|qu|quz|rn|rw|sc|sg|sn|su|ty|za:fontversion=153354:capability=otlayout\\:DFLT
otlayout\\:arab otlayout\\:cyrl otlayout\\:grek otlayout\\:lao
otlayout\\:latn:fontformat=TrueType:embolden=False:embeddedbitmap=True:decorative=False:lcdfilter=1:namelang=en:prgname=xemacs-xft-21.5-b34:hash=sha256\\:a82f85d87ec9a2251d93e3ca9bc34792c7c37f023dd17feadad819197a7f3a2d:postscriptname=DejaVuSansMono"
Stepping through with gdb shows that fontconfig bails out and returns
NULL when it hits the "charset=" part.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:01 p.m.
On Wed, May 14, 2014 at 1:29 PM, Jerry James <james(a)xemacs.org> wrote:
So I either need to apply the existing patch to the 21.5.34 release
and rebuild for Fedora, or start agitating for a 21.5.35 release. :-)
A little more looking shows that the problem with the charset
attribute was figured out and fixed about 3 months after the release
of 21.5.34. So the poor Fedora user that filed the bug is tripping
over bugs that were fixed 8 months ago. I think I'm going with the
option of begging for a 21.5.35 release. What can I do to help move
towards that?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:04 p.m.
Jerry James writes:
On Wed, May 14, 2014 at 10:59 AM, Jerry James
<james(a)xemacs.org> wrote:
> PATCH 21.5
Well, that was a bunch of nonsense.
Oh, trust yourself more than that! :-)
Ignore this patch. I was thinking that wrap_foo worked differently
than it does.
I believe it does work differently than it does, though -- in
--with-union-type builds. In that case, a *new* Lisp_Object (union)
is created (on the stack) and the appropriate member set to the
argument being wrapped, then that new Lisp_Object is returned.
I forget exactly what the semantics of this are, I suppose the
returned union object is copied by the compiler, but I can't see any
possible way that the return value is the pointer that was passed in.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:13 p.m.
On Wed, May 14, 2014 at 2:04 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
I believe it does work differently than it does, though -- in
--with-union-type builds. In that case, a *new* Lisp_Object (union)
is created (on the stack) and the appropriate member set to the
argument being wrapped, then that new Lisp_Object is returned.
I forget exactly what the semantics of this are, I suppose the
returned union object is copied by the compiler, but I can't see any
possible way that the return value is the pointer that was passed in.
In the --with-union-type case, the size of Lisp_Object is equal to the
size of EMACS_INT. When an Lisp_Object on the stack is created and
one of the wrap() funtions is called on a pointer, the ui field of the
Lisp_Object is set to the pointer. That fills all of the bits, so its
value is exactly the pointer. Then, when the Lisp_Object is returned,
the contents of that stack area (i.e, the pointer) is returned.
So, yes, the return value is exactly the pointer. It really was
nonsense. Call the same wrap_foo() function as many times as you want
on a pointer, and you'll get the same value out of all of those calls.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:02 a.m.
Jerry James writes:
So the poor Fedora user that filed the bug is tripping
over bugs that were fixed 8 months ago.
Which has the semantics of "the only bug fixed since 21.5.34" (pretty
close).
I think I'm going with the option of begging for a 21.5.35
release.
What can I do to help move towards that?
You don't have to beg, just ask. It will take a couple of weeks to
get on top of $DAYJOB, GSoC, and DMARC, and to fix up the release
docs. It's not that much work, but due to Tux connectivity issues it
requires several hours of babysitting for uploads.
I'd be a lot more proactive about releases if there were more patches
aimed at stuff that hurts typical users rather than Common Lisp
improvements and the like, especially more GNU syncs. But failing
that, you can always ask. :-)
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:22 p.m.
On Wed, May 14, 2014 at 9:02 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Which has the semantics of "the only bug fixed since
21.5.34" (pretty
close).
Hmmm. If that's really true, maybe I should just ship current
mercurial head for Fedora, rather than put you through the pain of a
release. Let me think about it.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:01 a.m.
Jerry James writes:
On Wed, May 14, 2014 at 9:02 PM, Stephen J. Turnbull
<stephen(a)xemacs.org> wrote:
> Which has the semantics of "the only bug fixed since 21.5.34" (pretty
> close).
Hmmm. If that's really true, maybe I should just ship current
mercurial head for Fedora, rather than put you through the pain of a
release. Let me think about it.
Well, given that by now the full diff is about 33000 lines (mostly in
man/), we can justify a release.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:47 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Well, given that by now the full diff is about 33000 lines (mostly
in man/), we can justify a release.
+1. Much easier for me in gentoo with a proper release.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3644
days inactive
3646
days old
10 comments
3 participants
participants (3)
-
Jerry James -
Stephen J. Turnbull -
The XEmacs Package Smoketest