spatialite_cleanup_ex() is not re-entrant due to xmlCleanupParser()
Even Rouault
Hi,
below a bug raised against GDAL but I believe it is fundamentally
a Spatialite bug. spatialite_cleanup_ex() calls
free_internal_cache(), which calls xmlCleanupParser(), and this
function is not thread-safe.
There is multiple documentation
(https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2-parser.html#xmlCleanupParser
,
https://0pointer.net/blog/projects/beware-of-xmlCleanupParser.html,
https://stackoverflow.com/questions/18417163/xmlcleanupparser-memory-loss)
that shows that xmlCleanupParser() is not appropriate for library
code, but should rather be put at the end of a main() binary. I'd
suggest removing it from free_internal_cache(). And potentially
offer a global spatialite_cleanup_libxml2() that could be used for
applications that themselves don't use libxml2 and would want to
fully reclaim libxml2 based memory
Even
-------- Message transféré --------
| Sujet : | [OSGeo/gdal] Shutting down `spatialite` might not be thread-safe (`double free or corruption (fasttop)`) (Issue #10685) |
|---|---|
| Date : | Fri, 30 Aug 2024 05:13:34 -0700 |
| De : | Laurențiu Nicola <notifi...@github.com> |
| Répondre à : | OSGeo/gdal <reply+AAJDD4NQJH365Q6C4D...@reply.github.com> |
| Pour : | OSGeo/gdal <gd...@noreply.github.com> |
| Copie à : | Subscribed <subsc...@noreply.github.com> |
What is the bug?
I have an app that's sometimes crashing with this stack trace:
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007f7d8ca2a26e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007f7d8ca0d8ff in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007f7d8ca0e7b6 in __libc_message_impl (fmt=fmt@entry=0x7f7d8cbb38d7 "%s\n") at ../sysdeps/posix/libc_fatal.c:132
#6 0x00007f7d8ca8dfe5 in malloc_printerr (str=str@entry=0x7f7d8cbb6c48 "double free or corruption (fasttop)") at ./malloc/malloc.c:5772
#7 0x00007f7d8ca9031a in _int_free (av=0x7f7d80000030, p=<optimized out>, have_lock=0) at ./malloc/malloc.c:4607
#8 0x00007f7d8ca92d9e in __GI___libc_free (mem=0x7f7d800166d0) at ./malloc/malloc.c:3398
#9 0x00007f7d8c606086 in xmlCleanupCharEncodingHandlers () from /lib/x86_64-linux-gnu/libxml2.so.2
#10 0x00007f7d8c631162 in ?? () from /lib/x86_64-linux-gnu/libxml2.so.2
#11 0x00007f7d8a8a600f in ?? () from /lib/x86_64-linux-gnu/libspatialite.so.8
#12 0x00007f7d8a4fc8ad in spatialite_cleanup_ex () from /lib/x86_64-linux-gnu/libspatialite.so.8
#13 0x00007f7d8dc23c2b in ?? () from /lib/x86_64-linux-gnu/libgdal.so.35
#14 0x00007f7d8dc2fb9d in ?? () from /lib/x86_64-linux-gnu/libgdal.so.35
#15 0x00007f7d8ddd3f32 in GDALClose () from /lib/x86_64-linux-gnu/libgdal.so.35
#16 0x000056428ef344ed in gdal::dataset::Dataset::close ()
#17 0x000056428ee46a0b in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#18 0x000056428ee1f39d in core::ops::function::FnOnce::call_once{{vtable.shim}} ()
#19 0x000056428efaf78b in std::sys::pal::unix::thread::Thread::new::thread_start ()
#20 0x00007f7d8ca81a94 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#21 0x00007f7d8cb0ea34 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
It can indeed call GDALClose
on multiple SQLite datasets at the same time.
Steps to reproduce the issue
None yet, sorry!
Versions and provenance
ghcr.io/osgeo/gdal:ubuntu-full-3.9.2
Additional context
No response
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this
thread.