segfault when attempted to interrupt the siege via ctrl+C

[stefanos82]

I've pulled the latest commit bee856b, compiled it on my Debian testing 64-bit via ./configure && make -j4

siege was compiled successfully, recursive make command failed to build the doc though.

I have tried a simple test siege --concurrent=500 --time=10S http://joespizza.local on my local website and by mistake I've inserted 500 when I meant to insert 50 (darn muscle memory!).

I have tried to interrupt it with ctrl+C only to get a segfault after a while:

          PID: 57926 (siege)
           UID: 1000 (stefanos)
           GID: 1000 (stefanos)
        Signal: 11 (SEGV)
     Timestamp: Tue 2025-09-09 03:08:41 EEST (4min 43s ago)
  Command Line: siege --concurrent=500 --time=10S http://joespizza.local
    Executable: /PortableApps/siege/bin/siege
 Control Group: /user.slice/user-1000.slice/session-2.scope
          Unit: session-2.scope
         Slice: user-1000.slice
       Session: 2
     Owner UID: 1000 (stefanos)
       Boot ID: 60e59598d80f4151b7a615c390b6720a
    Machine ID: 8c7db6fc6680a4087c9dca0452dbd717
      Hostname: debian
       Storage: /var/lib/systemd/coredump/core.siege.1000.60e59598d80f4151b7a615c390b6720a.57926.1757376521000000.zst (present)
  Size on Disk: 422.6K
       Message: Process 57926 (siege) of user 1000 dumped core.
                
                Module libgcc_s.so.1 from deb gcc-15-15.2.0-2.amd64
                Module libzstd.so.1 from deb libzstd-1.5.7+dfsg-1.1.amd64
                Module libuuid.so.1 from deb util-linux-2.41.1-2.amd64
                Stack trace of thread 58184:
                #0  0x00007fe6bc69b589 __pthread_cancel (libc.so.6 + 0x91589)
                #1  0x0000564078d51961 crew_cancel (/PortableApps/siege/bin/siege + 0xf961)
                #2  0x0000564078d53dcd sig_handler (/PortableApps/siege/bin/siege + 0x11dcd)
                #3  0x00007fe6bc69cb7b start_thread (libc.so.6 + 0x92b7b)
                #4  0x00007fe6bc71a7b8 __clone3 (libc.so.6 + 0x1107b8)
                                
                Stack trace of thread 57926:
                #0  0x00007fe6bc6ac0f4 _int_malloc (libc.so.6 + 0xa20f4)
                #1  0x00007fe6bc6acc4e __GI___libc_malloc (libc.so.6 + 0xa2c4e)
                #2  0x00007fe6bc687db3 __GI__IO_file_doallocate (libc.so.6 + 0x7ddb3)
                #3  0x00007fe6bc696b49 __GI__IO_doallocbuf (libc.so.6 + 0x8cb49)
                #4  0x00007fe6bc694cc8 _IO_new_file_overflow (libc.so.6 + 0x8acc8)
                #5  0x00007fe6bc695767 _IO_new_file_xsputn (libc.so.6 + 0x8b767)
                #6  0x00007fe6bc68937c __GI__IO_fwrite (libc.so.6 + 0x7f37c)
                #7  0x0000564078d490da __save_cookies (/PortableApps/siege/bin/siege + 0x70da)
                #8  0x00007fe6bc633ca8 __libc_start_call_main (libc.so.6 + 0x29ca8)
                #9  0x00007fe6bc633d65 __libc_start_main_impl (libc.so.6 + 0x29d65)
                #10 0x0000564078d499a1 _start (/PortableApps/siege/bin/siege + 0x79a1)
                
                Stack trace of thread 58015:
                #0  0x00007fe6bc716bb7 __madvise (libc.so.6 + 0x10cbb7)
                #1  0x00007fe6bc69ccf5 advise_stack_range (libc.so.6 + 0x92cf5)
                #2  0x00007fe6bc71a7b8 __clone3 (libc.so.6 + 0x1107b8)
                
                Stack trace of thread 58185:
                #0  0x00007fe6bc6a49ee __syscall_cancel_arch (libc.so.6 + 0x9a9ee)
                #1  0x00007fe6bc699668 __internal_syscall_cancel (libc.so.6 + 0x8f668)
                #2  0x00007fe6bc699c9c __futex_abstimed_wait_common64 (libc.so.6 + 0x8fc9c)
                #3  0x00007fe6bc69c31d __pthread_cond_wait_common (libc.so.6 + 0x9231d)
                #4  0x0000564078d5e4ac siege_timer (/PortableApps/siege/bin/siege + 0x1c4ac)
                #5  0x00007fe6bc69cb7b start_thread (libc.so.6 + 0x92b7b)
                #6  0x00007fe6bc71a7b8 __clone3 (libc.so.6 + 0x1107b8)
                ELF object binary architecture: AMD x86-64

Do I need to do something differently next time, other than reduce the number of concurrent users or limit it at best to the maximum users possible (255)?