Title fatal error during isearch-forward
Type defect Module core code 21.5
Severity crash Platform N/A
Keywords Nosy List
These controls should only be changed by committers and tracker administrators.
Status closed   Reason superseded
Superseder fatal error during isearch-forward
View: 190
  Submitted 2007-12-09.22:38:32
Priority normal   Assigned To

Created on 2008-01-19.04:58:05 by stephen, last changed 2008-01-23.10:03:21 by stephen.

File name Uploaded Type Edit Remove
unnamed stephen, 2008-01-19.04:58:05 text/plain
msg105 [hidden] ([hidden]) Date: 2008-01-19.04:58:05
  Message-ID: <>
Aidan Kehoe writes:

 > In local testing, I can reproduce your bug; and it seems that Stephen’s
 > patch of ,
 > which he has yet to commit, eliminates it. We’d love confirmation of this
 > from you; despite Stephen’s ‘do not apply this patch’ in his message, the
 > change is easy to apply.

Now that I've got a test that reproduces, I'll apply it tomorrow.

Note that the reason for third parties not to apply is that I intend
to make a whitespace change, and their CVS checkouts will have
conflicts due to that since the posted patch ignores whitespace.

However, there may very well be another bug lurking, as the backtrace
I was looking at was in a function that a pure ASCII search pattern
should never reach.  (If somebody cares to look, the function is
search.c, simple_search(); if only ASCII is in use, boyer_moore()
should always be used instead.)
msg104 [hidden] ([hidden]) Date: 2008-01-19.04:58:05
  Message-ID: <>
Jerry James writes:

 > I can reproduce this bug.  I'm trying to debug the problem now, and my
 > XEmacs that is doing the debugging is complaining:
 > Alert: ("unchecked charset" #<charset ipa "IPA" "IPA" "IPA
 > (International Phonetic Association)" 96 l2r cols=1 g1 final='0'
 > reg=[MuleIPA] 0x8a0cf>)
 > What does that mean?

It means that the Xft code is a horrible set of kludges, and one of
them failed.

Specifically, when the Xft routines get passed text to display, they
need to decide which font to use based on the charset because that is
how redisplay works.  Redisplay expects a corresponding Mule charset,
but xft_find_charset_font receives as key a string already in Unicode.

I added a table-driven hack to get a Mule charset based on the
character code, and that alert means that we fell off the end of the
table.  It's not particularly harmful, since Xft is well-behaved for
undefined characters.  How an IPA character got into the Unicode
string in the first place is a bit worrying, though.

My guess is that it's a mechanism similar to the one that triggered
the crash Klaus experienced: several charsets were added to the list
of preloaded ones, and one of them has a case table that maps ASCII
into Turkish (or IPA, except that I don't think IPA should have a case

XEmacs-Beta mailing list
Date User Action Args
2008-01-23 10:03:21stephensetstatus: chatting -> closed
priority: normal
reason: superseded
severity: crash
platform: + N/A
type: defect
superseder: + fatal error during isearch-forward
module: + core code 21.5
2008-01-23 10:01:23stephensetfiles: - unnamed
2008-01-19 04:58:05stephensetfiles: + unnamed, unnamed
status: new -> chatting
messages: + msg105
2008-01-19 04:58:05stephencreate