Handle possible null pointers from malloc/strdup/strndup()
commit72c99dc95961c1a91a1504173fd447f92f73ad50
authorRichard Yao <richard.yao@alumni.stonybrook.edu>
Fri, 7 Oct 2022 00:18:40 +0000 (6 20:18 -0400)
committerGitHub <noreply@github.com>
Fri, 7 Oct 2022 00:18:40 +0000 (6 17:18 -0700)
treec2a7d69e7773e5ee4da3ac8b6bcac507e1363de0
parent2ba240f3583e421e87ca3c5be0fb6146bf9c3f07
Handle possible null pointers from malloc/strdup/strndup()

GCC 12.1.1_p20220625's static analyzer caught these.

Of the two in the btree test, one had previously been caught by Coverity
and Smatch, but GCC flagged it as a false positive. Upon examining how
other test cases handle this, the solution was changed from
`ASSERT3P(node, !=, NULL);` to using `perror()` to be consistent with
the fixes to the other fixes done to the ZTS code.

That approach was also used in ZED since I did not see a better way of
handling this there. Also, upon inspection, additional unchecked
pointers from malloc()/calloc()/strdup() were found in ZED, so those
were handled too.

In other parts of the code, the existing methods to avoid issues from
memory allocators returning NULL were used, such as using
`umem_alloc(size, UMEM_NOFAIL)` or returning `ENOMEM`.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Closes #13979
cmd/zed/agents/fmd_serd.c
cmd/zed/agents/zfs_mod.c
cmd/zed/zed_exec.c
cmd/ztest.c
lib/libzfs/libzfs_sendrecv.c
lib/libzutil/zutil_import.c
tests/zfs-tests/cmd/badsend.c
tests/zfs-tests/cmd/btree_test.c
tests/zfs-tests/cmd/file/largest_file.c
tests/zfs-tests/cmd/nvlist_to_lua.c