/dev/VolGroup00/LogVol00 contains a file system with errors, check forced. minicom: ../iconv/loop.c:444: internal_utf8_loop_single: Assertion `inptr - bytebuf > (state->__count & 7)' failed. Aborted Are we assuming that input is valid UTF-8 and aborting if it isn't?
[root@efika ~]# cat /boot/initrd-2.6.25-0.141.rc6.git5.fc9.img ª�G�}\TU��pP�Ƣ�ꢢminicom: ../iconv/loop.c:444: internal_utf8_loop_single: Assertion `inptr - bytebuf > (state->__count & 7)' failed. Program received signal SIGABRT, Aborted. 0x0f33873c in raise () from /lib/libc.so.6 (gdb) bt #0 0x0f33873c in raise () from /lib/libc.so.6 #1 0x0f33a4b4 in abort () from /lib/libc.so.6 #2 0x0f32f818 in __assert_fail () from /lib/libc.so.6 #3 0x0f327ac4 in __gconv_transform_internal_utf8 () from /lib/libc.so.6 #4 0x0f396b0c in wcrtomb () from /lib/libc.so.6 #5 0x0f33cd64 in wctomb () from /lib/libc.so.6 #6 0x1002b388 in one_wctomb ( s=0xff961bdc "��\200<\020\005F \020\002ϴ\017J��", wchar=166) at common.c:110 #7 0x1001b8f0 in _write (c=166, doit=1, x=75, y=13, attr=0 '\0', color=112 'p') at window.c:399 #8 0x1001dd1c in mc_wputc (win=0x10054620, c=166) at window.c:1061 #9 0x1000a020 in vt_out (ch=166) at vt100.c:1055 #10 0x10027218 in do_terminal () at main.c:768 #11 0x100068a4 in main (argc=2, argv=0xff9622c4) at minicom.c:1373 (gdb) This looks like a glibc problem. wctomb() isn't supposed to abort. It's supposed to return -1 if it's given something it doesn't like. I instrumented minicom's one_wctomb() function to dump all the characters it was printing, and I'll attach the output from one instance of the crash. But I can't reproduce with a simple loop calling wctomb() with those characters.
Created attachment 299295 [details] test case (which doesn't reproduce the problem)
(In reply to comment #0) > Are we assuming that input is valid UTF-8 and aborting if it isn't? No, that assertion ensures a fundamental step in the processing. It means that more than the bytes making up an incomplete character, which are stored in the state, are used to produce an output character. This must be true. Your test case, as announced, does not reproduce the problem. I cannot imagine where there is a problem. Without a real reproducer I cannot hunt this down.
mbtowc and wctomb were sharing mbstate_t conversion state and minicom was calling them mixed without calls with NULL to request initial state. Fixed with http://sourceware.org/ml/glibc-cvs/2008-q2/msg00009.html
Should be fixed in 2.7.90-14