Bug 438687 - minicom aborts.
minicom aborts.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-24 10:24 EDT by David Woodhouse
Modified: 2008-04-10 06:04 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-10 06:04:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test case (which doesn't reproduce the problem) (1.60 KB, text/plain)
2008-03-27 05:31 EDT, David Woodhouse
no flags Details

  None (edit)
Description David Woodhouse 2008-03-24 10:24:52 EDT
/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?
Comment 1 David Woodhouse 2008-03-27 05:30:46 EDT
[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.
Comment 2 David Woodhouse 2008-03-27 05:31:42 EDT
Created attachment 299295 [details]
test case (which doesn't reproduce the problem)
Comment 3 Ulrich Drepper 2008-03-30 04:10:23 EDT
(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.
Comment 4 Jakub Jelinek 2008-04-07 16:06:09 EDT
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
Comment 5 Jakub Jelinek 2008-04-10 06:04:10 EDT
Should be fixed in 2.7.90-14

Note You need to log in before you can comment on or make changes to this bug.