siege crashed with SIGSEGV in *__GI_____strtol_l_internal()

Here is the stack from GDB in case the retracer chokes:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f7b7c2376f0 (LWP 10372)]
*__GI_____strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, loc=0x7f7b7b649580) at ../stdlib/strtol_l.c:298
298 ../stdlib/strtol_l.c: No such file or directory.
 in ../stdlib/strtol_l.c
(gdb) bt
#0 *__GI_____strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, loc=0x7f7b7b649580) at ../stdlib/strtol_l.c:298
#1 0x000000000040e62b in parse_time (p=0x7fff8426667f "ernet") at /usr/include/stdlib.h:286
#2 0x000000000040adc4 in parse_cmdline (argc=2, argv=0x7fff84264608) at main.c:236
#3 0x000000000040b113 in main (argc=2, argv=0x7fff84264608) at main.c:312
(gdb)

"siege -te" is sufficient to crash it, I don't think "siege -ate" should invoke the time parsing at all but it does.

I had a quick look at the code. This is not related to this bug but... The second if statement here is funny, this guy manages to malloc sub, leak it, strdup buffer and leak that as well. And casting size_t to int is a great practice.... not (length and start should be redeclared as size_t instead). I still siege though because it's easier to use than httperf and so on, but the code...

substring(char *buffer, int start, int length)
{
  char *sub;
  sub = malloc (sizeof (char) * (length + 1));

  if ((length < 1) || (start < 0) || (start > (int)strlen (buffer)))
    return NULL;

  if ((int)strlen (buffer) < length){
    sub = (char*) strdup (buffer);
    return buffer;
  }
...

To fix the bug at hand, it's sufficient to add "if (x ==0) return;" right after the while loop in parse_time(), like this:

parse_time(char *p)
{
  size_t x = 0;
  my.time = my.secs = 0;
  while(ISDIGIT(p[x]))
    x++;
  if (x == 0)
    return;

Running "valgrind siege -te" still shows leaks though.

StacktraceTop:*__GI_____strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0,
parse_time (p=0x7fff6718e65b "ernet")
parse_cmdline (argc=5, argv=0x7fff6718d4f8)
main (argc=5, argv=0x7fff6718d4f8) at main.c:312

I can confirm this and am going to enact a fix upstream. I am now adopting this package upstream. Will keep you posted. Thanks for taking the time to debug this and provide the patch!

I was not able to reproduce this on karmic.

Regards
chuck