This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
- From: "edwintorok at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 27 Jan 2010 12:35:51 -0000
- Subject: [Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
- References: <bug-42624-15165@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #20 from edwintorok at gmail dot com 2010-01-27 12:35 -------
Thanks to Jakub for the hints.
This is not a bug in libstdc++/gcc:
the problem is that fork() is called when we already have threads (due to
openmp/libstdc++ parallel mode), and then you can call a limited number of
functions before exec().
std::find is called both before and after fork(). This is fine in a default
build, but in a parallel mode build, the first std::find spawns threads, which
ClamAV doesn't expect.
I will just make it a #error if ClamAV is built in libstdc++ parallel mode.
--
edwintorok at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624