Cannot install HTTP::Proxy under Strawberry Perl 5.10.0.3

[jds17]

Dear fellow monks, has anyone managed to install HTTP::Proxy 0.23 under Strawberry Perl 5.10.0.3? The cpan install gets stuck at test no. 22. Using the debugger on this test and stepping through as far as possible, I found a call of IO::Socket::sockname(), where the passed socket argument at least is not undefined, though something obviously seems to be wrong with it:

perl -d t/22http.t
  DB<1>b IO::Socket::sockname
  DB<2> c
IO::Socket::sockname(C:/strawberry/perl/lib/IO/Socket.pm:245):
245:        @_ == 1 or croak 'usage: $sock->sockname()';

  DB<2> v
244     sub sockname {
245==>b     @_ == 1 or croak 'usage: $sock->sockname()';
246:        getsockname($_[0]);
247     }

  DB<2> x $_[0]
0  HTTP::Daemon=GLOB(0x187d804)
   -> *Symbol::GEN1
         FileHandle({*Symbol::GEN1}) => fileno(7)

  DB<3> n
IO::Socket::sockname(C:/strawberry/perl/lib/IO/Socket.pm:246):
246:        getsockname($_[0]);

  DB<3> n     <--------never returns

The call to getsockname never returns. Do you have an idea what goes wrong here or how I can further analyze this?

[almut]

Not sure, but maybe this is somehow related to getsockname() blocks indefinitely?.

Also, I had myself once experienced similar weirdness with getsockname depending on the setting of SO_EXCLUSIVEADDRUSE (Windows-specific socket option), though you'd think that both should be unrelated.  (Unfortunately, I can no longer remember the details, nor can I come up with a test case that would reproduce the issue — but maybe it rings a bell with someone else...)

[jds17]

Hi Almut,
thanks a lot for your suggestions, they look promising. I will take a fresh look at them in the morning.

[Anonymous Monk]

. Do you have an idea what goes wrong here or how I can further analyze this?

First I would dump %INC and see if I could upgrade any modules ( compare with cpanp  o):

Read more... (2 kB)
After that I'd check for any windows updates, after that I'd try using http://www.wireshark.org/ to see if I could figure it out.

22http.t had worked for me about a dozen times, but then it started hanging. I restarted "dhcp client" (start services.msc or issue net stop "dhcp client" then net start "dhcp client"), and it went back to working again. On the other hand, 90diveintomark.t always hang after "ok 1", no matter what I do.

ok 1 - 200.xml => 200
# hangs for a few minutes
not ok 2 - 220.xml => 220
#   Failed test '220.xml => 220'
#   at t\90diveintomark.t line 93.
#          got: '500'
#     expected: '220'
# hangs for a few minutes here too
#   Failed test '320.xml => 320'
#   at t\90diveintomark.t line 93.
#          got: '500'
#     expected: '320'

It seems like for me its related to my ISP's intermittent routing/DNS issues, which they eventually fix (takes a whole day sometimes).

[jds17]

I used wireshark and filtered for dhcp related entries but could not find anything suspicious, but I must admit I do not have any experience using this tool.

I will try to install HTTP::Proxy at home, too and see if I can spot any differences to the behaviour at work.