Hey Guys, ''
I am developing a rails application for a client. Suffice it to say I
have to do some long running tasks so of course I used my favorite
plugin backgroundrb. Unfortunately I have a problem. I recently put some
new work into a background task that requires the use of ruburple (a gem
for connecting to IM protocols). Since then, I noticed that the worker
that uses it sometimes just stops running with no explanation.
I checked the logs and I assume the relevant code is below:
libnm_glib_nm_state_cb: dbus returned an error.
(org.freedesktop.DBus.Error.ServiceUnknown) The name
org.freedesktop.NetworkManager was not provided by any .service files
** (process:13909): CRITICAL **: xmlnode_set_attrib: assertion `value
!NULL'' failed
** (process:13909): CRITICAL **: xmlnode_set_attrib: assertion `value
!NULL'' failed
** (process:13909): CRITICAL **: xmlnode_set_attrib: assertion `value
!NULL'' failed
#{my_rails_app}/releases/.../vendor/plugins/backgroundrb/framework/core.rb:149:
[BUG] Segmentation fault
ruby 1.8.6 (2007-06-07) [i486-linux]
My question is two-fold:
1) what''s the best way to go about fixing this? How can I get more
detailed information regarding the problem here. I assume the
combination of the CRITICAL and the always fun segmentation fault is
killing the thread. How can I find and eliminate the problem or
implement exception handling so it ignores the issue.
2) How can I just force the thread back up if it dies. There has to be a
way to have backgroundrb recreate the thread if it dies, right? I mean
sure, that segmentation fault shouldn''t happen but if it does, I need a
way to bring the thread back online.
So if you could help with that I would appreciate it. I know ezra pokes
around here every once in a while.
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
BTW the app is running on ruby 1.8.6 (2007-06-07) [i486-linux] rails 2.0.1 ubuntu 7.10 gems are updated and the weird part is that the "segmentation fault" doesn''t happen every time. Most of the time it works just fine. However 1/5 times the fault will occur and the thread dies. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
BTW, the line that it references for the segmentation fault:
backgroundrb/framework/core.rb:149
# method starts event loop in the process
def start_reactor
Signal.trap("TERM") { terminate_me }
Signal.trap("INT") { shutdown }
loop do
check_for_timer_events
user_thread_window #=> let user level threads run for a while
ready_fds = select(@read_ios,@write_ios,nil,0.005) # HERE IT
FAILS!!!
#next if ready_fds.blank?
next if !ready_fds or ready_fds.empty?
ready_fds = ready_fds.flatten.compact
ready_fds.each do |t_sock|
if t_sock.is_a? UNIXSocket
handle_internal_messages(t_sock)
else
handle_external_messages(t_sock)
end
end
end
end
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
On Fri, Jan 25, 2008 at 5:18 PM, Nathan Esquenazi <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > BTW, the line that it references for the segmentation fault: > > > backgroundrb/framework/core.rb:149 > > > # method starts event loop in the process > def start_reactor > Signal.trap("TERM") { terminate_me } > Signal.trap("INT") { shutdown } > loop do > check_for_timer_events > user_thread_window #=> let user level threads run for a while > ready_fds = select(@read_ios,@write_ios,nil,0.005) # HERE IT > FAILS!!! > #next if ready_fds.blank? > > next if !ready_fds or ready_fds.empty? > > ready_fds = ready_fds.flatten.compact > ready_fds.each do |t_sock| > if t_sock.is_a? UNIXSocket > handle_internal_messages(t_sock) > else > handle_external_messages(t_sock) > end > end > end > end > >By any chance, can you run this thing with gdb? Also segmentation fault is one error from which process itself can''t recover and must be restarted from outside. You can have a monit script for that. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---