Natanael Copa

> Something is blocking stdout. The gdb backtrace shows that the deadlock happens in `fread()`.

The proposed diff appears to fix it. I am not able to reproduce the deadlock with that change.

But really, I don't understand why we can not let the OS handle it, like it appears to be done originally, in the commented out line: https://github.com/signalwire/libks/blob/0ac67b5ad514f15fa4274580533099acf2dc2403/src/ks_log.c#L321

~Could it be related silent ABI breakage in libxml2? https://gitlab.gnome.org/GNOME/libxml2/-/issues/751~ I git bisected it to this commit: https://gitlab.gnome.org/GNOME/libxml2/-/commit/d025cfbb4bf05785d970e268e46d674580a8a686

reported upstream: https://gitlab.gnome.org/GNOME/libxml2/-/issues/815

I tried to but was unable to reproduce it with `xsltproc`: ```sh cat >entities.dtd &test; EOF cat >test.xslt

It is the entities test, x3, that fails: ```perl like(http_get("/x3"), qr!200 OK.*data=test entity!ms, 'entities'); ```

gdb backtrace from the generated core dump: ``` Reading symbols from ../nginx-1.26.2/objs/nginx... warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing warning: Can't open file /[aio] (deleted) during...

I think what happens is that after https://gitlab.gnome.org/GNOME/libxml2/-/commit/d025cfbb4bf05785d970e268e46d674580a8a686, the `test` entitiy is free'ed with the `xmlFreeDoc`, so the `xmlFreeDtd` ends up touching stuff that is already freed. This change here...

Looks like it leaks, indeed. ``` xslt.t .. 1..10 ==133951== Memcheck, a memory error detector ==133951== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==133951== Using Valgrind-3.23.0...