Siege 3.1.0 segfault when verbose is true

[nask0]

I notice that siege (3.1.0) segfault's when you have configured concurrent users > 1 and verbose = true (both with compiled version and that one provide from repository).
If verbose is set to false, then no crash occurred even with concurrent users > 1.

Here is the backtrace:

nask0@dev-nask0 ~ $ siege -C
CURRENT  SIEGE  CONFIGURATION
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.125 Safari/537.36 Siege/3.1
Edit the resource file to change the settings.

version:                        3.1.0
verbose:                        true
quiet:                          false
debug:                          false
protocol:                       HTTP/1.1
get method:                     GET
connection:                     close
concurrent users:               20
time to run:                    n/a
repetitions:                    20
socket timeout:                 30
accept-encoding:                *
delay:                          1.000 sec
internet simulation:            true
benchmark mode:                 false
failures until abort:           1024
named URL:                      none
URLs file:                      /tmp/load-tests-urls.txt
logging:                        true
log file:                       /tmp/siege-dcr.log
resource file:                  /home/nask0/.siegerc
timestamped output:             true
comma separated output:         false
allow redirects:                true
allow zero byte data:           false
allow chunked encoding:         true
upload unique files:            true

nask0@dev-nask0 ~ $ gdb siege
GNU gdb (GDB) Fedora 7.9.1-13.fc22
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from siege...Reading symbols from /usr/lib/debug/usr/bin/siege.debug...done.
done.
(gdb) run
Starting program: /usr/bin/siege 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
** SIEGE 3.1.0
** Preparing 20 concurrent users for battle.
The server is now under siege...
[New Thread 0x7fffeb74a700 (LWP 24982)]
[New Thread 0x7fffebf4b700 (LWP 24981)]
[New Thread 0x7fffec74c700 (LWP 24980)]
[New Thread 0x7fffecf4d700 (LWP 24979)]
[New Thread 0x7fffed74e700 (LWP 24978)]
[New Thread 0x7fffedf4f700 (LWP 24977)]
[New Thread 0x7fffee750700 (LWP 24976)]
[New Thread 0x7fffeef51700 (LWP 24975)]
[New Thread 0x7fffef752700 (LWP 24974)]
[New Thread 0x7fffeff53700 (LWP 24973)]
[New Thread 0x7ffff0754700 (LWP 24972)]
[New Thread 0x7ffff0f55700 (LWP 24971)]
[New Thread 0x7ffff1756700 (LWP 24970)]
[New Thread 0x7ffff1f57700 (LWP 24969)]
[New Thread 0x7ffff2758700 (LWP 24968)]
[New Thread 0x7ffff2f59700 (LWP 24967)]
[New Thread 0x7ffff375a700 (LWP 24966)]
[New Thread 0x7ffff3f5b700 (LWP 24965)]
[New Thread 0x7ffff475c700 (LWP 24964)]
[New Thread 0x7ffff4f5d700 (LWP 24963)]
[New Thread 0x7ffff575e700 (LWP 24962)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffee750700 (LWP 24976)]
0x00007ffff6deded3 in _IO_vfprintf_internal (s=s@entry=0x7fffee73bda0, format=<optimized out>, format@entry=0x4146e0 "%s%4d: %s %d %6.2f secs: %7lu bytes ==> %-4s %s", ap=ap@entry=0x7fffee74fb80)
    at vfprintf.c:1642
1642          process_string_arg (((struct printf_spec *) NULL));
(gdb) bt
#0  0x00007ffff6deded3 in _IO_vfprintf_internal (s=s@entry=0x7fffee73bda0, format=<optimized out>, format@entry=0x4146e0 "%s%4d: %s %d %6.2f secs: %7lu bytes ==> %-4s %s", ap=ap@entry=0x7fffee74fb80)
    at vfprintf.c:1642
#1  0x00007ffff6eb118c in ___vsprintf_chk (s=s@entry=0x7fffee73bed0 "", flags=flags@entry=1, slen=slen@entry=40000, format=0x4146e0 "%s%4d: %s %d %6.2f secs: %7lu bytes ==> %-4s %s", args=0x7fffee74fb80, 
    args@entry=0x7fffee73bed0) at vsprintf_chk.c:85
#2  0x00007ffff7bd8d3e in vsprintf (__ap=0x7fffee73bed0, __fmt=<optimized out>, __s=0x7fffee73bed0 "") at /usr/include/bits/stdio2.h:46
#3  __display (color=4, fmt=<optimized out>, ap=ap@entry=0x7fffee74fb80) at notify.c:164
#4  0x00007ffff7bd8e54 in DISPLAY (color=<optimized out>, fmt=<optimized out>) at notify.c:175
#5  0x0000000000406bfa in __request (C=<optimized out>, U=<optimized out>, client=<optimized out>) at client.c:350
#6  0x00000000004071af in start_routine (client=<optimized out>) at client.c:126
#7  0x000000000040851a in crew_thread (crew=0x62c750) at crew.c:140
#8  0x00007ffff79c2555 in start_thread (arg=0x7fffee750700) at pthread_create.c:333
#9  0x00007ffff6ea1f3d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

[JoeDog]

Lots of weirdness going on here. The line numbers don't seem to align with the core dump. For example, I'd expect #3 to correspond with notify.c:158 not 164.

Personally, I'm unable to reproduce this problem. I've run multiple users in verbose mode across an array of consoles and it doesn't dump core.

Do me a favor: move ~/.siegerc to something else, run siege.config to generate a new one, then try again. I wonder if something is mucking the formatting.

[nask0]

By mistake i was set

display_id = true

which caused the issue.

[JoeDog]

Yeah, but that's still a bug. You shouldn't be able to do anything which makes it dump core. I'll look at it. Thanks for bringing this to my attention.

UPDATE: I tied display-id = ture and display_id = ture and I can't get it to dump core. Any chance you still have the .siegerc file that caused the issue?

UPDATED UPDATE: I did indeed find a bug and fixed it. client.c has been updated in the main branch.

[nask0]

Awesome, thanks !