Skip to content

Static analysis / memory fixes#4082

Open
clumens wants to merge 14 commits intoClusterLabs:mainfrom
clumens:prerelease
Open

Static analysis / memory fixes#4082
clumens wants to merge 14 commits intoClusterLabs:mainfrom
clumens:prerelease

Conversation

@clumens
Copy link
Copy Markdown
Contributor

@clumens clumens commented Apr 13, 2026

These are fixes for issues found by static analysis. There are still three outstanding results from clang that I haven't decided what to do about (if anything):

  • pcmk__is_anonymous_clone - It thinks rsc->flags is a NULL pointer dereference, which is impossible.
  • tools/crm_resource.c:2086 - It thinks args->verbosity is a NULL pointer dereference, which is impossible. pcmk__new_common_args exits on error.
  • get_capable_devices - It thinks we're leaking search, which is pretty hard to decide if that's the case or not.

clumens added 13 commits April 13, 2026 11:44
Telling it to use the same number of threads as in cts-cli (one fewer
than the number of processors) speeds it up dramatically.
It shouldn't be, but clang's static analysis gets tripped up thinking
it's possible, so we might as well add a check.
…rwrite.

I think the idea here was to make sure that 'type' would always have
something set, just in case the pcmk__graph_next enum gained some more
values.  However, we have the compiler flags enabled to warn about that
so there should be no way through the switch statement without setting
it to something.
It was complaining that 'text' was getting set and then immediately
overwritten with some other value.  This can be solved by just getting
rid of the variable.
These shouldn't be strictly necessary, but clang can't figure them out
and thinks NULL pointer dereferences are possible.  In general, I'm not
a fan of adding these sorts of obvious checks.  On the other hand, I'm
less a fan of having static analysis enabled but then ignoring its
results.
If fopen returns success, errno will be undefined.  If getline reads a
file that is empty, the loop will never get a chance to set errno to 0,
in which case the test will be checking an undefined value.  Instead,
rearrange the loop so that errno is always set to 0.
Telling it to use the same number of threads as in cts-cli (one fewer
than the number of processors) speeds it up dramatically.
…ode.

I'm not sure whether or not this is a real bug.  The IPC client freeing
code is a little bit of a mess so it's hard to tell.  However, clang
thinks there is something here so just to be safe, check that api is
not NULL before freeing it.
We don't want to assign the return value of g_list_append back into the
hash table (note the comments above), but assigning its value to the
list variable causes static analysis to complain about a dead
assignment.  Just turn off the warning for this one line.
…plies.

Multiple static analysis tools think that it's impossible to reach the
pcmk__rsc_trace call at the bottom with reason still set to its initial
value of "allowed".  I'm not convinced of that, but regardless we can
still avoid the dead assignment by using pcmk__s instead.
Static analysis can't figure out that filename can't be NULL in the else
block, so I'm just going to add a test ahead of time.  In general I
dislike rearranging code like this just to please static analysis tools,
but I prefer doing that to having useless results full of false
positives.
This function has a nested fgets loop for reading long descriptions that
extend over multiple lines.  If the inner fgets hits EOF or an error,
it'll just continue and the outer fgets will be in some indeterminate
state.  Instead, handle those possibilities.

I think there's likely a lot that could be done to this function to make
it more robust, but this will have to do for now.
@nrwahl2
Copy link
Copy Markdown
Contributor

nrwahl2 commented Apr 13, 2026

get_capable_devices - It thinks we're leaking search, which is pretty hard to decide if that's the case or not.

This looks possible, but even if not, the code could use some clarifying. get_capable_devices() -> fenced_foreach_device() -> search_devices() -> can_fence_host_with_device() -> search_devices_record_result() frees search when search has received all the replies it needs. I doubt this is guaranteed to happen. It might be, but again, it's not obvious.

@clumens clumens changed the title Static analysis fixes Static analysis / memory fixes Apr 14, 2026
@clumens
Copy link
Copy Markdown
Contributor Author

clumens commented Apr 14, 2026

The last patch addresses memory leaks from running multiple 10-run ctslab sessions through valgrind. It is definitely not an exhaustive check of memory leaks by any means (perhaps I should also run regression tests through it), but I think it's going to catch the most important leak. The only other things that valgrind reports are things we already knew about but haven't been able to address, for instance:

==8592== 525 (88 direct, 437 indirect) bytes in 1 blocks are definitely lost in loss record 148 of 153
==8592==    at 0x484C214: calloc (vg_replace_malloc.c:1675)
==8592==    by 0x49F1CC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6800.4)
==8592==    by 0x49F1D07: g_option_context_new (in /usr/lib64/libglib-2.0.so.0.6800.4)
==8592==    by 0x48B3E5D: pcmk__build_arg_context (cmdline.c:84)
==8592==    by 0x10D3E3: UnknownInlinedFun (pacemaker-execd.c:315)
==8592==    by 0x10D3E3: main (pacemaker-execd.c:348)
==8592== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:calloc
   fun:g_malloc0
   fun:g_option_context_new
   fun:pcmk__build_arg_context
   fun:UnknownInlinedFun
   fun:main
}
==8592== LEAK SUMMARY:
==8592==    definitely lost: 88 bytes in 1 blocks
==8592==    indirectly lost: 437 bytes in 6 blocks
==8592==      possibly lost: 107 bytes in 2 blocks
==8592==    still reachable: 16,516 bytes in 158 blocks
==8592==         suppressed: 18,900 bytes in 12 blocks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants