Bug 77444

Summary: regexec() using unitialized values, closedir()/fclose() not releasing locks
Product: [Retired] Red Hat Linux Reporter: n/a <vol>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: fweimer, mitr
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-02-18 13:21:36 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 n/a 2002-11-07 04:38:09 UTC
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 23:24:59 UTC
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 14:43:55 UTC
It seems to be fixed in the Rawhide version.