Re: execinfo: Add tests.

[Collin Funk]

Hi Bruno,

On 5/12/24 3:43 AM, Bruno Haible wrote:
> Reading through your test, I notice that when size == 0 && symbols != NULL,
> the symbols pointer is not freed. So I went to look deeper.
> 
> Reading through the documentation at
> https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
> I found the following opportunities that can be tested in a unit test:
>   - backtrace: "The return value is the actual number of entries of buffer
>     that are obtained, and is at most size." This is something that can be 
> tested.
>   - backtrace_symbols: "The return value of backtrace_symbols is a pointer 
> obtained
>     via the malloc function ... The return value is NULL if sufficient memory 
> for
>     the strings cannot be obtained." Since in unit tests, out-of-memory can be
>     assumed to not happen, we can check that the return value is != NULL.
>   - backtrace_symbols: "The return value is a pointer to an array of strings,
>     which has size entries just like the array buffer" This sounds like we can
>     pass a too-small buffer, and the stack trace will be truncated. This can 
> be
>     tested as well.
>   - The third function, backtrace_symbols_fd, is not tested.

Oops, yes you are correct. Thanks for improving the tests. I have
never used these functions before so I am not surprised I made a
mistake...

The reasoning for printing the backtrace was so that the output can be
compared with the BSD implementation or various linker flags, etc.
Seemed like it might be helpful.

I left backtrace_symbols_fd untested because I did not see too much
benefit in testing it. Its job is similar enough to backtrace_symbols
but would require thinking about module dependencies and headers for
create () and unlink (), or similar.

> Note the change in the module description. If we want to verify that there is
> an AC_SUBST for LIB_EXECINFO, the way to do it is to write @LIB_EXECINFO@.
> If the AC_SUBST was missing, $(LIB_EXECINFO) would come out as empty whereas
> @LIB_EXECINFO@ would lead to a build failure.

Ah, thanks for the explanation. When writing the module description I
was a bit confused why some tests used @LIB_NAME@ instead of
$(LIB_NAME). Looks like my guess was unlucky, but now I know for next
time. :)

Collin