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

[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-)