IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Remove calls to generic error handler or use stderr for
- legacy deprecation warnings
- nanohttp, nanoftp in standalone mode
- memory debug messages
Use xmlRaiseMemoryError.
Remove TODO macro.
Don't raise errors in xmlmodule.c.
Linking executables will fail on systems with glibc < 2.34 without
declaring these symbols as weak references.
In commit c19771c1f1 these references
were moved to globals.c from threads.c, but the `#pragma weak`
declarations were lost in the process.
Also removing unneeded weak declarations from threads.c.
Hopefully work around the classic problem with double-checked locking:
Another thread could read xmlParserInitialized == 1 but doesn't see
other initialization results yet due to compiler or hardware reordering.
While unlikely, this seems theoretically possible.
The solution is to add a memory barrier after initializing the data but
before setting xmlParserInitialized. It might be enough to use a second
initialization flag which is only used inside the locked section and
update xmlParserInitialized after unlocking. But I haven't seen this
approach in many articles discussing this issue, so it's possibly
flawed as well.
GCC 12 fixed -Waddress warnings for inline functions, resulting in
warnings when comparing pthread_equal with NULL. Simply remove the
check and assume that pthread_equal is available if all the other
functions are. This code is only enabled on Linux anyway.
Private functions were previously declared
- in header files in the root directory
- in public headers guarded with IN_LIBXML
- in libxml.h
- redundantly in source files that used them.
Consolidate all private header files in include/private.
Reset the 'run_once' state in xmlCleanupThreads, so the global
variables can be reinitialized later.
While it's generally unsafe to call xmlCleanupParser and continue to
use the library afterwards, this fix should avoid an outright crash if
you do so on Windows. This should help with applications erroneously
calling xmlCleanupParser.
See #376.
These functions shouldn't be part of the public API. Most init
functions are only thread-safe when called from xmlInitParser. Global
variables should only be cleaned up by calling xmlCleanupParser.
If non-parser parts of libxml (e.g. xmlwriter) are used before a parser,
xmlOnceInit may have run (e.g. via the many paths to xmlGetGlobalState),
but not xmlInitThreads (which is called only by xmlInitParser)
Once globalkey != TLS_OUT_OF_INDEXES (which can happen in many ways),
DLLMAIN(DLL_THREAD_DETACH) may attempt to lock cleanup_helpers_cs
before it is valid. This may happen even if the thread whose exit
is triggering DllMain is from code which is not linked to libxml.
globalkey and cleanup_helpers_cs should be initialized together,
with cleanup_helpers_cs initialized first and deleted last.
Don't include windows.h and wsockcompat.h from config.h but only when
needed.
Don't define _WINSOCKAPI_ manually. This was apparently done to stop
windows.h from including winsock.h which is a problem if winsock2.h
wasn't included first. But on MinGW, this causes compiler warnings.
Define WIN32_LEAN_AND_MEAN instead which has the same effect.
Always use the compiler-defined _WIN32 macro instead of WIN32.
For https://bugzilla.gnome.org/show_bug.cgi?id=737851
Unfortunately this change has introduced a problem which results in
occasional hangs on Windows when running multi-threaded on a multi-core
host.
When locking the xmlRMutex the count field is increment inside the
critical section but when unlocking the count field is decremented
outside the critical section. The increment/decrement is not atomic so
this can result in the count field being updated incorrectly.
The solution is to change xmlRMutexUnlock to decrement the count field
before leaving the critical section rather than after.
Fixes bug #704908
The declarations of pthread functions, used to generate weak references
to them, fail to suppress macros. Thus, if any pthread function has
been provided as a macro, compiling threads.c will fail.
This breaks on musl libc, which defines pthread_equal as a macro (in
addition to providing the function, as required).
Prevent the declarations for e.g. musl libc by refining the condition.
The idea for this solution was borrowed from the alpine linux guys, see
http://git.alpinelinux.org/cgit/aports/tree/main/libxml2/libxml2-pthread.patch
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Reported by Petr Sumbera <petr.sumbera@oracle.com>
Two threads entering xmlInitializeDict concurently could lead
to a lockup due to multiple initializations of the lock used.
To avoid this problem move this to a new private function
called from xmlOnceInit() and deprecate the old initalizer.
Since threaded programs must call xmlInitParser() and this
will lead to dereference of private data and the call to
xmlOnceInit() guaranteed to be unique this should be safe now.
