Yes, there are two parallel threads that do this at the same time. What I was noticing is that at application shutdown, my application complained about the lock I handed over to OpenSSL not being unlocked. Looking into it, I realized that during initialization, OpenSSL grabbed a lock from my callback, during this time, grpc replaced the locks and OpenSSL unlock call got re-routed. But again, this is just a side effect. The real problem is simply the fact that grpc is setting some global callbacks on OpenSSL that should best be left to the application. I understand that this is probably done to make it easy for the grpc integrators but there are applications such as mine where there are other usage of OpenSSL and I'd rather manage the global settings myself than rely on grpc to do it.
On Wednesday, April 18, 2018 at 3:05:05 PM UTC-7, jian...@google.com wrote: > > Could you describe the race condition in details? > > In gRPC ssl_transport_security, init_openssl() is only called when ssl > transport security is needed. In your application, you are > calling SSL_library_init() in a separate thread in parallel? > > > On Wednesday, April 18, 2018 at 2:46:28 PM UTC-7, Arpit Baldeva wrote: >> >> I am using grpc-1.10.0 and it has that code. Looking at the latest >> master, it still has that code - >> https://github.com/grpc/grpc/blob/master/src/core/tsi/ssl_transport_security.cc >> >> - see the init_openssl function. >> >> The problem is not just that grpc_init initialized the OpenSSL. The >> problem is really that grpc is initializing OpenSSL internally and it can >> trounce the application settings. Grpc should let application choose if >> they want it to handle the OpenSSL initialization or not. >> >> Thanks. >> >> On Wednesday, April 18, 2018 at 12:25:58 PM UTC-7, jian...@google.com >> wrote: >>> >>> Hi Arpit, >>> >>> grpc_init initializes OpenSSL for a short period (~2 days) and the code >>> was later removed. Do you still the problem, if you fetch the latest master? >>> >>> On Monday, April 16, 2018 at 2:22:32 PM UTC-7, Arpit Baldeva wrote: >>>> >>>> Hi, >>>> >>>> I recently pinned down a sporadic race condition in my application due >>>> to grpc intializing OpenSSL internally. The problem is that OpenSSL has >>>> some global callbacks that grpc is trying to initialize on it's own >>>> without >>>> the authorization of the application. The problem is in the >>>> init_openssl call in ssl_transport_security.cc which trounces similar >>>> calls from the application. The situation is made worse(race condition) if >>>> some application threads already have locks acquired via previous calls >>>> and >>>> then grpc changes the stuff underneath before the locks are released >>>> (hence >>>> the race condition). >>>> >>>> My application has usage of OpenSSL in a wider context than just grpc. >>>> I get the point that grpc is wrapping this up to make it easier for >>>> standing up an application with grpc but I think such type of things >>>> should >>>> be accompanied by a compile/run time option supplied at grpc_init that >>>> let's application decide the right owner. I am fine with the option >>>> defaulting to grpc initializing the OpenSSL internally. >>>> >>>> Thoughts? >>>> >>>> Thanks. >>>> >>> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/3df13436-d771-4450-85c3-d2683b08e976%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
