Bug 907645 - siege cannot connect to local machines
Summary: siege cannot connect to local machines
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: siege
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Christof Damian
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-04 22:20 UTC by D.S. Ljungmark
Modified: 2014-02-05 23:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 23:19:34 UTC


Attachments (Terms of Use)
Patch to fix name resolution issue. (1.15 KB, patch)
2013-05-06 23:10 UTC, Michael Hudson-Doyle
no flags Details | Diff

Description D.S. Ljungmark 2013-02-04 22:20:29 UTC
Description of problem:
Siege from fedora gets "connection refused" when it tries to connect.

Version-Release number of selected component (if applicable):
siege-2.72-3.fc18.x86_64

How reproducible:

siege -g http://172.27.1.175/
[error] socket: unable to connect sock.c:222: Connection refused
[done]

stracing shows:
[pid 15007] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 15007] select(4, [3], [3], NULL, {30, 0}) = 2 (in [3], out [3], left {29, 999996})
[pid 15007] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 ECONNREFUSED (Connection refused)

( connect to 0.0.0.0 ? clearly wrong )

Works in upstream beta:
~/build/siege-2.73b6% ./src/siege -g http://172.27.1.175/
GET / HTTP/1.1
Host: 172.27.1.175
Accept: */*
Accept-Encoding: 
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.73b6)
Connection: close

Comment 1 Fedora Update System 2013-02-23 20:08:43 UTC
siege-2.74-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/siege-2.74-1.fc18

Comment 2 Fedora Update System 2013-02-23 20:20:28 UTC
siege-2.74-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/siege-2.74-1.el6

Comment 3 Fedora Update System 2013-02-24 08:49:37 UTC
Package siege-2.74-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing siege-2.74-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-2959/siege-2.74-1.fc18
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2013-03-01 21:44:57 UTC
siege-2.75-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/siege-2.75-1.fc18

Comment 5 Fedora Update System 2013-03-01 23:19:15 UTC
siege-2.75-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/siege-2.75-1.el6

Comment 6 Fedora Update System 2013-03-12 08:37:34 UTC
siege-2.75-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Celestino 2013-03-18 17:09:00 UTC
(In reply to comment #6)
> siege-2.75-1.fc18 has been pushed to the Fedora 18 stable repository.  If
> problems still persist, please make note of it in this bug report.

Defect still present on my Fedora 18 system.

[camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -f siege.url 
...
[pid  5923] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid  5923] select(4, [3], [3], NULL, {30, 0}) = 1 (out [3], left {29, 999997})
[pid  5923] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EISCONN (Transport endpoint is already connected)
[pid  5923] write(3, "GET /prova.txt HTTP/1.1\r\nHost: 1"..., 152) = 152
[pid  5923] select(4, [3], NULL, NULL, {30, 0}) = 1 (in [3], left {29, 999997})
[pid  5923] read(3, "HTTP/1.1 404 Not Found\r\nDate: Mo"..., 4096) = 397
....

[camoroso@f18dev ~]$ cat siege.url
http://10.186.65.0/prova.txt

[camoroso@f18dev ~]$ ifconfig p2p1
p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.186.16.198  netmask 255.255.240.0  broadcast 10.186.31.255
        inet6 fe80::a00:27ff:fe6d:c9d7  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:6d:c9:d7  txqueuelen 1000  (Ethernet)
        RX packets 231092  bytes 24653772 (23.5 MiB)
        RX errors 0  dropped 213  overruns 0  frame 0
        TX packets 286951  bytes 65660341 (62.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


[camoroso@f18dev ~]$ rpm -q siege
siege-2.75-1.fc18.x86_64

[camoroso@f18dev ~]$ uname -a
Linux f18dev 3.8.2-206.fc18.x86_64 #1 SMP Fri Mar 8 15:03:34 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Comment 8 Christof Damian 2013-03-18 18:20:07 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > siege-2.75-1.fc18 has been pushed to the Fedora 18 stable repository.  If
> > problems still persist, please make note of it in this bug report.
> 
> Defect still present on my Fedora 18 system.

Looks OK to me.

> [camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -f siege.url 
> ...
> [pid  5923] read(3, "HTTP/1.1 404 Not Found\r\nDate: Mo"..., 4096) = 397
> ....

The connection seems to be OK, giving a 404 error.

> [camoroso@f18dev ~]$ cat siege.url
> http://10.186.65.0/prova.txt

What happens if you access this address with curl, wget or a web browser?

Comment 9 Celestino 2013-03-18 23:11:46 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > siege-2.75-1.fc18 has been pushed to the Fedora 18 stable repository.  If
> > > problems still persist, please make note of it in this bug report.
> > 
> > Defect still present on my Fedora 18 system.
> 
> Looks OK to me.
> 
> > [camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -f siege.url 
> > ...
> > [pid  5923] read(3, "HTTP/1.1 404 Not Found\r\nDate: Mo"..., 4096) = 397
> > ....
> 
> The connection seems to be OK, giving a 404 error.

That response 404 comes from Apache running on localhost (f18dev), not from requested host (10.186.65.0).

> 
> > [camoroso@f18dev ~]$ cat siege.url
> > http://10.186.65.0/prova.txt
> 
> What happens if you access this address with curl, wget or a web browser?

On host 10.186.65.0 the resource "prova.txt" is present and I get it with any other tool, e.g. GET, wget, etc.

In other words, on my Fedora 18 installation, siege connects to localhost only, not to the host specified in the requested URL.

I also tried it on Fedora 17 and Sabayon: On Fedora 17, siege gives same wrong behavior; on Sabayn insted it works as expected.

(Sorry for my poor english)

Comment 10 Celestino 2013-03-19 08:39:40 UTC
More tests. Here I use two hosts:

 1. f18dev
       IP: 10.186.16.198
       OS: Fedora 18 x86_64
       Kernel: 3.8.2-206.fc18.x86_64
       Apache: httpd-2.4.3-15.fc18.x86_64
       siege: siege-2.75-1.fc18.x86_64

 2. vaio
       IP: 10.186.65.0
       OS: Fedora 17 x86_64
       Kernel: 3.7.9-104.fc17.x86_64
       Apache: httpd-2.2.23-1.fc17.x86_64

===================

Request by GET (lwp-request):


[camoroso@f18dev ~]$ GET http://vaio/prova.txt
Hi,
I'm prova.txt

===================


Request by siege:

[camoroso@f18dev ~]$ siege -c 1 -r 1 -g http://vaio/prova.txt
GET /prova.txt HTTP/1.1
Host: vaio
Accept: */*
Accept-Encoding: 
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.75)
Connection: close


HTTP/1.1 404 Not Found
Date: Tue, 19 Mar 2013 08:05:00 GMT
Server: Apache/2.4.3 (Fedora) PHP/5.4.12
Content-Length: 207
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /prova.txt was not found on this server.</p>
</body></html>

[done]

===================


Now, I copy and paste siege http request in a nc (netcat) connection:

[camoroso@f18dev ~]$ nc vaio 80
GET /prova.txt HTTP/1.1
Host: vaio
Accept: */*
Accept-Encoding: 
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.75)
Connection: close

HTTP/1.1 200 OK
Date: Tue, 19 Mar 2013 08:04:52 GMT
Server: Apache/2.2.23 (Fedora)
Last-Modified: Tue, 19 Mar 2013 07:59:07 GMT
ETag: "17fdaa-13-4d8427ade66e5"
Accept-Ranges: bytes
Content-Length: 19
Connection: close
Content-Type: text/plain; charset=UTF-8

Hi,
I'm prova.txt

===================

Please, note the difference of Server http headers in last two responses:

siege
Server: Apache/2.4.3 (Fedora) PHP/5.4.12

nc
Server: Apache/2.2.23 (Fedora)

Hence, that means that the answer to siege comes from Apache running on f18dev and not from the one running on vaio.

Further, as shown yesterday, I get following output tracing siege by strace:

[camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -g http://vaio/prova.txt 
...
[pid  7220] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid  7220] select(4, [3], [3], NULL, {30, 0}) = 1 (out [3], left {29, 999997})
[pid  7220] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EISCONN (Transport endpoint is already connected)
[pid  7220] fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
...
[pid  7220] write(3, "GET /prova.txt HTTP/1.1\r\nHost: v"..., 141) = 141
[pid  7220] select(4, [3], NULL, NULL, {30, 0}) = 1 (in [3], left {29, 999998})
[pid  7220] read(3, "HTTP/1.1 404 Not Found\r\nDate: Tu"..., 4096) = 397
...

Comment 11 Christof Damian 2013-03-19 08:56:54 UTC
That does look(In reply to comment #10)
> More tests. Here I use two hosts

That does look wrong indeed. I will try to somehow reproduce this. I see the 0.0.0.0 in strace too, but it still works for me. 

The only thing that comes to mind at the moment is that you use a .0 address for your vaio, which is usually a network address. I will try this on my machine to see if it makes a difference. 
If I can't find anything I will ping the siege author, maybe he has an idea.

Comment 12 Celestino 2013-03-19 13:25:09 UTC
(In reply to comment #11)
> That does look(In reply to comment #10)
> > More tests. Here I use two hosts
> If I can't find anything I will ping the siege author, maybe he has an idea.

Christof, I just built siege from source, version 2.78. Now it seems to work fine.

[camoroso@f18dev bin]$ ./siege -c 1 -r 1 -g http://vaio/prova.txt
GET /prova.txt HTTP/1.1
Host: vaio
Accept: */*
Accept-Encoding: 
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.78)
Connection: close


HTTP/1.1 200 OK
Date: Tue, 19 Mar 2013 13:21:52 GMT
Server: Apache/2.2.23 (Fedora)
Last-Modified: Tue, 19 Mar 2013 07:59:07 GMT
ETag: "17fdaa-13-4d8427ade66e5"
Accept-Ranges: bytes
Content-Length: 19
Connection: close
Content-Type: text/plain; charset=UTF-8

Hi,
I'm prova.txt

Comment 13 Christof Damian 2013-03-19 19:17:54 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > That does look(In reply to comment #10)
> > > More tests. Here I use two hosts
> > If I can't find anything I will ping the siege author, maybe he has an idea.
> 
> Christof, I just built siege from source, version 2.78. Now it seems to work
> fine.

I have build a new RPM for f18. Could you test this? It is just on koji for now: http://koji.fedoraproject.org/koji/taskinfo?taskID=5143556

Comment 14 Celestino 2013-03-20 09:13:20 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > That does look(In reply to comment #10)
> > > > More tests. Here I use two hosts
> > > If I can't find anything I will ping the siege author, maybe he has an idea.
> > 
> > Christof, I just built siege from source, version 2.78. Now it seems to work
> > fine.
> 
> I have build a new RPM for f18. Could you test this? It is just on koji for
> now: http://koji.fedoraproject.org/koji/taskinfo?taskID=5143556

Done, but no good news.

Test on siege built from sources

[camoroso@f18dev bin]$ ./siege -c 1 -r 1 -g http://vaio/prova.txt
GET /prova.txt HTTP/1.1
Host: vaio
Accept: */*
Accept-Encoding: 
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.78)
Connection: close


HTTP/1.1 200 OK
Date: Wed, 20 Mar 2013 09:06:21 GMT
Server: Apache/2.2.23 (Fedora)
Last-Modified: Tue, 19 Mar 2013 07:59:07 GMT
ETag: "17fdaa-13-4d8427ade66e5"
Accept-Ranges: bytes
Content-Length: 19
Connection: close
Content-Type: text/plain; charset=UTF-8

Hi,
I'm prova.txt


Test on siege from rpm

[camoroso@f18dev bin]$ siege -c 1 -r 1 -g http://vaio/prova.txt
[error] socket: -1871571200 connection refused.: Connection refused
[done]

[camoroso@f18dev bin]$ siege -V
SIEGE 2.78

Copyright (C) 2013 by Jeffrey Fulmer, et al.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.


PS: Today vaio IP is 10.186.65.23

Comment 15 Christof Damian 2013-03-20 21:13:31 UTC
(In reply to comment #14)
> 
> [camoroso@f18dev bin]$ siege -c 1 -r 1 -g http://vaio/prova.txt
> [error] socket: -1871571200 connection refused.: Connection refused
> [done]
> 

I am really lost here :-) As you can see from the spec file I am really not doing anything different from you compiling it on your machine.

It is just configure & make, and there a no strange options in there:

./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc/siege
make -j5

It also works without problems for me. 

Maybe it is related to a dynamic library.

Comment 16 Celestino 2013-03-21 15:18:52 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > 
> > [camoroso@f18dev bin]$ siege -c 1 -r 1 -g http://vaio/prova.txt
> > [error] socket: -1871571200 connection refused.: Connection refused
> > [done]
> > 
> 
> I am really lost here :-) As you can see from the spec file I am really not
> doing anything different from you compiling it on your machine.

I did further analysis. Below you can see a summary. The critical point seems to be the call to the function gethostbyname_r(). In siege from rpm gethostbyname_r() translates "vaio" as "0". In siege from source, translation gives "390183434" -> "10.186.65.23". GDB shows it better.

Rebuild using your configure command line (prefix = /home/camoroso/siege)

[camoroso@f18dev siege]$ ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/home/camoroso/siege --exec-prefix=/home/camoroso/siege --bindir=/home/camoroso/siege/bin --sbindir=/home/camoroso/siege/sbin --sysconfdir=/home/camoroso/siege/etc --datadir=/home/camoroso/siege/share --includedir=/home/camoroso/siege/include --libdir=/home/camoroso/siege/lib64 --libexecdir=/home/camoroso/siege/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/home/camoroso/siege/share/man --infodir=/home/camoroso/siege/share/info --sysconfdir=/home/camoroso/siege/etc/siege

[camoroso@f18dev siege]$ make

[camoroso@f18dev siege]$ make install

[camoroso@f18dev siege]$ ll
totale 0
drwxrwxr-x 1 camoroso camoroso  80 21 mar 11.12 bin
drwxrwxr-x 1 camoroso camoroso  10 21 mar 11.12 etc
drwxrwxr-x 1 camoroso camoroso   6 21 mar 11.12 share
drwxrwxr-x 1 camoroso camoroso 484 21 mar 11.11 siege-2.78

[camoroso@f18dev siege]$ cd bin
[camoroso@f18dev bin]$ pwd
/home/camoroso/siege/bin
[camoroso@f18dev bin]$ export PATH=$PATH:`pwd`

[camoroso@f18dev siege]$ echo $PATH
/usr/...:/home/camoroso/siege/bin

[camoroso@f18dev siege]$ siege -c 1 -r 1 -g http://vaio/prova.txt
GET /prova.txt HTTP/1.1
Host: vaio
Accept: */*
Accept-Encoding: 
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.78)
Connection: close


HTTP/1.1 200 OK
Date: Thu, 21 Mar 2013 10:12:16 GMT
Server: Apache/2.2.23 (Fedora)
Last-Modified: Tue, 19 Mar 2013 07:59:07 GMT
ETag: "17fdaa-13-4d8427ade66e5"
Accept-Ranges: bytes
Content-Length: 19
Connection: close
Content-Type: text/plain; charset=UTF-8

Hi,
I'm prova.txt

=====================================================

STRACE on rpm:

[camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -g http://vaio/prova.txt
...
[pid 27951] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 ECONNREFUSED (Connection refused)
[pid 27951] write(2, "[\33[1;33merror\33[0m] socket: 51964"..., 77Process 27952 attached
 <unfinished ...>
[pid 27952] set_robust_list(0x7fa31e7919e0, 24) = 0
[pid 27952] rt_sigprocmask(SIG_BLOCK, [HUP INT TERM], [ESC[1;33merrorESC[0m] socket: 519644928 connection refused.: Connection refused
...

STRACE on sources

[camoroso@f18dev bin]$ strace -f /home/camoroso/siege/bin/siege -c 1 -r 1 -g http://vaio/prova.txt
...
[pid 27848] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("10.186.65.23")}, 16) = 0
[pid 27848] select(4, [3], [3], NULL, {30, 0}) = 1 (out [3], left {29, 999995})
[pid 27848] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("10.186.65.23")}, 16) = -1 EISCONN (Transport endpoint is already connected)
...


=====================================================
GDB analysis: Note value of hp-h_addr_list[0]
and cli.sin_addr: in rpm it is 0;
in source it is 390183434 -> 10.186.65.23
=====================================================


GDB on siege from rpm

[camoroso@f18dev ~]$ gdb /usr/bin/siege
...
Reading symbols from /usr/bin/siege...Reading symbols from /usr/lib/debug/usr/bin/siege.debug...done.
done.
(gdb) start -c 1 -r 1 -g http://vaio/prova.txt
...
(gdb) b new_socket
Breakpoint 2 at 0x40eca0: file sock.c, line 76.
(gdb) cont
Continuing.
[New Thread 0x7ffff7fd9700 (LWP 28960)]
[New Thread 0x7ffff77d8700 (LWP 28961)]
[Switching to Thread 0x7ffff7fd9700 (LWP 28960)]

Breakpoint 2, new_socket (C=C@entry=0x7ffff00008c0, hostparam=0x620580 "vaio", portparam=80) at sock.c:76
76      {
(gdb) n
...
126         if((gethostbyname_r(hostparam, &hent, hbf, sizeof(hbf), &hp, &herrno) < 0)){
(gdb) p *((unsigned long *)hp->h_addr_list[0])
$3 = 0
...

157       memcpy(&cli.sin_addr, hp->h_addr, hp->h_length);
(gdb) n
...
(gdb) p cli
$4 = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}
(gdb) n
189       conn = connect(C->sock, (struct sockaddr *)&cli, sizeof(struct sockaddr_in));
(gdb) 
190       pthread_testcancel();
(gdb) p conn
$6 = -1

=====================================================



GDB on siege built from sources

[camoroso@f18dev ~]$ cd siege/siege-2.78/src/
[camoroso@f18dev src]$ gdb ./siege
...
Reading symbols from /home/camoroso/siege/siege-2.78/src/siege...done.
(gdb) start -c 1 -r 1 -g http://vaio/prova.txt
...
(gdb) b new_socket
Breakpoint 2 at 0x40d890: file sock.c, line 76.
(gdb) cont
Continuing.
[New Thread 0x7ffff7fdf700 (LWP 28978)]
[New Thread 0x7ffff77de700 (LWP 28979)]
[Switching to Thread 0x7ffff7fdf700 (LWP 28978)]

Breakpoint 2, new_socket (C=C@entry=0x7ffff00008c0, hostparam=0x61c430 "vaio", portparam=80) at sock.c:76
76      {
(gdb) n
...
126         if((gethostbyname_r(hostparam, &hent, hbf, sizeof(hbf), &hp, &herrno) < 0)){
(gdb) p *((unsigned long *)hp->h_addr_list[0])
$17 = 390183434
(gdb) n
157       memcpy(&cli.sin_addr, hp->h_addr, hp->h_length);
(gdb) p cli
$14 = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 390183434}, sin_zero = "\000\000\000\000\000\000\000"}
(gdb) n
189       conn = connect(C->sock, (struct sockaddr *)&cli, sizeof(struct sockaddr_in));
(gdb) p conn
$18 = 0


=====================================================


Note from man page of gethostbyname_r()

[camoroso@vaio net]$ man gethostbyname_r
...
DESCRIPTION
       The gethostbyname*() and gethostbyaddr*() functions are obsolete.  Applications should use getaddrinfo(3) and getnameinfo(3) instead.
...



=====================================================

>Maybe it is related to a dynamic library.

RPM
[camoroso@f18dev src]$ ldd /usr/bin/siege
        linux-vdso.so.1 =>  (0x00007fffff1fe000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000000378a000000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003789c00000)
        libssl.so.10 => /lib64/libssl.so.10 (0x0000003404400000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003403c00000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003789800000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003789400000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003403000000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003402c00000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x000000378fc00000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003403400000)
        libz.so.1 => /lib64/libz.so.1 (0x000000378ac00000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003403800000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003791000000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x000000378c800000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000378b000000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003402000000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x000000366e400000)

Source
[camoroso@f18dev src]$ ldd ~/siege/bin/siege
        linux-vdso.so.1 =>  (0x00007fffcaaa4000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000000378a000000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003789800000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003789400000)

Comment 17 Fedora Update System 2013-03-25 18:55:20 UTC
siege-2.75-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Christof Damian 2013-03-25 19:50:06 UTC
sorry, that was closed by mistake

Comment 19 Christof Damian 2013-04-18 18:22:14 UTC
next try: siege 3.0.0 is has now been submitted to rawhide, f18, f19 and el6. Could you give it another try?

Comment 20 Celestino 2013-04-19 07:22:07 UTC
(In reply to comment #19)
> next try: siege 3.0.0 is has now been submitted to rawhide, f18, f19 and
> el6. Could you give it another try?

I can't find that rpm. I found this:

https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/Packages/s/siege-2.78-2.fc20.x86_64.rpm

Could you post direct link to the right package?

Comment 21 Christof Damian 2013-04-19 07:54:18 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > next try: siege 3.0.0 is has now been submitted to rawhide, f18, f19 and
> > el6. Could you give it another try?
> 
> I can't find that rpm. I found this:
> 
> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/
> Packages/s/siege-2.78-2.fc20.x86_64.rpm
> 
> Could you post direct link to the right package?

For rawhide you can find it here: http://kojipkgs.fedoraproject.org//packages/siege/3.0.0/2.fc20/x86_64/siege-3.0.0-2.fc20.x86_64.rpm

For the others on the koji page: http://koji.fedoraproject.org/koji/packageinfo?packageID=3828

Comment 22 Celestino 2013-04-19 08:38:24 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)

> For the others on the koji page:
> http://koji.fedoraproject.org/koji/packageinfo?packageID=3828

==========================
[camoroso@f18dev ~]$ siege -c 1 -r 1 -g http://vaio/prova.txt
[error] socket: 982947584 connection refused.: Connection refused
[done]


[camoroso@f18dev ~]$ siege -V
SIEGE 3.0.0

Copyright (C) 2013 by Jeffrey Fulmer, et al.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.
==========================

At this point I am convinced that the problem is in the build environment/context, not in the code.

Comment 23 Christof Damian 2013-04-19 08:43:17 UTC
(In reply to comment #22)
>
> At this point I am convinced that the problem is in the build
> environment/context, not in the code.

I agree. It would also help if I could reproduce this locally.

Comment 24 Celestino 2013-04-19 08:55:11 UTC
(In reply to comment #23)
> (In reply to comment #22)
> >
> > At this point I am convinced that the problem is in the build
> > environment/context, not in the code.
> 
> I agree. It would also help if I could reproduce this locally.

My env is a virtual machine on VirtualBox.

$ rpm -q VirtualBox-4.2
VirtualBox-4.2-4.2.6_82870_el5-1

VM OS: Fedora 18 x86_64.

[camoroso@f18dev ~]$ uname -a
Linux f18dev 3.8.5-201.fc18.x86_64 #1 SMP Thu Mar 28 21:01:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[camoroso@f18dev ~]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) 


Ask me for any other info

Comment 25 Michael Hudson-Doyle 2013-05-03 03:02:07 UTC
I'm pretty sure this is a bug in siege.  gethostbyname_r makes hp point at hent  and hp->h_addr point at hbf both of which are automatic variables that have left scope by the time of the memcpy into cli.sin_addr (and this is undefined per section 6.2.4 of C99).

I presume the differences people are to do with gcc versions or flags.  But the code is broken.  And moving hent and hbf up to function scope makes it work for me.

Comment 26 Christof Damian 2013-05-03 11:35:21 UTC
(In reply to comment #25)
> I'm pretty sure this is a bug in siege.  gethostbyname_r makes hp point at
> hent  and hp->h_addr point at hbf both of which are automatic variables that
> have left scope by the time of the memcpy into cli.sin_addr (and this is
> undefined per section 6.2.4 of C99).
> 
> I presume the differences people are to do with gcc versions or flags.  But
> the code is broken.  And moving hent and hbf up to function scope makes it
> work for me.

Thanks for your help Michael! Do you have a patch for this? Otherwise I can create one and send it to upstream too. 

I will try that later.

Comment 27 Christof Damian 2013-05-06 22:54:56 UTC
I wonder if this is related: http://freecode.com/projects/siege/releases/354453

"This release fixes a bug in which a host lookup failure could cause siege to erroneously send traffic to localhost."

Comment 28 Michael Hudson-Doyle 2013-05-06 23:09:10 UTC
Yes -- I sent a patch to the author.  I'll attach it here too.

Comment 29 Michael Hudson-Doyle 2013-05-06 23:10:57 UTC
Created attachment 744355 [details]
Patch to fix name resolution issue.

Comment 30 Celestino 2013-05-07 12:07:34 UTC
(In reply to comment #27)
> I wonder if this is related:
> http://freecode.com/projects/siege/releases/354453
> 
> "This release fixes a bug in which a host lookup failure could cause siege
> to erroneously send traffic to localhost."

Version 3.0.1-beta3
If you generate the rpm package in your build context, I'll try it on my F18 virtual machine.

Comment 31 Christof Damian 2013-05-08 18:37:40 UTC
(In reply to comment #30)
> (In reply to comment #27)
> > I wonder if this is related:
> > http://freecode.com/projects/siege/releases/354453
> > 
> > "This release fixes a bug in which a host lookup failure could cause siege
> > to erroneously send traffic to localhost."
> 
> Version 3.0.1-beta3
> If you generate the rpm package in your build context, I'll try it on my F18
> virtual machine.

beta4 is now available in rawhide. Here is the koji link: http://koji.fedoraproject.org/koji/taskinfo?taskID=5348395

Comment 32 Celestino 2013-05-09 08:58:43 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #27)
> > > I wonder if this is related:
> > > http://freecode.com/projects/siege/releases/354453

> beta4 is now available in rawhide. Here is the koji link:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5348395

:(

[camoroso@f18dev ~]$ siege -c 1 -r 1 -g http://vaio/prova.txt
[error] socket: -1665722624 unknown network error.: No route to host
[done]
[camoroso@f18dev ~]$ rpm -q siege
siege-3.0.1-1.beta4.fc20.x86_64

Comment 33 Fedora End Of Life 2013-12-21 15:44:29 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 34 Fedora End Of Life 2014-02-05 23:19:34 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.