TimeoutAfter_2 test failure

[tueda]

TimeoutAfter_2 failed for valgrind tvorm:

https://github.com/vermaseren/form/actions/runs/12961843378/job/36157628776

===============================================================================
TimeoutAfter_2 (features.frm:293) FAILED
===============================================================================
==4848== Memcheck, a memory error detector
==4848== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4848== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==4848== Command: /home/runner/work/form/form/sources/tvorm -w4 1.frm
==4848== 
TFORM 5.0.0-beta.1 (Jan 24 2025, v5.0.0-beta.1-115-g1d5e40b) 4 workers  Run: Sat Jan 25 04:39:47 2025
    #procedure problematicprocedure
    * Infinite loop.
      #do i=1,1
        #redefine i "0"
      #enddo
    #endprocedure
    
    #timeoutafter 1
    #call problematicprocedure
==4848== Thread 2:
==4848== Invalid read of size 1
==4848==    at 0x17D24B: MesPrint (message.c:189)
==4848==    by 0x235B19: Terminate (startup.c:1818)
==4848==    by 0x236383: onErrSig (startup.c:1575)
==4848==    by 0x4D2E08F: ??? (in /usr/lib/x86_64-linux-gnu/libc-2.31.so)
==4848==    by 0x4CD7373: futex_wait_cancelable (futex-internal.h:183)
==4848==    by 0x4CD7373: __pthread_cond_wait_common (pthread_cond_wait.c:508)
==4848==    by 0x4CD7373: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:647)
==4848==    by 0x268D76: ThreadWait (threads.c:2168)
==4848==    by 0x26952B: RunThread (threads.c:1270)
==4848==    by 0x4CD0608: start_thread (pthread_create.c:477)
==4848==    by 0x4E0A352: clone (clone.S:95)
==4848==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==4848== 
  0.06 sec + 0.00 sec: 0.06 sec out of 17.97 sec
==4848== 
==4848== HEAP SUMMARY:
==4848==     in use at exit: 7,180,184,256 bytes in 404 blocks
==4848==   total heap usage: 449 allocs, 45 frees, 7,180,315,235 bytes allocated
==4848== 
==4848== Thread 1:
==4848== 608 bytes in 2 blocks are possibly lost in loss record 116 of 222
==4848==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4848==    by 0x40149DA: allocate_dtv (dl-tls.c:286)
==4848==    by 0x40149DA: _dl_allocate_tls (dl-tls.c:532)
==4848==    by 0x4CD1322: allocate_stack (allocatestack.c:622)
==4848==    by 0x4CD1322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==4848==    by 0x26E390: StartAllThreads (threads.c:320)
==4848==    by 0x2364AB: main (startup.c:1695)
==4848== 
==4848== 1,216 bytes in 4 blocks are possibly lost in loss record 146 of 222
==4848==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4848==    by 0x40149DA: allocate_dtv (dl-tls.c:286)
==4848==    by 0x40149DA: _dl_allocate_tls (dl-tls.c:532)
==4848==    by 0x4CD1322: allocate_stack (allocatestack.c:622)
==4848==    by 0x4CD1322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==4848==    by 0x26E20B: StartAllThreads (threads.c:293)
==4848==    by 0x2364AB: main (startup.c:1695)
==4848== 
==4848== LEAK SUMMARY:
==4848==    definitely lost: 0 bytes in 0 blocks
==4848==    indirectly lost: 0 bytes in 0 blocks
==4848==      possibly lost: 1,824 bytes in 6 blocks
==4848==    still reachable: 7,180,182,432 bytes in 398 blocks
==4848==         suppressed: 0 bytes in 0 blocks
==4848== Reachable blocks (those to which a pointer was found) are not shown.
==4848== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4848== 
==4848== For lists of detected and suppressed errors, rerun with: -s
==4848== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
===============================================================================

The 2nd run passed the test.

[jodavies]

And again: https://github.com/vermaseren/form/actions/runs/13008441429/job/36280482285

I will investigate this at some point. Though re-running works, it is a bit of a pain.

[jodavies]

I can't seem to reproduce this particular valgrind error on my computer. Under vorm, I get the intentional valgrind error from Crash (why doesn't this cause a failure in the CI, actually?)

If I run multiple instances of form as in, parallel -j4 "form-test -d ITER={} timeout.frm" ::: $(seq 1 4), the timeout doesn't work at all.

[tueda]

On a native Linux machine running Ubuntu 20.04.6 LTS, I encountered 449 failures out of 1000 runs (449 / 1000 = 44.9%) of TimeoutAfter_2 with valgrind tvorm (which is with -w4). The test failed 9 times out of 5000 runs (9 / 5000 = 0.18%) without Valgrind.