[Catalyst] Development Server Crashing

[Brandon Black]

On 6/21/06, Brandon Black <blblack at gmail.com> wrote:
> On 6/21/06, hkclark at gmail.com <hkclark at gmail.com> wrote:
> > When I run "script/myapp_server.pl -k" with the keepalive option (so
> > that things work with IE), I get the following crash (not right away,
> > but usually within the first few clicks):
> >
> > Use of uninitialized value in subroutine entry at
> > /usr/lib/perl5/5.8.5/i386-linux-thread-multi/Socket.pm line 370.
> > Bad arg length for Socket::unpack_sockaddr_in, length is 0, should be
> > 16 at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/Socket.pm line 370.
> >
> > Has anyone else run into this?
> >
> > Pretty much all of my modules are the latest & greatest from CPAN.
>
> I haven't run into this with Catalyst myself, but I have seen this
> issue in general a few times in the past, in totally different
> contexts.  My strong suspicion is that the problem lies in the method
> "_socket_data" in Catalyst::Engine::HTTP.
>
> If you look there, you will see where the results of getpeername() and
> getsockname() are used as arguments to sockaddr_in() in array context
> without checking validity first.  sockaddr_in() in array context calls
> unpack_sockaddr_in, which is then voicing the complaint you're seeing.
>
> Probably patching that subroutine to do something sane when !true
> values are returned by get{peer|sock}name would do the trick.  Like
> pretending the address is 0.0.0.0 or some such thing.
>

While I'm at this, I peeked at the other engines, and it looks like
Engine::Apache could stand to be patched to prevent the obscure
possibility of a similar issue w/ MP1.x by changing the line:

$c->request->hostname( $self->apache->connection->remote_host );

to

$c->request->hostname( $self->apache->get_remote_host );

The MP 1.x API docs for the two indicate why get_remote_host is the
better choice.  MP 2.0 docs seem to indicate it doesn't matter which
you use in that version.

I don't even have an Apache setup to test this on anymore, so I'll
leave actually trying and/or patching this to someone else.

-- Brandon