Active Exception: Unable to validate cubics library against schema with error: Invalid input json:

[Pedro Gomes]

Hello,

I've been trying to link CoolProp with a C++ code for a couple of days now.

I tried using the SourceForge binaries (6.5.0, 6.6.0, 6.8.0, and 7.0.0), and building 6.8.0 and 7.0.0 locally, on Ubuntu 24, GCC 13 (both static and shared libs, with and without the PIC option),.

I get a segfault as soon as the program starts, during the parsing of the fluid JSONs. Valgrind says it comes from rapidjson allocators.

The JSONs that are being passed to rapidjson seem valid to me, I've printed them and diff'd against the ones in dev.

I've also tried to modify the build system of our code to compile the CoolProp sources together with ours (we use Bazel, which sadly is not plug-and-play with CMake).

In doing so, I also tried hacking rapidjson to use only the C allocator (instead of their fast one that also uses the stack).

I also tried with the developement branch of rapidjson, no luck.

Any ideas of what can be going on here? Or what else I can try?

Thank you and regards,

Pedro

[Ian Bell]

Can you put together a docker container demonstrating the problem? Otherwise, I have no idea of how to help.

--
You received this message because you are subscribed to the Google Groups "coolprop-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coolprop-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/coolprop-users/db072e53-b981-4de3-8424-9d64b2390f3cn%40googlegroups.com.

[Pedro Gomes]

Thank you for the quick reply.

I think that would be more difficult than what I'll try next, which is replacing rapidjson with nlohmann.

[Ian Bell]

I started down the road of switching to nlohmann::json but it was a lot of work, even with the help of AI tools. 

To view this discussion visit https://groups.google.com/d/msgid/coolprop-users/19e40259-8bd6-418f-876a-28052d6f2f64n%40googlegroups.com.

[Pedro Gomes]

This was some kind of ABI incompatibility. Linking statically was fine, but we cannot link our application statically.

In case it helps someone else...

I was able to make it work by patching the "Pow10" function in rapidjson to just use pow(10, n) instead of a very large static lookup table.

In debug builds, I also need RAPIDJSON_DEFAULT_ALLOCATOR=::RAPIDJSON_NAMESPACE::CrtAllocator, so there may be other gremlins, but at least valgrind is clean.

While debugging, I ended up changing all fluid libraries to load the first time they are used instead of the constructor (it's hard to deal with exceptions in constructors of global variables).

I saw it was a pattern used for larger libraries. I can open a PR if this is useful.

I also noticed an #undef FMT_HEADER_ONLY in CPStrings.h, this doesn't seem to contribute to the ABI issue, but I suspect it is not 100% safe in case someone is using that option.

I'll post an update if I ever get to the root cause of this, by accident :).

Best regards,

Pedro

[Ian Bell]

Did you have your own rapidjson version not synchronized to be the same as in CoolProp? That could certainly cause issues if it did not match

To view this discussion visit https://groups.google.com/d/msgid/coolprop-users/032aee3f-4a54-4218-963d-c06244c88ebbn%40googlegroups.com.

[Pedro Gomes]

We do not knowingly have our own version of rapidjson, if another of the third-party libs we use has it, it has it silently.

(also some of my messages seem to get auto-deleted and pop up 4 days later, sorry for the late reply if that happens with this message too)

[Ian Bell]

discussion(s) has largely moved to github: https://github.com/CoolProp/CoolProp/discussions

To view this discussion visit https://groups.google.com/d/msgid/coolprop-users/c51c3224-b195-470d-952f-389bb45297e3n%40googlegroups.com.