Issue 370 in protobuf: static initialization problem with dlopen
prot...@googlecode.com
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 370 by ek.k...@gmail.com: static initialization problem with
dlopen
http://code.google.com/p/protobuf/issues/detail?id=370
What steps will reproduce the problem?
1. create an application which contains foo/foo.pb.o (compiled with protoc
from protobuf-2.4.1)
2. create a shared library with contains foo/foo.pb.o
3. run the application and then the application is going to dlopen() the
shared library
What is the expected output?
Initialization of file descriptors with protobuf_AddDesc_* are just
invoked only at the startup of the application
Aborted What do you see instead?
Static initialization also occurs at the time of dlopen() and the
application crashes as follows.
libprotobuf ERROR google/protobuf/descriptor_database.cc:57] File already
exists in database: foo/foo.proto
libprotobuf FATAL google/protobuf/descriptor.cc:862] CHECK failed:
generated_database_->Add(encoded_file_descriptor, size):
terminate called after throwing an instance
of 'google::protobuf::FatalException'
what(): CHECK failed: generated_database_->Add(encoded_file_descriptor,
size):
What version of the product are you using?
Protobuf 2.4.1
On what operating system?
Debian wheezy
Please provide any additional information below.
If I changed src/google/protobuf/compiler/cpp/cpp_file.cc to use non-static
version of 'bool already_here' like in the attached file, the problem seems
to be solved.
Attachments:
cpp_file.cc.diff 1.1 KB
prot...@googlecode.com
Comment #1 on issue 370 by w...@phrenotherapy.com: static initialization
Has anyone else tried this fix? Do we know if this patch (or the error
that lead to it) have been fixed in 2.4.3?
prot...@googlecode.com
Comment #2 on issue 370 by montoya....@gmail.com: static initialization
I just tried this fix but it is not working. I will be trying to understand
why.
prot...@googlecode.com
Comment #3 on issue 370 by montoya....@gmail.com: static initialization
what I did was to set LOG messages at
src/google/protobuf/descriptor_database.cc
and
src/google/protobuf/message.cc
to warnings, returning true in the first one.
I know it is not ok.
maybe we should follow the following advice:
http://code.google.com/p/protobuf/issues/detail?id=128
prot...@googlecode.com
Comment #4 on issue 370 by asierg...@gmail.com: static initialization
Same problem. The patch did not fix my issue.
I am using protobuf 2.4.1 in Windows 7 and MingW (gcc version 4.4).
prot...@googlecode.com
Comment #5 on issue 370 by montoya....@gmail.com: static initialization
We did not have this problem in Windows 7 with VisualStudio 2010
:(
Anyway, We finally decided to switch to apache thrift.
prot...@googlecode.com
Comment #6 on issue 370 by ssj...@gmail.com: static initialization problem
with dlopen
http://code.google.com/p/protobuf/issues/detail?id=370
The design of the protobuf library is currently such that if you unload a
dynamic
library containing a protobuf class, you *must* simultaneously unload the
copy of
libprotobuf that it is linked against. Therefore, if you are writing a
dynamic
library which may be loaded and unloaded at runtime, you should probably
statically
link it against protocol buffers.
How to statically link it against protocol buffers? it really works ?
prot...@googlecode.com
Comment #7 on issue 370 by ssj...@gmail.com: static initialization problem
with dlopen
http://code.google.com/p/protobuf/issues/detail?id=370
you can use protobuf dynamic complier to avoid this problem
prot...@googlecode.com
Comment #8 on issue 370 by ylee...@gmail.com: static initialization problem
with dlopen
http://code.google.com/p/protobuf/issues/detail?id=370
using static library will not have this problem.I did.
reconfigure google buffer with :
configrue --disable-shared
before this step ,modify configure file at 2575 and 2578 line like this:
if test "x${ac_cv_env_CFLAGS_set}" = "x"; then :
CFLAGS="-fPIC"
fi
if test "x${ac_cv_env_CXXFLAGS_set}" = "x"; then :
CXXFLAGS="-fPIC"
than make ,it will be ok .
prot...@googlecode.com
Comment #9 on issue 370 by richardg...@gmail.com: static initialization
This is an issue even if you are not unloading shared libraries. We see
this assert when dlopen loads a shared library containing a protobuf class
that is contained in a static library included by both the .so and the
binary.
Can the assert changed to throw only when the message definitions are
different?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
prot...@googlecode.com
Comment #10 on issue 370 by richardg...@gmail.com: static initialization
I attach a quick fix to test for identical duplicate message definitons.
Build libprotobuf.so with this & link to it with your .so and binaries.
How it works : The protoc generated file calls InternalAddGeneratedFile
with the message description first. If the message name is already present,
and the description matches, it skips the assert error. Since this call is
first, asserts in subsequent functions (eg. InternalRegisterGeneratedFile)
are safe to ignore as we know the message description is identical. Whilst
this relies on the current implementation, it is backwards compatible
without an API change. I've successfully applied this to 2.3.0.
Attachments:
quick_patch.diff 1.9 KB
prot...@googlecode.com
Comment #11 on issue 370 by ek.k...@gmail.com: static initialization
Great! My solution in the original post requires updating protoc compiler
(libprotoc.so*) and re-generating *.pb.cc files in application side and
rebuilding. But the patch in #10 fixes the problem just replacing
libprotobuf.so*. I hope this will be integrated in the future version of
protobuf.
prot...@googlecode.com
Comment #12 on issue 370 by scpet...@osrfoundation.org: static
The patch in comment #10 works for us as well. Is there any chance that it
will be merged? I can generate some code to help reproduce the problem if
that would help.