Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser

From: Eric Wong <normalperson@yhbt.net>
To: Augusto Becciu <augusto@jadedpixel.com>
Cc: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
Date: Thu, 3 Jun 2010 16:40:30 -0700	[thread overview]
Message-ID: <20100603234030.GA18377@dcvr.yhbt.net> (raw)
In-Reply-To: <AANLkTimy0cLsh36A4pBoYMzZJY5wBKrxCp7rgCxyiZ53@mail.gmail.com>

Augusto Becciu <augusto@jadedpixel.com> wrote:
> On Wed, Jun 2, 2010 at 6:38 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Augusto Becciu <augusto@jadedpixel.com> wrote:
> >> On Wed, Jun 2, 2010 at 5:25 PM, Eric Wong <normalperson@yhbt.net> wrote:
> >> > Augusto Becciu <augusto@jadedpixel.com> wrote:
> >> >> Hey guys,
> >> >>
> >> >> Started running unicorn in a production server like two weeks ago.
> >> >> It's been running smoothly, but looking at the logs found 44
> >> >> exceptions like this:
> >> >>
> >> >> E, [2010-06-02T16:17:15.117071 #22680] ERROR -- : Read error:
> >> >> #<TypeError: can't modify frozen string>
> >> >> E, [2010-06-02T16:17:15.117270 #22680] ERROR -- :
> >> >> /usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
> >> >> `headers'
> >> >
> >> > <snip>
> >> >
> >> >> Ruby version: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux],
> >> >> MBARI 0x8770, Ruby Enterprise Edition 2010.01

<snip>

> >> There's no way our application could be freezing that constant, at
> >> least not intentionally.

<snip>

> Thanks Eric! Unfortunately after completely disabling RPM, we keep
> getting that error. :(
> 
> What else could it be?

Any details about your application you're allowed to share can help us,
especially a list of library/gem dependencies and versions.

I would grep through your gems and vendor directories to ensure there's
nothing freezing objects it shouldn't freeze.  It could also be a buggy
C extension corrupting memory somewhere, too...

This isn't happening for all your worker processes, is it?

If your application logs show which PID handled each request, you can
join the PIDs from the application logs with PIDs in the error logs
generated by Unicorn.  That lets you narrow down the possible requests
that could trigger the errors and help you reproduce the problem sooner.

This is one of my favorite features of one-request-per-process model
is that you can easily narrow down which request is triggering a
particular bug without worrying about race conditions from other
requests.

This is certainly the first time I've heard of this problem, so I think
it's specific to something in your application/environment.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying