logging: Remove linker 'magic' and just use statics for logging callsites

[chrissie-c]

It is my (and several others') opinion that the linker 'magic' used to maintain callsite data in libqb is hugely over complicated and unnecessarily fragile. It's main purpose seems to have been to improve performance but empirical testing shows this to be tiny at best. The overhead of sprintf makes minor optimisations in this code pointless.

With this code removed, libqb allocates callsites using a C static variable at run-time. This sounds bad but in actuality it merely moves the allocation from program load time to the first few milliseconds of program run-time. Applications like corosync and pacemaker spend most of their time in small loops doing the same work over and over again so the overhead doesn't apply and jitter does not occur.

We've tested this with corosync and pacemaker under valgrind and massif and the differences are minimal and even then only show up under artificial stress testing.

For this change I've bumped the soname up to 20 to indicate this is an incompatible change. I'm open to suggestions as to a release number but am currently thinking of 1.2.0

[jnpkrn]

Once more, opinion != hard data.

The justification is unsound to say the least.

it merely moves the allocation from program load time to the first few
milliseconds of program run-time

I beg your pardon?
/me still can't believe this doubly misled statement

---

Are there actual persistent issues around this feature? Let's fix them.

Is any client program too worry to run into problems?
Ok, libqb.pc explains how to compatibly drop that feature for that
very program, and not universally, which would break the compatibility
for everyone. Do you want a specific libqb-nostaticlogdata.pc to
ease that?

---

Come on, point me at any project and I am confident I can find a feature
that can be dropped while retaining the core. That's easy, very little
effort is needed (as opposed to pushing the limits smartly, which is
exactly how I'd identify the callsite section utilization).

But it always comes at cost of something else, here:

• run-time efficiency and instruction count hence realtime-like
  predictability

• ability to develop some even more efficient extension, see
  [RFE] "nanoblackbox" feature that could be appealing for stable-binary-packages-driven distros #274 for an idea

• ...

• indirect checking that some logging inputs (e.g. a format string) are
  compile-time constants, hence assuring additional assumptions wrt.
  using of libqb's logging

[fabbione]

ack from me.

[jfriesse]

count me in the queue of ackers, so ACK

[jnpkrn]

Add one more disruption to already a long list why this is basically
reliability alienation:

• when some call fails for out-of-memory condition and proceeds to
  at least log about this possibly recoverable problem, it will
  now exteremely likely fail doing it that as well

Congrats!

[gao-yan]

Thanks for the solution. Is there any plan when to release a new version with this?

It appears dlm_stonith is basically broken with libqb-1.0.3:

# dlm_stonith -n 172204701
dlm_stonith: utils.c:55: common: Assertion `"implicit callsite section is observable, otherwise target's and/or libqb's build is at fault, preventing reliable logging" && work_s1 != NULL && work_s2 != NULL' failed.
Aborted (core dumped)

[chrissie-c]

Rebuilding dlm might fix that.

I'm going to start on a 2.0rc series shortly. Once we get the hi-res timestamps merged I think.

[gao-yan]

Thanks for the information.

It was rebuilt but didn't work. But now I realized dlm_stonith calls stonith_api_kick_helper() but it's not explicitly linked with libstonithd according to the Makefile. No idea why, but it's probably relevant...

[gao-yan]

Oh, well, stonith_api_kick_helper() is an inline function from pacemaker's stonith-ng.h header file which manipulates stuff with dlopen() and dlsym(). This doesn't seem to work with libqb-1.0.3 though.

[GitSoftwareNow]

@jfriesse which version of libqb is correct?

[GitSoftwareNow]

@jfriesse which version of libqb is the corosync 3.0.2 relayed?

[jfriesse]

@GitSoftwareNow Corosync works with most of the versions, but you must keep in sync the installed version and version which is corosync linked with. Currently I wouldn't be to hesitate to recommend current git master.

Also please consider to use corosync issue you've opened for other questions, because commenting under already merged libqb PR is not optimal.