Bug 3787 - popen isn't thread-safe
Summary: popen isn't thread-safe
Status: RESOLVED INVALID
Alias: None
Product: uClibc
Classification: Unclassified
Component: stdio (show other bugs)
Version: unspecified
Hardware: All All
: P2 major
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-25 10:31 UTC by Andreas Schigold
Modified: 2012-06-04 06:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments
working testcase (1.42 KB, text/plain)
2012-04-18 08:57 UTC, Bernhard Reutner-Fischer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schigold 2011-05-25 10:31:23 UTC
function popen isn't thread-safe:

FILE *popen(const char *command, const char *modes)
{
...
        VFORK_LOCK;
        if ((pid = vfork()) == 0) {     /* Child of vfork... */
                // child-stuff
        }
-->     VFORK_UNLOCK; // Line 109

...

        if (pid > 0) {                          /* Parent of vfork... */
                // handling of popen_list
-->             VFORK_UNLOCK; // Line 121

                return fp;
        }
-->     // Line 125

As you see the mutex will be locked correct, but it will be unlocked always in line 109 of file popen.c. After that the function handles the popen_list and tries another unlock in line 121.

If 2 threads are calling popen at the same time, they can damage the popen_list.

I suggest to move the VFORK_UNLOCK-call from line 109 to line 125 to solve this.

Greetings, Andreas
Comment 1 Bernhard Reutner-Fischer 2012-04-18 08:57:34 UTC
Created attachment 4280 [details]
working testcase

I would like to reproduce this alleged bug.
Can you change attached testcase so it fails?

TIA,
Comment 2 Andreas Schigold 2012-06-02 09:33:24 UTC
Hm, I'sorry. I afraid it was my fault. I oversaw the another VFORK_LOCK inside the if-block in line 118. So I think this code is okay.

It was one year ago and I'm not sure, what was the exact reason for our problems. Possibly in our code was one "fclose"-call with a popen'ed FILE pointer.

In a test program I also couldn't reproduce the problem. So I think we can close this bug. Sorry, if I confused you with my bad research.

Greetings
Andreas Schigold