History data size mismatch

Issue #194 resolved
Niklaus Berger created an issue
Logging a list of variables to the history via links in the history ODB subtree,
we get messages as follows at every run start:

19:43:24.009 2019/10/06 [Logger,ERROR] [history_schema.cxx:2676:hs_write_event,ERROR] Event 'System' data size mismatch: expected 412 bytes, got 416 bytes

19:43:24.008 2019/10/06 [Logger,ERROR] [history_schema.cxx:2676:hs_write_event,ERROR] Event 'System' data size mismatch: expected 412 bytes, got 416 bytes

19:43:23.850 2019/10/06 [Logger,ERROR] [history_schema.cxx:455:hs_write_event,ERROR] Event 'System' data size mismatch count: 25, expected 412 bytes, hs_write_event() called with as much as 416 bytes

19:43:23.850 2019/10/06 [Logger,ERROR] [history_schema.cxx:455:hs_write_event,ERROR] Event 'System' data size mismatch count: 25, expected 412 bytes, hs_write_event() called with as much as 416 bytes

The history calculates the size of a record from the size of the individual variables, (history_schema.cxx, L2666 ff), whereas the ODB delivers the data aligned/padded to the size of the largest value in the record.
In our history, a long list of doubles (64 Bit) fas followed by three floats (32 bit), leading to a padded response from the ODB, 4 byte longer than the history expects.
Quick fix: Add another 32 bit dummy variable to the history. Gets rid of the error messages...
Should probably be fixed at a deeper level...

Comments (5)

  1. dd1

    I cannot reproduce this: create /History/Links/System with double,int,int,int and I see mlogger create an event with size 24 (correct: 8+4+4+4=20, plus 4 bytes of padding) and see history events with size 24, and there is no mismatch.

    But I do not understand where the 4 bytes of padding are coming from. The code hs_write_event() does not know about this padding and if it activates, computed size will be 20, not 24 and there will be errors as reported in this bug.

    K.O.

  2. dd1

    Ok, confirmed, I see same error message with “double+3 int”, I was confused because this cm_msg(MERROR) message is not printed to the terminal, it only goes into the log file.

    K.O.

  3. dd1

    confirmed same problem for /sequipment/xxx/variables with 1 double, 1 int. mismatch expected 12, got 16 bytes.

    looks like somebody is adding pad words at the end of data.

    K.O.

  4. dd1

    Indeed, there is a deeper problem, see bug #274.

    I think I was able to fix the problem in this bug without breaking anything else (except for mhdump).

    thank you for reporting this problem.

    K.O.

  5. Log in to comment