[there's no category in the bug tracker for libassuan, so I'm using gnupg]
I just built libassuan 2.1.0 on x86_64-sun-solaris2.10 with the no-cost Oracle
Workshop 12.2 compiler toolchain.
The pipeconnect and fdpassing tests segfault. After rebuilding with debug
symbols, the segfaults happen in the internal vasprintf:
$dbx .libs/fdpassing core
Reading fdpassing
core file header read successfully
Reading ld.so.1
Reading libassuan.so.0.4.0
Reading libgpg-error.so.0.8.0
Reading libintl.so.8.1.1
Reading libc.so.1
Reading libsocket.so.1
Reading libnsl.so.1
program terminated by signal SEGV (no mapping at the fault address)
Current function is int_vasprintf
126 char *tmp = va_arg (ap, char *);
(dbx) where
>[1] int_vasprintf(result = 0xfffffd7fffdfda28, format = 0x7ffffff7dbd8 "%s
(%s=%p): enter: err_source = %i (%s), malloc_hooks = %p (%p, %p, %p), log_cb =
%p, log_cb_data = %p\n", args = 0xfffffd7fffdfd908), line 126 in "vasprintf.c"
[2] _assuan_vasprintf(result = 0xfffffd7fffdfda28, format = 0x7ffffff7dbd8 "%s
(%s=%p): enter: err_source = %i (%s), malloc_hooks = %p (%p, %p, %p), log_cb =
%p, log_cb_data = %p\n", args = 0xfffffd7fffdfda38), line 157 in "vasprintf.c"
[3] _assuan_debug(ctx = 0xfffffd7fffdfdb20, cat = 2U, format = 0x7ffffff7dbd8
"%s (%s=%p): enter: err_source = %i (%s), malloc_hooks = %p (%p, %p, %p), log_cb
%p, log_cb_data = %p\n", ... = 0x7ffffff410a0, ...), line 59 in "debug.c"
[4] assuan_new_ext(r_ctx = 0xfffffd7fffdfeb10, err_source =
GPG_ERR_SOURCE_USER_1, malloc_hooks = 0x7ffffff8fb50, log_cb = 0x7ffffff7acf0 =
&_assuan_log_handler(), log_cb_data = (nil)), line 131 in "assuan.c"
[5] assuan_new(r_ctx = 0xfffffd7fffdfeb10), line 163 in "assuan.c" [6] main(argc = 0, argv = 0xfffffd7fffdfeb60), line 287 in "fdpassing.c"
As a first test, I hacked src/vasprintf.c so that instead of having
_assuan_vasprintf call int_vasprintf, I had it call g_vasprintf from glib.
While doing that, I got a warning from the compiler that the third argument
to g_vasprintf was incorrect. Looking back through the compilation logs, I see
that there was a similar warning when building using int_vasprintf:
libtool: compile: cc -xipo=2 -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I/loca
l/include -I/local/gnu/include -Xa -xO4 -xstrconst -KPIC -xtarget=generic -m64 -
xarch=generic -I/local/include -I/local/gnu/include -c vasprintf.c -KPIC -DPIC
-o .libs/vasprintf.o
"vasprintf.c", line 157: warning: argument #3 is incompatible with prototype:
prototype: pointer to array[1] of struct __va_list_element {unsigned int __va_gp_offset, unsigned int va_fp_offset, pointer to void va_overflow_arg_area
, pointer to void __va_reg_sve_area} : "vasprintf.c", line 50
argument : pointer to pointer to struct __va_list_element {unsigned int __va_gp_offset, unsigned int va_fp_offset, pointer to void va_overflow_arg_area,
pointer to void __va_reg_sve_area}
If I remove the & from args in the call to int_vasprintf, the tests all pass,
whether I use the internal int_vasprintf or the g_vasprintf from glib.
I can provide a patch if needed, if you believe that the change is the correct one.