grpc crash in a forked process (ruby) #26257
Comments
|
This cannot be reproduced with the extension built on macOS 11.4 and run in 11.4. Crash log with debug info: Application Specific Information: The crash happens in parseSystemVersionPList which is LLVM runtime function.
|
|
Having this same issue trying to run any example of My environment:
UPDATE |
|
great! Thanks for the update |
|
I can still reproduce this issue: Using the following gem versions Using this ruby: Using macos I even tried to match your ruby version and it's still crashing: |
could you please try compiling grpc from the source? There are some libs need to be updated too. |
I added gem 'grpc', github: 'grpc/grpc', submodules: trueto my Gemfile and it didn't crash! |
|
I'm seeing this as well. Seems to occur when the gRPC server is down. [1] pry(main)> require_relative './lib/grpc/health_services_pb'
=> true
[2] pry(main)> stub = Grpc::Health::V1::Health::Stub.new(Gruf.server_binding_url, :this_channel_is_insecure)
=> #<Grpc::Health::V1::Health::Stub:0x0000000105491cf8
@ch=#<GRPC::Core::Channel:0x0000000105491758>,
@host="127.0.0.1:9001",
@interceptors=#<GRPC::InterceptorRegistry:0x0000000105491690 @interceptors=[]>,
@propagate_mask=nil,
@timeout=1969-12-31 18:59:59 -0500>
[3] pry(main)> stub.check Grpc::Health::V1::HealthCheckRequest.new
=> <Grpc::Health::V1::HealthCheckResponse: status: :SERVING>
[4] pry(main)> stub.check Grpc::Health::V1::HealthCheckRequest.new
objc[44682]: +[__NSTimeZone initialize] may have been in progress in another thread when fork() was called.
objc[44682]: +[__NSTimeZone initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.Between 3 and 4 I shut the gRPC server down.
|
This seems like something new. Could you open a new issue, and post the code and how to reproduce please? |
Same here. Suffering from this issue after updating grpcio to 1.48.1. Managed to prevent grpcio from crashing by adding environment variable |
|
I worked around this problem by calling # frozen_string_literal: true
if RUBY_PLATFORM.include?('darwin')
require 'fiddle'
require 'ffi'
module CFTimeZone
extend FFI::Library
ffi_lib '/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation'
attach_function :CFTimeZoneCopyDefault, [], :pointer
attach_function :CFRelease, [:pointer], :void
end
# Dynamically load Foundation.framework, ~implicitly~ initializing
# the Objective-C runtime before any forking happens in webserver
#
# From https://bugs.ruby-lang.org/issues/14009
Fiddle.dlopen '/System/Library/Frameworks/Foundation.framework/Foundation'
# grpc uses abseil-cpp to retrieve the local time zone via macOS APIs:
# https://github.com/abseil/abseil-cpp/blob/20230125.rc3/absl/time/internal/cctz/src/time_zone_lookup.cc#L139
#
# To ensure these APIs are not called in a forked process (https://github.com/grpc/grpc/issues/26257),
# load the required framework, retrieve the default time zone, and then release the resource.
default_time_zone = CFTimeZone.CFTimeZoneCopyDefault
CFTimeZone.CFRelease(default_time_zone)
endI suspect if |
|
I've created #33281 for #26257 (comment). |
|
original issue solved by updating environment, new issue tracked in #33281, closing. |
What version of gRPC and what language are you using?
version: 1.37.1
language: ruby
What operating system (Linux, Windows,...) and version?
macos 11.3.1
What runtime / compiler are you using (e.g. python version or version of gcc)
ruby 2.7.3p183 (2021-04-05 revision 6847ee089d) [x86_64-darwin20]
What did you do?
Gemfile
main.rb
What did you expect to see?
A successful response.
What did you see instead?
Anything else we should know about your project / environment?
When it doesn't run in a forked process, the code works.
I originally opened a bug with the google-ads-googleads ruby gem at googleads/google-ads-ruby#310 but since this looks like a grpc issue, I opened another bug here.
workaround
OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES bundle exec ruby main.rbdoesn't crash, but I don't think this is a good long term solution.crash log
ruby_2021-05-16-092847_Thomass-MacBook-Pro.crash.txt
The text was updated successfully, but these errors were encountered: