Could happen if the switch statement hit the default.
Was originally this way in ca682973

as stated in README.
Was originally this way in ca682973

relies on the primary to do so.

There is a potential race condition if the backup DBD tries to create/check the
database at the same time as the primary.  This patch removes this race by not
allowing the backup to do the check/create.

Bug 3827

Coverity CID 171481

Coverity CID 45152

Coverity CID 44923

Coverity CID 44802

Coverity 44943, 44944

Coverity CID 44941, 44942

Starting in MariaDB 10.2 many of the api commands started
setting errno erroneously.

Looks like it was used as test program.

Test was sporadically failing on smd without sleep

bug 4095

Coverity CID 166003

Coverity CID 44775

Coverity CID 44723

Corrections needed for variable type change in commit
91c847c1

This is needed to check range check for over/underflow by strtol.
Coverity CID 44779

Coverity CID 44776, 44777

Test was expecting the job name to be 'sh', when it may be 'bash'
or some other shell. Tweak the regex appropriately.

Bug 4110.

No real changes in logic
Coverity CID 44667, 44703, 44883, 153385

history.

Bug 4095

Testing if curl_handle != NULL or rc != SLURM_SUCCESS was already done
in the right above if/else statements, jumping to the consequent goto
cleanup label if needed. Thus the removed test was never going to be
evaluated to true, and Coverity properly warned about this.

Regression introduced in commit 5f5e6472 (code cleanup).

Calling bit_unfmt() with a zero bit_size() bitmap leads to a later
call to bit_nclear() with start=0 and stop=-1, leading to the ABRT.

This scenario happened when cgroup.conf has ConstrainDevices=yes and
task_cgroup_devices_create() tries to collect the GRES devices
but gres_cpu_cnt=0, thus creating a p->cpus_bitmap = bit_alloc(gres_cpu_cnt);
of zero size which is passed by argument to bit_unfmt().

gres_cpu_cnt is 0 because we have defined a gres.conf like this:

Name=gpu Type=tesla File=/tmp/gres/tesla0 CPUs=0,1
Name=gpu Type=tesla File=/tmp/gres/tesla1 CPUs=0,1
Name=gpu Type=kepler File=/tmp/gres/kepler0 CPUs=2,3
Name=gpu Type=kepler File=/tmp/gres/kepler1 CPUs=2,3

but have no GresTypes nor GRES option in the slurm.conf / node config def.

Bug 3974

Bug 3217

Running slurmctld under valgrind while operating with jobcomp/elasticsearch
reported the following bytes definitely lost:

==27403== 658 bytes in 1 blocks are definitely lost in loss record 301 of 342
==27403==    at 0x4C2FD4F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27403==    by 0x2281B3: slurm_xrealloc (xmalloc.c:137)
==27403==    by 0x22856A: makespace (xstring.c:114)
==27403==    by 0x2285D0: _xstrcat (xstring.c:132)
==27403==    by 0x228CE0: _xstrfmtcat (xstring.c:291)
==27403==    by 0x83C5BCD: ???
==27403==    by 0x30A913: g_slurm_jobcomp_write (slurm_jobcomp.c:172)
==27403==    by 0x18D8FC: job_completion_logger (job_mgr.c:13652)

It turns out the generated buffer in slurm_jobcomp_log_record was xstrdup'ed to
the corresponding job_node->serialized_job, but the originally generated buffer
wasn't freed afterwards. The fix consists in change the transfer so that instead
of xstrdup'ing the char * we just assign the pointer and NULL the buffer.

The job_node->serialized_job was already xfree'd properly later when the job
was indexed.

Discovered while working on Bug 4065.

This should only happen due to ESLURM_RESULT_TOO_LARGE,
which leads to no list being packed.

Follow on to 390da8cf / 8cf1835c.

Bug 3624.