Using `caPutLogShow` after `caPutJsonLogInit` causes segfault

[anderslindho]

This may be true also for other similar invalid combinations - I have not tested.

[anjohnson]

Thanks for this report. Issue #10 was about whether IOCs should be able to support both logging formats simultaneously and is thus related to this. I recommend not including both caPutLog.dbd and caPutJsonLog.dbd when building an IOC, which will prevent both the JSON and non-JSON put-logging commands from being available at the same time.

My original assumption when specifying the JSON support was that an IOC would only use one or the other logging format, and that configuring which one could be done at IOC build time by including the appropriate DBD file, although the build system doesn't currently prevent both from being included. I suspect the simplest way to prevent segfaults would be to modify the module to make it impossible to link a binary executable that includes both.

If there is a site that wants to log in both formats at the same time, or to be able to select which format to use at runtime then some more development will be needed to allow that or prevent misuse that will cause this segfault. Is that something you need?

[anderslindho]

We (ESS) have no need for that, and we can (and will) just exclude caPutLog.dbd since all our IOCs load the module through the same process; I just didn't think of that when switching the format. For our setup this is thus easily enough resolved - I mainly wanted to report this upstream, so to speak. I think mitigating misuse is the only real value here, so making it impossible to link when both are included seems like a good option.

[anjohnson]

Thanks.

My original approach fails because ESS and PSI need load the code from a shared library, which requires both sets of support code to be linked into that shared library, but that wasn't supposed to be possible. My idea works if I only build the static libcaPutLog.a library, but that's no use to you.

I could add a second library that provides the JSON support, but that would require the IOC Makefile to pick a matching DBD file and library, and existing JSON users would have to fix all their IOC builds. I want existing IOC Makefiles that are configured correctly (with only one of the two DBD files) to continue to work without having to be changed.

Thus I'm working on only allowing one set of commands to be registered. I can't think of a way to prevent both DBD files from being included though, so I don't think I can report that as an error at IOC build time. The generated *_registerRecordDeviceDriver() routine normally calls registrars in alphabetical order (meaning that the JSON commands will win for IOCs that are built with both DBD files), although the order might be different for ESS and PSI builds, so I won't rely on that. If both registration routines are run or the "wrong" Init command is used an error will be logged explaining how to fix the problem, while the other "wrong" commands just won't be recognized by iocsh.

A PR for this will follow fairly soon.