Bug 43136 - core during call of wcstol()
core during call of wcstol()
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-01 03:25 EDT by Martin Strassburger
Modified: 2016-11-24 10:09 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-01 03:51:16 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)

  None (edit)
Description Martin Strassburger 2001-06-01 03:25:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
I'm settling the "C" locale und during a all of wcstol() a core is written.

How reproducible:
Always

Steps to Reproduce:
Test source:
cat hieble3.c

#include <stdio.h>
#include <locale.h>
#include <stdlib.h>
#include <wctype.h>
#include <wchar.h>

void test(const wchar_t* p)
{
        const wchar_t*  start = p;
        wchar_t*        stop  = 0;
        long            value = 0;

        fprintf(stderr, "in=%.7S start=%p ", start, start);

        value = wcstol( start, &stop, 10 );

        if( value == 0 && stop == 0 )
            fprintf(stderr, " - conversion failed\n");
        else
            fprintf(stderr, "stop=%p ch=%ld\n",   stop,  value);
}
 
int main(int argc, char** argv)
{
  char *c;
  test(L"1234");                  /* ok */
  test(L"FAIL");                  /* ok */
 
#if 1
  c=setlocale(LC_ALL, "de_DE.ISO-8859-1");
  printf("setlocale returns %s\n", c == NULL ? "NULL" : c);
 
  test(L"1234");                  /* ok */
  test(L"FAIL");                  /* ok */
#endif
  c=setlocale(LC_ALL, "C");
  printf("setlocale returns %s\n", c == NULL ? "NULL" : c);
 
  test(L"1234");                  /* ok */
  test(L"FAIL");                  /* core dump */
 
  return 0;
}

gcc -Wall hieble3.c     

./a.out
in=1234 start=0x8048668 stop=0x8048678 ch=1234
in=FAIL start=0x804867c stop=0x804867c ch=0
setlocale returns de_DE
in=1234 start=0x8048668 stop=0x8048678 ch=1234
in=FAIL start=0x804867c stop=0x804867c ch=0
setlocale returns C
in=1234 start=0x8048668 stop=0x8048678 ch=1234
in=FAIL start=0x804867c Segmentation fault (core dumped)
	

Actual Results:  gdb ./a.out core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
#0  0x400d1605 in towupper () at wcfuncs.c:98
98      wcfuncs.c: No such file or directory.
(gdb) bt
#0  0x400d1605 in towupper () at wcfuncs.c:98
#1  0x4007cc7e in __wcstol_internal () at ../stdlib/strtol.c:450
#2  0x4007cd9c in wcstol () at ../stdlib/strtol.c:450
#3  0x80484d4 in test ()
#4  0x80485d1 in main ()
#5  0x400309cb in __libc_start_main () at
../sysdeps/generic/libc-start.c:122
(gdb)

Expected Results:  The last line should look like:
in=FAIL start=0x804867c stop=0x804867c ch=0


Additional info:

If I change #if 1 to #if 0 and recompile, the program seems to work.
Comment 1 Jakub Jelinek 2001-06-01 03:32:16 EDT
Wide character support in glibc 2.1.x is known to be incomplete and known to
be buggy. If you need proper wide character support, you should use glibc 2.2.x.
Comment 2 Martin Strassburger 2001-06-01 03:51:12 EDT
The glibc of SuSE 7.0 (shlibs 2.1.3-190) does not have the problem.
Why is the RedHat glibc not able to run the testprogram?
The RedHat glibc 2.1.2-18 was able to run the programm, too.
Comment 3 Jakub Jelinek 2001-06-01 04:58:55 EDT
Because it was fixed in glibc after 6.2 distribution was released.
See http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/locale/C-ctype.c.diff?r1=1.22.2.4&r2=1.22.2.5&cvsroot=glibc
for a patch.
But I don't consider this serious enough to issue an errata because of it.
If we'll release a security errata for 6.2 glibc, then we'll include it.
As I said, there are many other bugs in glibc 2.1.x and backporting all of
them from glibc 2.2.x is not productive solution, glibc 2.2.x can be run
on RHL 6.x without problems.

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