BTextView sometimes refuses diacritics (says ":inline_only")

[ttcoder]

Sometimes Haiku boots into a state where BTextView won't accept to type (among others) french diacritics like ê or ä. Rebooting generally fixes the problem.

[ttcoder]

Steps to reproduce, once Haiku is booted into a "hosed" state:

• open StyledEdit
• hit the "¨" dead key (or the "chevron" dead key, can't type it here in Trac, messes with display for some reason) on your keyboard. A black-on-blue chevron appears in StyledEdit.
• hit "e" or whatever. Instead of replacing the chevron with an ê, StyledEdit will replace it with this string : :inline_only . I suppose this is the fastest way to locate this bug: grep the source tree for this strange ":inline_only" string, finding which .cpp file contains such a thing.

Bug properties I've found so far:

• BTextViews are all affected (and thus BTextControl, StyledEdit ..etc). Pe is not affected, presumably because it uses its own text engine. I wonder if it is BTextView itself which is the culprit, or another component that it collaborates with (input_server method anyone?)
• Not exceedingly difficult to reproduce: if my Haiku session is in an OK state and does not exhibit this problem, as is true in 80% of cases, I just have to reboot a few times until I finally get Haiku into the "hosed diacritics" state.
• I first saw this bug in the 493xx range, and it is still there now in hrev44058

UPDATE:

• there is a strange workaround if one wants to type a stand-alone chevron: hit the chevron deadkey, but click outside of the StyledEdit window and work in another window. When you come back to StyledEdit the chevron will be accepted. No workaround for actual diacritics like "ê" though.

Grabbo:

• 

[ttcoder]

FWIW, still there in hrev45325 .

Out of curiosity I used the haiku.it.su.se search engine and found two instances of ":inline_only":

• ​http://haiku.it.su.se:8180/source/xref/src/servers/input/InputServer.cpp
• ​http://haiku.it.su.se:8180/source/xref/src/add-ons/input_server/devices/keyboard/KeyboardInputDevice.cpp

(namely, message->AddBool("be:inline_only", true); )

So I'm still leaning to this theory: there is a race condition in the bootup-time initialization of the i18ln code, which makes it sometime look up data in the wrong place, i.e. in the BMessage above (or in the TEXT data segment/area of the code ?? that's where the "be:inline_only" text originates, before being written to a BMessage field of course).

As to the difference between Pe and BTextView, maybe it's because InputServer/KbdInputDevice processes things differently depending on whether the BView is "input method aware " or not (?)

EDIT: also attempted to run Debugger on StyledEdit to catch it "in the act", but gave up quickly (since when you click anywhere in Debugger it de-activates StyledEdit and thus the chevron is deactivated anyway).

[ttcoder]

Didn't see that one in months. Suggest closing, I'll re-open if this mem corruption(?) starts occuring again in newer hrevs.

[waddlesplash]

Still OK to close?

[ttcoder]

AFAIConcerned, definitely yes! Thanks.

[ttcoder]

Noticed for a few weeks that this is back/still there, but this time the string is "e" instead of ":inlineonly..". I'm going to upgrade from 47991 to hrev48117 soon, leaving this ticket closed on the off chance that the aforementionned tough-ass kernel fix ends up fixing this ticket too :-) (noted ticket:11377#comment:3)

EDIT: seeing the bug (first time in a long time) today, still with string "e", on this old hrev48168 install; that's close enough to begeistert that I can't remember if it's pre-fixes or post-fixes, so leaving this ticket closed still, until I'm able to upgrade this install later.

[ttcoder]

For the record, looks like this was actually ​fixed in hrev49019, for which one can make a quite plausible scenario that fits the observed behavior: one of the delete[] string prematurely frees the character being typed after the dead key, which thus could randomly (depending on heap layout) get clobbered by the string "be:inline_only" in method _EnqueueInlineInputMethod().

Another one that was not detected by Coverity, but caught by the guarded heap, go mmlr! 8-)