-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[b4.4] Fix "fill" handling in static decomposition #1500
[b4.4] Fix "fill" handling in static decomposition #1500
Conversation
If "fill" was correctly specified, `cfg_col->fill` will have a value. Otherwise, `cfg-col->fill` will be `NULL`. We should use `cfg_col->fill` to determine if "fill" was present.
The "fill" string value was handled incorrectly. This patch fixes the bug.
Still broken, but in a different way:
Error message isn't terribly helpful. I am not sure what it isn't liking. |
@morrone can I see your config? |
@morrone never mind me. It was an incorrect assertion that |
- Adress the issue that the static decomposition incorrectly set `LDMS_V_LIST` as type of the column when "type" was not specified in the config. - In the case of multiple lists with different length in a set, the number of produced rows equals to the number of the longest list. When the shorter lists are exhausted, the "fill" value of the respective column is used. However, if "fill" was not specified, `ldmsd` crashed due to `NULL` fill mval. This patch uses a `zfill` (zero value) as a fall back if "fill" was not specified.
@morrone Could you please give this another whirl? |
@narategithub It looks like there are no longer any errors thrown with my config and your latest fix. My testbed is slightly broken (networking issues) at the moment, so I can't quite check the full decomposition output for correctness. But I can see that my "cluster" default fill is at least working, so that is a good sign. |
Thank you, @morrone ! |
This PR addressed #1495 . This PR (with #1498 and #1499) has been tested with these test cases in
ldms-test
repo (branchb4.4
):