HP-UX 11iv2 (11.23) on Itanium

Zabbix agent 5.0.38rc1 works as expected - this is partially correct: it does not crash on "zabbix_agentd -p".
It could be HP-UX 11iv2 (11.23) specific as ZBX-20417 shows that vfs.file.get[] works normally in HP-UX 11iv3.

The crash is caused by HP-UX vsnprintf(), not conforming to standards.

Crash happens, when Zabbix agent calls get_dir_names(), which calls canonicalize_path(), which calls zbx_snprintf_alloc() where is

*alloc_len = vsnprintf(NULL, 0, fmt, args) + 2; /* '\0' + one byte to prevent the operation retry */

vsnprintf(NULL, 0, fmt, args) causes crash (it works as documented on other operating systems).

https://stackoverflow.com/questions/619497/heap-corruption-in-hp-ux provides some insight to the problem on HP UX 11.11 and a possible workaround.

It is not clear can it be solved by applying vendor patches for HP-UX (I think a commercial support contract is required).

Attachment vsnprintf_test.c demonstrates crash on vsnprintf(NULL, 0, ...).
Attachment vsnprintf_test2.c demonstrates what vsnprintf(buf, sizeof(buf),...) returns depending on buffer size.
Attachment vsnprintf_test3.c demonstrates possible workaround.

I do not understand how it could be that the issue is not happening on 5.0.38rc1:

$ git describe --tags
5.0.38rc1
$ grep actually src/libs/zbxcommon/str.c -B7 -A3
void    zbx_snprintf_alloc(char **str, size_t *alloc_len, size_t *offset, const char *fmt, ...)
{
        va_list args;
        size_t  avail_len, written_len;
retry:
        if (NULL == *str)
        {
                /* zbx_vsnprintf() returns bytes actually written instead of bytes to write, */
                /* so we have to use the standard function                                   */
                va_start(args, fmt);
                *alloc_len = vsnprintf(NULL, 0, fmt, args) + 2; /* '\0' + one byte to prevent the operation retry */

And the master:

$ grep actually src/libs/zbxcommon/common_str.c -B11 -A2
void    zbx_snprintf_alloc(char **str, size_t *alloc_len, size_t *offset, const char *fmt, ...)
{
        va_list args;
        size_t  avail_len, written_len;
retry:
        if (NULL == *str)
        {
                int     rv;


                va_start(args, fmt);


                /* zbx_vsnprintf() returns bytes actually written instead of bytes to write, */
                /* so we have to use the standard function                                   */
                if (0 > (rv = zbx_vsnprintf_check_len(fmt, args))) 

To me there is basically no difference?

<andris> My statement about 5.0.38rc1 was based on observation that 5.0.38rc1 does not crash on "zabbix_agentd -p". zbx_snprintf_alloc() in 5.0.38rc1 will crash on vsnprintf(NULL, 0, fmt, args).

<dimir> There. So, in which version did the problem appear? According to my calculations it's this one which was released in 2.1.0 .

<andris> This can be an explanation:

$ man vsnprintf
...
STANDARDS
fprintf(), printf(), sprintf(), snprintf(), vprintf(), vfprintf(), vsprintf(), vsnprintf(): POSIX.1‐2001, POSIX.1‐2008, C99.
...
Concerning the return value of snprintf(), SUSv2 and C99 contradict each other: when snprintf() is called with size=0 then SUSv2 stipulates an unspecified return value less than 1, while C99 allows str to be NULL in this case, and gives the return value (as always) as the number of characters that would have been written in case the output string has been large enough. POSIX.1‐2001 and later align their specification of snprintf() with C99.

Looks like HP-UX 11.31 provides C99-style vsnprintf(), but HP-UX 11.23 - kind of pre-C99-style vsnprintf().

Actually, vfs.file.get does not even exist in 5.0. It was added in 6.0

Available in versions:

• pre-6.0.23rc1 52c033dce1b
• pre-6.4.8rc1 f39c83b8168
• pre-7.0.0alpha7 f460ae1a892