Segmentation fault on keyevents test.

[tsesani]

Devuan Chimaera 4.0 and Daedalus 5.0 with all updates. Could be caused by the latest security updates for xorg. Built with X and no SDL from 1.7.0 release and current git clone.

[scaramacai]

The same happens to me. Built with X and no SDL on Devuan Ceres, using gcc. I used the git clone of April 7.

The behavior is quite random. Usually I get a seg fault as soon as I release a key on the keyevent test, but sometimes the program continues to work. In all cases, however, it seems that the event is processed twice. Furthermore, ch code given on key-up is not correct, and is always the same for the same session, independently of the key.

I'm attaching a couple of screenshots that could clarify what actually happens, when the program does not seg fault:

Moreover, I added some print on stderr to keyevents.c to have more information. All the reported cases immediately end with a segment fault

First case: press and release 'a'

Event: key-down, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Pressed 'a'
beginning AG_UNICODE is defined
 key-down: sym=[         A] [097] mod=0x0000 ch=0x61 ('a')
ending AG_UNICODE is defined

Event: key-down, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Pressed 'a'
beginning AG_UNICODE is defined
 key-down: sym=[         A] [097] mod=0x0000 ch=0x61 ('a')
ending AG_UNICODE is defined

Event: key-up, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Segmentation fault

Second case: press Rshift

Event: key-down, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Segmentation fault

The same happens not only for any Ctrl, Shitf etc., but also for any key that is not within the ASCII range. I tried for example with ù and ò.

Third case: press 'a', give focus to another window, give focus to keyevent test and press 's'

Event: key-down, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Pressed 'a'
beginning AG_UNICODE is defined
 key-down: sym=[         A] [097] mod=0x0000 ch=0x61 ('a')
ending AG_UNICODE is defined

Event: key-down, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Pressed 'a'
beginning AG_UNICODE is defined
 key-down: sym=[         A] [097] mod=0x0000 ch=0x61 ('a')
ending AG_UNICODE is defined

Event: key-down, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Pressed 's'
beginning AG_UNICODE is defined
 key-down: sym=[         S] [115] mod=0x0000 ch=0x73 ('s')
ending AG_UNICODE is defined

Event: key-down, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Pressed 's'
beginning AG_UNICODE is defined
 key-down: sym=[         S] [115] mod=0x0000 ch=0x73 ('s')
ending AG_UNICODE is defined

Event: key-up, with number of args: 5
Arg[0]: 
Arg[1]: 
Arg[2]: key
Arg[3]: mod
Arg[4]: ch
Size of event_ptr 8
Size of event 624
Size of console_ptr 8
Segmentation fault

This is my libagar build as provided by agartest:

[JulNadeauCA]

This may possibly be due to X input methods. Could you try the test again with X input methods disabled?

In revision https://github.com/JulNadeauCA/libagar/commit/32b0acb5dbbb7853f9c408d4fe3d75d34b72318e, I've added an option no-im to the glx driver which can be used to disable X input methods.

If you run agartest -d 'glx(no-im)' keyevents, do you see the same behavior?

[JulNadeauCA]

Revision https://github.com/JulNadeauCA/libagar/commit/8a1ca6762d604510ef5a31d6b192a8ddf64cc85d should hopefully fix the problem. Can you confirm that it does for you? We were passing KeyRelease events to XwcLookupString(), which the documentation recommends that we don't.

[scaramacai]

Revision 8a1ca67 should hopefully fix the problem. Can you confirm that it does for you? We were passing KeyRelease events to XwcLookupString(), which the documentation recommends that we don't.

Thank you very much for your quick reply! Things are going better.

Segmentation faults are disappeared.

The problem that the key-(up/down) is processed twice still exists, however when the 'Tab' key is pressed and released, for some reason I don't understand, the test comes to a state where there is only one "key-down, key-up" per key, and from that point on all seems to go fine.

Actually, the Tab key is the only one that gives the right response since the very beginning of the test.

I was also able to put the test in the right state by:

• press 'Tab' (receive just one key-down event)
• press another key (receive two key-down events)
• release 'Tab' (one key-up)
• release the other key (one key-up)
• press any key (now it seems to work as it should)

I tested this with both -d glx and with -d 'glx(no-im)' as suggested by you. I also tried to disable the global keys bindings in agartest.c, but results are the same (apart that Shift+Ctrl+C, Esc, an so on are reported within the key events).

[scaramacai]

News 2024-04-12

Recompiled using clang (but don't think this is the point) and also added SDL2.

The behavior is the same as before (tested glx, sdl2mw, and sdl2fb) but discovered that clicking any mouse button (1-5) one or more times the problem disappears (as it is when pressing and releasing Tab).

Hope this can help to fix the code.