Properly track resv->[core_cnt|node_cnt] memory.
Testing with valgrind I found some cases where memory leaked or program got SIGSEV. This was due to bad memory tracking of these resv_desc_msg_t members. Some example requests that now end up with the expected behavior and no memory errors nor leaked memory: scontrol create reservationname=test start=now end=now+1day users=alex ... - nodecnt=2 - nodecnt=badvalue - nodecnt=2 tres=node=1 - nodecnt=2 tres=node=badvalue - corecnt=1 - corecnt=badvalue - corecnt=1 tres=cpu=2 - corecnt=1 tres=cpu=badvalue sview reservation creation/update. Ideally we should use slurm_free_resv_desc_msg() instead of tracking each resv_desc_msg_t member separately, but this function unconditionally xfrees each member, even if they have a value but memory was not allocated, thus receiving a SIGABRT. Bug 2329
Please register or sign in to comment