Prematurely closed connection

Eric Wong normalperson at yhbt.net
Thu May 13 16:13:17 EDT 2010


Paul Carey <paul.p.carey at gmail.com> wrote:
> Hi
> 
> I've come across a puzzling issue. The code segment below works as
> expected, but if I replace :error => true with :error =>
> invite.errors, nginx serves a 502 as per the log below. invite.errors
> is normal hash.
> 
> I'm using a bundled merb 1.1 with Unicorn 0.99. Unicorn is a system
> gem. I'm running nginx 0.7.65. I've only experienced this issue with
> nginx / unicorn.
> I'd be grateful for any thoughts or pointers.
> 
> Many thanks
> Paul
> 
> == controller action, serving json
> if invite.save
>   display :ok => true
> else
>   Merb.logger.info "invite.errors #{invite.errors}"
>   display :error => true
> end

<snip>

Hi Paul,

> == unicorn.stderr.log
> I, [2010-05-13T16:34:03.869423 #15332]  INFO -- : reaped
> #<Process::Status: pid 15398 SIGSEGV (signal 11)> worker=15I,
                               ^^^^^^^

Uh oh, something is causing the Unicorn process to segfault in the
response phase.  Since Unicorn is only running Ruby code at that point,
I suspect there's something in your JSON enoder that's not liking
the serialization of invite.errors...

I'm not familiar with Merb at all, but I'd be curious to see how your
JSON encoder is handling the "invite.errors" hash.

Which version of Ruby, JSON/Yajl library, etc are you using?

Can you get us a backtrace?

Can you run with RACK_ENV=development to get Rack::Lint onto your
middleware stack?  Perhaps Merb isn't returning a 100% valid Rack
response and Rack::Lint will notice.

Thanks for any info you can provide.

-- 
Eric Wong


More information about the mongrel-unicorn mailing list