Opened 11 years ago

Closed 9 years ago

Last modified 9 years ago

#2504 closed defect (fixed)

pressing "ñ" makes libgnt exit the mainloop

Reported by: fherrera Owned by: sadrul
Milestone: 2.6.0 Component: finch (gnt/ncurses)
Version: 2.2.2 Keywords:
Cc:

Description

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

Attachments (3)

gdb-finch.txt (13.4 KB) - added by santiagoward2000 11 years ago.
santiagoward2000-finch-backtrace
gdb-finch-2.txt (15.8 KB) - added by santiagoward2000 11 years ago.
gio-channel-encoding.patch.txt (1.2 KB) - added by sadrul 9 years ago.
patch

Download all attachments as: .zip

Change History (27)

comment:1 Changed 11 years ago by sadrul

  • pending changed from 0 to 1

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

comment:1 Changed 11 years ago by trac-robot

  • pending changed from 1 to 0
  • Status changed from new to closed

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

comment:2 Changed 11 years ago by 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)

comment:3 Changed 11 years ago by santiagoward2000

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

comment:4 Changed 11 years ago by sadrul

  • pending changed from 0 to 1
  • Status changed from closed to reopened

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

comment:5 Changed 11 years ago by 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.

Changed 11 years ago by santiagoward2000

santiagoward2000-finch-backtrace

comment:6 Changed 11 years ago by 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?

comment:7 Changed 11 years ago by santiagoward2000

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

Changed 11 years ago by santiagoward2000

comment:8 Changed 11 years ago by santiagoward2000

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

comment:9 Changed 11 years ago by sadrul

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

comment:10 Changed 11 years ago by sadrul

  • pending changed from 1 to 0
  • Version changed from 2.1.0 to 2.2.2

comment:11 Changed 11 years ago by santiagoward2000

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

comment:12 Changed 11 years ago by 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

comment:13 Changed 10 years ago by 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

comment:14 Changed 10 years ago by sadrul

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

comment:15 Changed 10 years ago by 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;
}

comment:16 Changed 10 years ago by sadrul

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

comment:17 Changed 10 years ago by 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.

comment:18 Changed 9 years ago by 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.

Changed 9 years ago by sadrul

patch

comment:19 Changed 9 years ago by QuLogic

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

comment:21 Changed 9 years ago by bernmeister

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

comment:22 Changed 9 years ago by darkrain42

  • Milestone set to 2.6.0

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)

comment:23 Changed 9 years ago by darkrain42

  • Milestone changed from 2.6.0 to 2.6.1

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

comment:24 Changed 9 years ago by qulogic@…

  • Milestone changed from 2.6.1 to 2.6.0
  • Resolution set to fixed
  • Status changed from new to closed

(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.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!