"shared-state-async discover" hangs

[eric-j-ason]

Building and running shared-state-async on Debian results in a binary that hangs on shared-state-async discover and produces no output. The external script shared-state-async-discover does get called, so the hangup comes after that.

A workaround is to put a debug printout such as this anywhere in the body of the function closeAFD:

RS_DBG("Debug printout as a workaround");

This suggests to me that it is a memory management bug, and that the extra printout happens to change the memory layout in such a way that the bug no longer shows itself.

The problem appears in Debug, Coverage as well as Release builds, and the workaround works in all three cases.

[javierbrk]

Hi @eric-j-ason, thanks for the detailed report!

Just a few quick questions to help narrow this down:

Does the hang always occur, or is it random?

What version of the GCC compiler are you using?

What architecture are you targeting when compiling?

Thanks!

[eric-j-ason]

Sorry, I forgot to mention the compiler details. I have GCC 12.2.0 and I was going to say that I am compiling on and for x86-64, but given the following output, perhaps znver3 is the right answer.

$ gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
 /usr/lib/gcc/x86_64-linux-gnu/12/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu - -march=znver3 -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mvpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mclwb -mclzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mmwaitx -mno-pconfig -mpku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mrdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -mno-sgx -msha -mshstk -mno-tbm -mno-tsxldtrk -mvaes -mno-waitpkg -mwbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver3 -fasynchronous-unwind-tables -dumpbase -

As far as I can tell, the hang always occurs and the workaround always works.

[javierbrk]

this seems to be a problem related to the architecture/compiler mix, it is the first time someone reports this. Maybe you can create a pull request on the shared state repo.

[eric-j-ason]

this seems to be a problem related to the architecture/compiler mix, it is the first time someone reports this. Maybe you can create a pull request on the shared state repo.

All I have is the workaround that prints a debug message, and happens to make things work. Should I create a pull request of that?