Bug 77444 - regexec() using unitialized values, closedir()/fclose() not releasing locks
regexec() using unitialized values, closedir()/fclose() not releasing locks
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-06 23:38 EST by n/a
Modified: 2016-11-24 10:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-18 08:21:36 EST
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 n/a 2002-11-06 23:38:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823
Netscape/7.0

Description of problem:
During calls to fclose() and closedir(), their respective locks are
not released.  I am unaware of the specific implications involved,
but a downloaded glibc fixes this (libc-2.2.93.so -> libc-2.2.5.so).
regexec calls (at some point after re_internal) uses an uninitialized
value as pointed out by valgrind.  Again, Im unaware of the specific
consequences of this, however, with this problem, the program under
development crashed, and without, did not.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Call fopen/fclose
2.Call opendir/closedir
3.Call regexec


Actual Results:  Uninitialized values sometimes lead to segfault

Expected Results:  Normal operation.  Sorry, I dont have too much information to
offer
about the product under development.

Additional info:

This is output from valgrind.  All these errors are happening
under the regexec() call.  These errors do not occur with
the downgraded libc.  The problems related to fclose() and
closedir() result in a pthread_mutex_destroy error about
the mutex still being in use.

==9858== Thread 2:
==9858== Use of uninitialised value of size 4
==9858==    at 0x420C15E5: (within /lib/i686/libc-2.2.93.so)
==9858==    by 0x420C12DB: (within /lib/i686/libc-2.2.93.so)
==9858==    by 0x420BD350: (within /lib/i686/libc-2.2.93.so)
==9858==    by 0x420C2DF5: (within /lib/i686/libc-2.2.93.so)
==9858== 
==9858== Thread 2:
==9858== Conditional jump or move depends on uninitialised value(s)
==9858==    at 0x420C15F1: (within /lib/i686/libc-2.2.93.so)
==9858==    by 0x420C12DB: (within /lib/i686/libc-2.2.93.so)
==9858==    by 0x420BD350: (within /lib/i686/libc-2.2.93.so)
==9858==    by 0x420C2DF5: (within /lib/i686/libc-2.2.93.so)
Comment 1 Jakub Jelinek 2002-12-03 18:24:59 EST
The accesses to unitialized memory should be fixed in glibc CVS, fclose/closedir
is done on purpose, it is not a bug.
Comment 2 Michel Arboi 2003-01-31 09:43:55 EST
It seems to be fixed in the Rawhide version.

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