Bug in libldmsd_plugattr implementation of new logging infrastructure
morrone opened this issue · comments
If I am understanding things correctly, it looks to me like there is a bug in how the new logging infrastructure was added to ldmsd_plugattr.
In ldmsd_plugattr.c, the following was added:
/* Defined in ldmsd.c */
extern ovis_log_t config_log;
If this was something internal to the ldmsd, that would have been fine. But ldmsd_plugattr.c is not part of ldmsd; it is built into libldmsd_plugattr, and used as a library by various plugins.
This is currently breaking the build for ibnet, and probably other plugins that use plugattr.
I think the proper approach is to change the libldmsd_plugattr API to have each function accept an additional ovis_log_t parameter.
@morrone Thanks for pointing this out. I'll be traveling this week, so I should have a patch to fix this by the end of the week.
@morrone, @nichamon it looks to me like although a number of plugins bind with this library, only store_csv uses the library for any other function than ldmsd_plugattr_config_check. I think as a general rule having a low-level library logging messages is a bad idea...and this library logs a lot of messages.
So as part of this, I would ask that we consider pulling the one function that multiple plugins use (i.e. ldmsd_plugattr_config_check) into libldmsd if we really think this function is useful and take the remainder of the library and put it in store_csv as it is the only consumer of the remaining services.
I wouldn't call having messages for a library that carefully parses and validates 12+ types and diagnoses user input "a lot of messages". We have used things like atoi (and all its poor assumptions) in a lot of places that should be coded with this kind of functionality (ldmsd_plugattr_s32, etc) instead. The ldmsd_plugattr_$type functions could also be moved into (renamed) util.h to provide parsing, validation, and diagnosis directly via the av_list api.
But that said, Chris's/Tom's original point is valid; either we pass in the log pointer or we correctly define a separate logging instance or we split the entire functionality between core ldmsd and util.h (with a log pointer passed in). Not losing the line-number context in messages is important, whatever the solution is.
@morrone, to confirm the code builds, but when you attempt to load the plugin it fails due to an unresolved symbol. Is this correct?
@tom95858, ibnet fails at build time, not later at plugin load time. Since the build didn't finish, I couldn't go any further than that.
Oh, I'm sorry, it looks like it is specifically breaking the build at ldms_ibnet_schema_name (ibnet_data.c):
make[5]: Entering directory '/g/g0/morrone/src/ovis/OVIS-4/ldms/src/sampler/ibnet'
CC ldms_ibnet_schema_name-ibnet_data.o
CCLD ldms_ibnet_schema_name
../../../../ldms/src/ldmsd/.libs/libldmsd_plugattr.so: undefined reference to `config_log'
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:761: ldms_ibnet_schema_name] Error 1
So the issue is using the library in this stand-alone app.
Yes, it does compile now. Thanks!