Bug in libldmsd_plugattr implementation of new logging infrastructure

[Christopher J. Morrone]

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.

[nichamon]

@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.

[Tom Tucker]

@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.

[Benjamin Allan]

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.

[Tom Tucker]

@morrone, to confirm the code builds, but when you attempt to load the plugin it fails due to an unresolved symbol. Is this correct?

[nichamon]

@tom95858 @morrone I could build and load store_csv without problems. store_csv links to ldmsd_plugattr and calls its APIs. FYI, the build flags I used were -ggdb3 -O0 -Werror -Wall.

[Christopher J. Morrone]

@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.

[Christopher J. Morrone]

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.

[nichamon]

@morrone Ah ... I see. I was unaware that a stand-alone program uses the ldmsd_plugattr library. I created PR #1250 to fix the build problem.

[Christopher J. Morrone]

Yes, it does compile now. Thanks!