Re: [xml] possible race condition

On Fri, Dec 18, 2015 at 03:59:23PM +0800, Daniel Veillard wrote:
On Wed, Dec 16, 2015 at 11:27:11PM +0400, Hovnatan Karapetyan wrote:

To my question on possible non thread-safe code in libxml2 on stackoverflow
I got a reply that there is indeed a race condition at Could anyone
please confirm this?

  The catalogs are indeed build progressively, doing it upfront on any XML
processing would add a huge burden to any parsing. Building it progressively
looks indeed racy, but I tried very hard to avoid any issue with it there
is even a test designed explicitely for this look for testThreads.c in the
source code, it does test multithreaded building of the catalog to make sure
there is no leak or building issues in practice.
  Now if someone has a reproducer with an issue related to that code
I'm interested but just saying "an automated tool told me there is a race here
but I don't know why, how and if there is side effects" means possibly
wasting a lot of time fo a non-issue.

  Testthreads should be part of running make check though somehow it
seems to have fallen through the cracks, I'm re-adding it,

  BTW for feedback on bugoverflow, yes there is a race but we don't
care, it's about catching recursions, and say that the threshold is
100, we may miss it when reaching depth of 100 but since it's recusive
we will hit 101 and the problem will be caught anyway, just one iteration
later so no it's not worth putting a gard there,


Daniel Veillard      | Open Source and Standards, Red Hat
veillard redhat com  | libxml Gnome XML XSLT toolkit | virtualization library

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]