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
== nginx.log
2010/05/13 16:34:03 [error] 11448#0: *226 upstream prematurely closed
connection while reading response header from upstream, client:
78.147.1.152, server: _, request: "PUT
/invites/726a50c3400d2fa16c7ec9e29512ac2cb69b52c8 HTTP/1.1", upstream:
"http://unix:/var/apps/sd/tmp/unicorn.sock:/invites/726a50c3400d2fa16c7ec9e29512ac2cb69b52c8",
host: "ec2-174-129-71-76.compute-1.amazonaws.com", referrer:
"http://ec2-174-129-71-76.compute-1.amazonaws.com/events/djk5qipe87bas51z0qrgeukrr"
== unicorn.stderr.log
I, [2010-05-13T16:34:03.869423 #15332] INFO -- : reaped
#<Process::Status: pid 15398 SIGSEGV (signal 11)> worker=15I,
[2010-05-13T16:34:03.890454 #15429] INFO -- : worker=15 spawned
pid=15429
I, [2010-05-13T16:34:03.890669 #15429] INFO -- : worker=15 readyI,
[2010-05-13T16:34:55.650233 #15332] INFO -- : reloading
config_file=config/unicorn.rb
I, [2010-05-13T16:34:58.583076 #15332] INFO -- : Refreshing Gem list
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
>> == 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...Hi Eric You''re absolutely right. The problem had nothing to do with Unicorn. JSON 1.4.3 was segfaulting on that particular hash - I don''t know why just yet - but all worked as expected when I reverted to JSON 1.4.2. Many thanks Paul