Bug 176583

Summary: gconv seems to be broken and causes segmentation faults
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-12-29 00:46:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert Scheck 2005-12-27 01:54:04 UTC
Description of problem:
The problem is easy to reproduce, just try the following:

robert@tux:~ > LANG=C cp /boot/memtest86+-1.65 /etc
cp: cannot create regular file `/etc/memtest86+-1.65': Permission denied
robert@tux:~ >

robert@tux:~ > LANG=de_DE@euro cp /boot/memtest86+-1.65 /etc
Speicherzugriffsfehler
robert@tux:~ >

"Speicherzugriffsfehler" means "segmentation fault" in English. For me, it 
looks like that you can reproduce it with any application using gconv or so?
For example, chowns or chmods which should end up in a localized "Permission 
denied" also have a "segmentation fault" when using another LANG env.

I guess the same bug caused my chat client irssi to core dump:
#0 0x00410abe in __gconv_transliterate (step=0x8de13b4, step_data=0x8bc9814, 
trans_data=0x0, inbufstart=0x8e73000 ":", inbufp=0xbff7b948, 
inbufend=0x8e73024 "f", outbufstart=0xbff7b94c, irreversible=0xbff7b954) at 
gconv_trans.c:207 
207 gconv_trans.c: No such file or directory. 
in gconv_trans.c

#0 0x00410abe in __gconv_transliterate (step=0x8de13b4, step_data=0x8bc9814, 
trans_data=0x0, inbufstart=0x8e73000 ":", inbufp=0xbff7b948, 
inbufend=0x8e73024 "f", outbufstart=0xbff7b94c, irreversible=0xbff7b954) at 
gconv_trans.c:207 
#1 0x009527ed in gconv (step=0x8de13b4, data=0x8bc9814, inptrp=0xbff7ba10, 
inend=0x8e73024 "f", outbufstart=0x0, irreversible=0xbff7ba88, 
do_flush=0, consume_incomplete=0) at ../iconv/loop.c:311 
#2 0x0040f0d3 in __gconv_transform_utf8_internal (step=0x8de1378, 
data=0x8bc97f0, inptrp=0xbff7bad0, inend=0x8d4801d "", outbufstart=0x0, 
irreversible=0xbff7ba88, do_flush=0, consume_incomplete=0) at ../iconv/skeleton.
c:674 
#3 0x00409d03 in __gconv (cd=0x8bc97e8, inbuf=0xbff7bad0, inbufend=0x8d4801d "", 
outbuf=0xbff7bacc, outbufend=0x89c5451 "", 
irreversible=0xbff7ba88) at gconv.c:72 
#4 0x0040933a in iconv (cd=0x8bc97e8, inbuf=0xbff7bad0, inbytesleft=0xbff7bad8, 
outbuf=0xbff7bacc, outbytesleft=0xbff7bad4) at iconv.c:53 
#5 0x00550bbe in do_conv (obj=0x8c490b8, string=0x8c3a2a0) at Iconv.xs:112

Version-Release number of selected component (if applicable):
glibc-2.3.90-22
gcc-4.1.0-0.10

How reproducible:
Everytime, see above.

Actual results:
Segmentation faults :-(

Expected results:
Just working again soon... ;-)

Comment 1 Ulrich Drepper 2005-12-29 00:46:07 UTC
Most likely the same know issue.

*** This bug has been marked as a duplicate of 176573 ***