- Package:
- libfastjson4
- Source:
- libfastjson4
- Description:
- fast json library for C
- Submitter:
- Arthur Marsh
- Date:
- 2025-12-08 21:17:02 UTC
- Severity:
- normal
- Tags:
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Upgrading libfastjson4 lead to rsyslog failing:
service rsyslog restart
Stopping enhanced syslogd: rsyslogd.
Starting enhanced syslogd: rsyslogd/usr/sbin/rsyslogd: Relink `/usr/lib/x86_64-linux-gnu/libfastjson.so.4' with `/usr/lib/x86_64-linux-gnu/libm.so.6' for IFUNC symbol `modf'
Segmentation fault
failed!
* What exactly did you do (or not do) that was effective (or
ineffective)?
Downgrading libfastjson4 to 0.99.9-1 enabled rsyslog to run alright.
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Which version of rsyslog are you using? Can you please attach the output of reportbug --template rsyslog I also notice that 0.99.9-1 is from oldoldstable. At the same time you are running forky/sid plus libc6 from experimental. This appears like an odd mix and reminds me of https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian Needless to say, that I can not reproduce the issue. Can you reproduce the issue in a clean/fresh installation of Debian sid? Please also provide a backtrace of the crash https://wiki.debian.org/HowToGetABacktrace Am 07.09.25 um 15:34 schrieb Arthur Marsh:
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
Hi by downgrading libc6 and related packages to 2.41-12, I was able to use
rsyslogd with version 1.2304.0-2 libfastjson4.
Please close the bug.
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Am 10.09.25 um 02:44 schrieb Arthur Marsh: Ok, doing so. If you want to see this further investigated, you will need to provide the requested information Michael
Michael, Today another Devuan report of this same issue was submitted[1]. Investigating further, the underlying cause appears to have been reported and fixed upstream[2]. As far as I can understand from the various Devuan, Artix and Gentoo reports, the failure is only evident on rsyslog builds without systemd using libc 2.42 which changed its modf() implementation and now requires explicit -lm linking. This explains you being unable to reproduce the issue on Debian. It would be a great help if you could cherry pick the upstream fix. Or I am happy to NMU if you would prefer? Thanks Mark [1] https://bugs.devuan.org/929 [2] https://github.com/rsyslog/libfastjson/pull/167
Am 04.12.25 um 20:10 schrieb Mark Hindley:
rsyslog links directly against -lm
librsyslog_la_LIBADD = $(DL_LIBS) $(RT_LIBS) $(LIBUUID_LIBS)
$(LIBFASTJSON_LIBS) ${LIBESTR_LIBS} -lm
and also
$ objdump -x /usr/sbin/rsyslogd | grep NEEDED | grep libm
NEEDED libm.so.6
If rsyslog crashes on Devuan, it's likely a downstream problem and I
would appreciate that you don't ask Devuan users to file bug reports
against Debian packages if the problem is not reproducible in Debian.
Michael
Am 04.12.25 um 20:10 schrieb Mark Hindley: What this has to do with systemd escapses me. Please elaborate.
I don't think it has anything *directly* to do with systemd. It is merely that the common feature of all the similar reports I have seen is rsyslog having been built with --disable-libsystemd (i.e not the Debian default.) It appears to me that building in this way triggers a buggy interaction with libfastjson producing # /usr/sbin/rsyslogd -n -iNONE /usr/sbin/rsyslogd: Relink `/usr/lib/x86_64-linux-gnu/libfastjson.so.4' with `/usr/lib/x86_64-linux-gnu/libm.so.6' for IFUNC symbol `modf' Segmentation fault If this error message is taken on face value it suggests libfastjson should have an explicit linker reference to libm. It certainly doesn't appear to: $ ldd /usr/lib/x86_64-linux-gnu/libfastjson.so linux-vdso.so.1 (0x00007faac9759000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007faac9400000) /lib64/ld-linux-x86-64.so.2 (0x00007faac975b000) I have been trying to create a minimal reproducer, with no success so far. Do you have any further ideas? Best wishes Mark
Am 05.12.25 um 20:30 schrieb Mark Hindley: No, so why do you frame it as a systemd issue?
I am sorry, but I didn't. I said the common feature of the similar reports is that rsyslog is built with --disable-libsystemd. Mark
Am 05.12.25 um 20:39 schrieb Mark Hindley: To be precise, you said: "the failure is only evident on rsyslog builds without systemd" I'd be interested to know how --enable-libsystemd changes rsyslog wrt issue.
[ I presume you mean --disable-libsystemd? ] Yes, so would I, because I can't identify why that makes a difference either. Mark
Am 05.12.25 um 20:53 schrieb Mark Hindley: If you don't know, please don't make any assumptions.
I am not making any assumptions, I am identifying patterns that suggest where to look further. Mark
I have just built rsyslog in a clean Debian sid chroot. The only modification I made was: diff -u /var/cache/pbuilder/build/cow.20727/rsyslog-8.2510.0/debian/rules /tmp/rules --- /tmp/rules.orig 2025-12-05 20:03:31.253451817 +0000 +++ /var/cache/pbuilder/build/cow.20727/rsyslog-8.2510.0/debian/rules 2025-12-05 19:37:21.590953299 +0000 @@ -12,6 +12,7 @@ confflags += --enable-imptcp \ --enable-imjournal \ --enable-omjournal \ + --disable-libsystemd \ --enable-kmsg endif After the build: $ ./tools/rsyslogd -n -iNONE ./tools/rsyslogd: Relink `/usr/lib/x86_64-linux-gnu/libfastjson.so.4' with `/usr/lib/x86_64-linux-gnu/libm.so.6' for IFUNC symbol `modf' Segmentation fault ./tools/rsyslogd -n -iNONE I think that is reasonable evidence that --disable-libsystemd triggers the issue. I still don't understand why. Mark
Michael, My theory as to what is going on here follows. Libfastjson uses modf(3) as implemented in libm, but does not declare NEEDED against the library: $ grep -r modf /tmp/libfastjson/ /tmp/libfastjson/json_print.c: // needed for modf() /tmp/libfastjson/json_print.c: result = buffer_printf(buffer, (modf(jso->o.c_double.value, &dummy)==0)?"%.17g.0":"%.17g", jso->o.c_double.value); /tmp/libfastjson/json_object.c: double dummy; /* needed for modf() */ /tmp/libfastjson/json_object.c: (modf(jso->o.c_double.value, &dummy)==0)?"%.17g.0":"%.17g", $ objdump -x /usr/lib/x86_64-linux-gnu/libfastjson.so | grep NEEDED NEEDED libc.so.6 The default Debian build of src:rsyslog links with libsystemd. $ grep LIBSYSTEMD_LIBS rsyslog/configure.ac RSRT_LIBS="\$(RSRT_LIBS1) \$(LIBESTR_LIBS) \$(LIBFASTJSON_LIBS) \$(LIBSYSTEMD_LIBS)" LIBSYSTEMD_LIBS is specified *after* LIBFASTJSON_LIBS and contains -lsystemd. Libsystemd.so itself NEEDS libm and so at compile time the correct modf() implementation is linked and all is well. $ objdump -x /usr/lib/x86_64-linux-gnu/libsystemd.so | grep NEEDED NEEDED libm.so.6 NEEDED libc.so.6 NEEDED ld-linux-x86-64.so.2 When building rsyslog without libsystemd (--disable-libsystemd), LIBSYSTEMD_LIBS is empty. Although rsyslog specifies -lm, it is *before* -lfastjson. So in lines such as this: libtool: link: gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/rsyslog-8.2510.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wl,-z -Wl,relro -Wl,-z -Wl,now -o rsyslogd rsyslogd-syslogd.o rsyslogd-rsyslogd.o rsyslogd-omshell.o rsyslogd-omusrmsg.o rsyslogd-omfwd.o rsyslogd-omfile.o rsyslogd-ompipe.o rsyslogd-omdiscard.o rsyslogd-pmrfc5424.o rsyslogd-pmrfc3164.o rsyslogd-smtradfile.o rsyslogd-smfile.o rsyslogd-smfwd.o rsyslogd-smtradfwd.o rsyslogd-iminternal.o -Wl,--export-dynamic ../grammar/.libs/libgrammar.a ../compat/.libs/compat.a -lz -lpthread ../runtime/.libs/librsyslog.a -lm -lestr -lfastjson -luuid modf() in libfastjson is not resolved and this produces the IFUNC runtime error observed. /usr/sbin/rsyslogd: Relink `/usr/lib/x86_64-linux-gnu/libfastjson.so.4' with `/usr/lib/x86_64-linux-gnu/libm.so.6' for IFUNC symbol `modf' There apear to be 2 possible fixes: 1) Add -lm to libfastjson.pc, as implemented in the current upstream fix. 2) Rebuild libfastjson with explicit -lm linkage as suggested by the error message. To me, 2) makes more sense; surely it is libfastjson's responsibility to link the correct symbols? Adding the following patch to libfastjson, adds the correct libm NEEDED + diff -u /tmp/libfastjson/Makefile.am /var/cache/pbuilder/build/cow.393/libfastjson-1.2304.0/Makefile.am --- /tmp/libfastjson/Makefile.am 2025-12-05 16:35:42.382689052 +0000 +++ /var/cache/pbuilder/build/cow.393/libfastjson-1.2304.0/Makefile.am 2025-12-08 08:24:40.794398879 +0000 @@ -1,4 +1,3 @@ - EXTRA_DIST = README.html SUBDIRS = . tests @@ -27,7 +26,7 @@ -export-symbols-regex '^fjson_.*' \ -no-undefined \ @JSON_BSYMBOLIC_LDFLAGS@ -libfastjson_la_LIBADD = libfastjson-internal.la +libfastjson_la_LIBADD = libfastjson-internal.la -lm libfastjson_la_SOURCES = \ json_version.c \ $ objdump -x /libfastjson-1.2304.0/.libs/libfastjson.so | grep NEEDED NEEDED libm.so.6 NEEDED libc.so.6 and rebuilding rsyslog without libsystemd against the patched libfastjson $ objdump -x tools/rsyslogd|grep NEEDED NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libestr.so.0 NEEDED libfastjson.so.4 NEEDED libuuid.so.1 NEEDED libc.so.6 no longer produces a runtime error. Which solution do you prefer? Best wishes Mark
running: patchelf --add-needed libm.so.6 /usr/lib/x86_64-linux-gnu/libfastjson.so.4.3.0 allows rsyslog to start.