pressing "ñ" makes libgnt exit the mainloop

[fherrera]

when using finch, pressing "ñ" (ñ) causes the process to finish.

When debugging it, it seems that the mainloop is terminated. This is also happening with the libgnt tests, so it's a libgnt problem

[sadrul]

What's your locale? What's your $TERM?

[trac-robot]

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

[santiagoward2000]

I have the same problem. Using finch, when I press "ñ" it crashes and I get: Segmentation fault (core dumped) This happens when I use UTF-8. Using ISO-8859-15 would leave a space each time I press "ñ", but it crashes with the same error when I press enter (after having entered a "ñ" character)

[santiagoward2000]

Sorry, I forgot to mention I'm using xfce4-terminal

[sadrul]

If you get the crash with 2.2.2, please get a backtrace.

[santiagoward2000]

OK, I just upgraded to 2.2.2, and got a backtrace. However, since I upgraded, instead of getting a "Segmentation fault (core dumped)", finch just closes when I press "ñ", and the backtrace said it exited normally. I'll attatch the file.

[santiagoward2000]

santiagoward2000-finch-backtrace

[sadrul]

How about, after attaching to the process, you do 'break _exit', then 'continue', if you press the key after that, does it break in gdb, with a useful backtrace?

[santiagoward2000]

I did that, and even if Finch had quitted, gbd said it was still running.

[santiagoward2000]

It's been some days already. I just wanted to know if the backtrace was useful or if I should do anything else.

[sadrul]

The backtrace is not useful, unfortunately. And I don't know how to reproduce the problem.

[santiagoward2000]

Well, I found a solution. I set xfce4-terminal to TERM=screen and it fixed it.

[ari]

I can reproduce this in gnome-terminal when not inside screen and when using a UTF-8 locale. Also, these additional problems occur:

- Compose,s,s should produce ß, but

produces an underbar

- Compose," (double quote) and a/o/u opens a dialog instead of

producing vocal with diaresis

[QuLogic]

Hey sadrul,

Couldn't get it to break at _exit, but I tried breaking at g_main_loop_quit instead:

#0  IA__g_main_loop_quit (loop=0xad4000) at gmain.c:2873
	__PRETTY_FUNCTION__ = "IA__g_main_loop_quit"
#1  0x00007f6bd3faaea2 in wm_quit (bindable=<value optimized out>, 
    list=<value optimized out>) at gntwm.c:1077
	wm = (GntWM *) 0x8e4020
#2  0x00007f6bd3fac3a2 in gnt_wm_process_input (wm=0x8e4020, 
    keys=0xa687e0 "\033q") at gntwm.c:1931
	ret = <value optimized out>
#3  0x00007f6bd3fae462 in io_invoke (source=<value optimized out>, 
    cond=<value optimized out>, null=<value optimized out>) at gntmain.c:285
	back = 0 '\0'
	p = 0
	keys = "ñ\000\000\000\000\000\000\000�v\000\000\000\000\000Z<\000\000\000\000\000\000\001\000\000\000\000\000\000\0000��\000\000\000\000\000\217�\214�k\177\000\000AG\000\000\000\000\000\000\030\212�\000\000\000\000\000Z<\000\000\000\000\000\000\004�\214�k\177\000\000Z<\000\000\000\000\000\000\030\212�", '\0' <repeats 14 times>, "\222w\000\000\000\000\000\000\222w\000\000\000\000\000@�w\000\000\000\000\000`{��k\177\000\000\000\222w\000\000\000\000\000�\227w\000\000\000\000\000@�w\000\000\000\000\000`{��k\177\000\000\000\000\000\000\000\000\000\000���\177\000\000\000\000\t\025?�k\177\000\000@�w\000\000\000\000\000�]i�
"...
	rd = 2
	k = 0xa687e2 ""
	cvrt = 0xa687e0 "\033q"
#4  0x00007f6bd28d7e71 in IA__g_main_context_dispatch (context=0x77b740)
    at gmain.c:2009
No locals.
#5  0x00007f6bd28db106 in g_main_context_iterate (context=0x77b740, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2642
	got_ownership = <value optimized out>
	max_priority = 2147483647
	timeout = 3930
	some_ready = 1
	nfds = <value optimized out>
	allocated_nfds = <value optimized out>
	fds = (GPollFD *) 0xb50a00
	__PRETTY_FUNCTION__ = "g_main_context_iterate"
#6  0x00007f6bd28db3a9 in IA__g_main_loop_run (loop=0xad4000) at gmain.c:2850
	got_ownership = <value optimized out>
	self = (GThread *) 0x76d010
	__PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#7  0x0000000000436816 in main (argc=3, argv=<value optimized out>)
    at finch.c:421

[sadrul]

Interesting. It looks like g_locale_to_utf8 is converting "ñ" into "alt+q" for some reason. I have no idea why, though.

[QuLogic]

That's odd. I tried printing out keys and ended up with c3 b1, which is the correct UTF-8 sequence for 'ñ'. I also tried this really short program (that I hope is correct), and the output was the same. Maybe there's something else that finch sets up that's messing with things?

#include <stdio.h>
#include <locale.h>
#include <glib.h>
int
main(int argc, char **argv) {
	int i;
	char n[] = ñ";
	gchar *result;
	setlocale (LC_ALL, "");
	result = g_locale_to_utf8(n, -1, NULL, NULL, NULL);
	for (i = 0; result[i]; i++)
		printf("%02x\n", (unsigned char)result[i]);
	g_free(result);
	return 0;
}

[sadrul]

Does it print the same values if you read the string from user input (using read, for example)?

[QuLogic]

Yes, as I said, printing keys before g_locale_to_utf8 in finch is correct. Using read() in the test program works fine as well.

[sadrul]

QuLogic: Since you can reproduce this problem, could you please test the attached patch and see if that helps with anything. Try changing '#if 0' to '#if 1' if the patch as it is doesn't help much.

[sadrul]

patch

[QuLogic]

Ticket #9636 has been marked as a duplicate of this ticket.

[bernmeister]

Would it be prudent to retarget this patch to 2.6.0 or is that asking for trouble?

[darkrain42]

Sure, why not. Maybe they'll fix it. :)

(for the record, they did some work in d@cpi and figured out what the issue is. I'm unsure if they've committed fixes yet; I may have missed them)

[darkrain42]

Doesn't look like it's going to be fixed for 2.6.0.

[qulogic@…]

(In [21745356545795bcec9c44cff0e779429c5092c6]):
Make gnt_keys_refine UTF8-compatible. Note, the rest of the tests don't need to be changed as multi-byte UTF8 values are always >128.

Fixes #2504.