Bug 77444 - regexec() using unitialized values, closedir()/fclose() not releasing locks
Summary: regexec() using unitialized values, closedir()/fclose() not releasing locks
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-11-07 04:38 UTC by n/a
Modified: 2016-11-24 15:08 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-18 13:21:36 UTC

Attachments (Terms of Use)

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

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:

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
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== 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.

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