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: > > Hi, > > > > To my question on possible non thread-safe code in libxml2 on stackoverflow > > ( > > http://stackoverflow.com/questions/34007044/libxml2-multithreading-errors-in-helgrind) > > I got a reply that there is indeed a race condition at > > https://git.gnome.org/browse/libxml2/tree/catalog.c#n1634. 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 -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
