Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
crash when protocol buffers are used in .so #206
Comments
KjellKod
commented
Jul 30, 2015
|
@fkusche did you find out what it was? Any work around? I believe a project that I am working on is experiencing a very similar issue. If we use .so then we see this crash. If we create it as a .a (static) then it doesn't happen. |
fkusche
commented
Aug 28, 2015
|
@KjellKod sorry for the late answer. No I did not find out anything more, unfortunately. |
xfxyjwf
added
wontfix
c++
labels
Jan 20, 2016
|
As protobuf has used some global variables, linking protobuf dynamically with dlopen across several modules are very problematic. I'm not aware of any good solution here. |
xfxyjwf
closed this
Jan 20, 2016
LocutusOfBorg
commented
May 18, 2017
|
Hello, if I'm correct this is making the vlc build segfault now |
llongi
referenced this issue
in inilabs/caer
Oct 3, 2017
Closed
cAER seg fault on exit with wrong configuration #113
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
fkusche commentedFeb 11, 2015
Consider the following
foo.cpp:and
bar.cpp:and
p.proto:Compile the proto file:
protoc --cpp_out=. p.protoCompile foo to an executable:
g++ -fPIC foo.cpp -ofoo -lprotobuf -ldlCompile bar to a dll:
g++ -fPIC -Wl,--unresolved-symbols=ignore-in-shared-libs -shared -o bar.so bar.cpp p.pb.cc -lprotobufrunning
foowill produce a segmentation fault inShutdownProtobufLibrary():Without dlopening bar.so, there will be no segfault.
Also, when p.pb.cc is not compiled into bar.so.
Is this because of global constructors/destructors being executed?
How can this be solved?