corrupted stack/heap when using statically-built gRPC on Windows

44 views
Skip to first unread message

Stéphane Charette

unread,
Nov 27, 2019, 1:54:13 PM11/27/19
to grpc.io
I'm writing a plugin for a Windows app.  I need grpc and protobufs to be statically linked into my plugin's dll.

In vcpkg, I created a new triplet to build static libs but dynamically linked with the runtime using /MD instead of /MT.  My triplet looks like this:

>type c:\src\vcpkg\triplets\x64-windows-mixed.cmake
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)

And then I installed grpc and protobufs like this:

vcpkg.exe install c-ares:x64-windows-mixed grpc:x64-windows-mixed openssl:x64-windows-mixed openssl-windows:x64-windows-mixed protobuf:x64-windows-mixed zlib:x64-windows-mixed

I link everything (protobuf::libprotoc protobuf::libprotobuf protobuf::libprotobuf-lite gRPC::gpr gRPC::grpc gRPC::grpc++ gRPC::grpc_cronet c-ares::cares c-ares::cares_static OpenSSL::SSL OpenSSL::Crypto ZLIB::ZLIB) into my .dll, and when it comes time to run the code, I get one of two problems.

Problem #1:  Cannot resolve "localhost":

E1127 10:17:30.456000000   496 resolver_registry.cc:80] don't know how to resolve 'localhost:56765' or 'dns:///localhost:56765'
E1127 10:17:30.457000000   496 resolver_registry.cc:80] don't know how to resolve 'dns:///localhost:56765' or 'dns:///dns:///localhost:56765'
E1127 10:17:30.458000000   496 channel.cc:83] channel stack builder failed: {"created":"@1574878650.457000000","description":"the target uri is not valid.","file":"C:\src\vcpkg\buildtrees\grpc\src\v1.23.1-ebfd5c51df\src\core\ext\filters\client_channel\client_channel.cc","file_line":1483}
E1127 10:17:30.459000000   496 channel_connectivity.cc:50] grpc_channel_check_connectivity_state called on something that is not a client channel, but 'lame-client'
STATE=channel has seen a failure that it cannot recover from

Found what I think is the solution to that here:  https://github.com/grpc/grpc/issues/11366  Because I'm create static libs, apparently I need to manually call grpc_init().

Problem #2:  Memory corruption.

As soon as I make that call to grpc_init(), memory is hosed.  In a debugger I see a segfault with no backtrace making me think the heap and/or stack is now completely hosed.  Considering how difficult of a time I've had trying to figure out how to build and link the dependencies into my .dll, I wouldn't be surprised if it is a "simple" compiler switch that I need to set, but at this point I have no idea where to go next.

Anyone have thoughts on what might be happening?

Stéphane Charette

Jan Tattermusch

unread,
Dec 5, 2019, 8:50:55 AM12/5/19
to grpc.io
Can you provide a minimal reproduction for the problem?
(include commands to run as a preparation and a simple C++ project that demonstrates the issue.)

You're right in the sense that you need to run grpc_init() before using gRPC in C++. There might be other problems in your code, but it's hard to know without seeing the actual code you run and the exact way you build.

ned...@gmail.com

unread,
Dec 9, 2019, 5:33:57 AM12/9/19
to grpc.io
I had something similar (many-many strange problems) until I've removed gRPC::grpc_cronet from the link list.
Reply all
Reply to author
Forward
0 new messages