On Tue, May 24, 2011 at 4:01 PM, Stefan Fritsch <[email protected]> wrote: > On Sunday 22 May 2011, Jeff Trawick wrote: >> > Can those people who frequently hit the testreslist failures >> > please check if this commit helps? From a powerpc Debian build >> > host, it looks promising, but I don't have direct access to that >> > machine and can't do repeated tests there. >> >> no luck on Windows 7 >> >> apr-util 1.3.x, gcc, still fails >> apr trunk, Visual C++ 2008 Express, still fails >> >> Seven:~/svn/apr-util-1.3.x-xx/test$ ./testall -v testreslist >> testreslist : /Line 258: expected <10>, but saw <20> >> FAILED 1 of 1 >> Failed Tests Total Fail Failed % >> =================================================== >> testreslist 1 1 100.00% > > Can you try the attached patch in addition? Is this failure sporadic > or always?
tested with apr-util 1.3.x and gcc no change I don't remember if this test has ever worked for me in this environment > > >> > Unfortunately, there are also other thread-safety issues in >> > apr/apr- util. Using hellgrind on testreslist found these >> > issues: >> > >> > - unsafe read of pool->child in apr_pool_destroy. This one >> > worries me. If a subpool is destroyed in one thread while the >> > pool itself is destroyed in another thread, it can happen that >> > apr_pool_destroy is called again for the subpool. This would >> > likely lead to a crash. Any ideas on how to fix this without >> > sacrificing too much performance? >> > >> > - unsafe read of allocator->max_index (PR 48535, likely not >> > critical) >> > >> > - unsafe read of _myself->thd_cnt in thread_pool_cleanup() >> > (likely not critical; but there seem to be other thread-safety >> > issues in that file, at least the access of thd_high is also >> > unsafe) > > The last one is fixed by the attached patch. I no longer think that it > is no problem. > -- Born in Roswell... married an alien...
