laotao / protobuf

Automatically exported from code.google.com/p/protobuf
Other
0 stars 0 forks source link

static initialization problem with dlopen #370

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
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.

Original issue reported on code.google.com by ek.k...@gmail.com on 29 Jan 2012 at 5:55

Attachments:

GoogleCodeExporter commented 9 years ago
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?

Original comment by w...@phrenotherapy.com on 26 Apr 2012 at 4:28

GoogleCodeExporter commented 9 years ago
I just tried this fix but it is not working. I will be trying to understand 
why. 

Original comment by montoya....@gmail.com on 29 May 2012 at 2:15

GoogleCodeExporter commented 9 years ago
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

Original comment by montoya....@gmail.com on 29 May 2012 at 3:47

GoogleCodeExporter commented 9 years ago
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).

Original comment by asierg...@gmail.com on 12 Jul 2012 at 9:28

GoogleCodeExporter commented 9 years ago
We did not have this problem in Windows 7 with VisualStudio 2010

:(

Anyway, We finally decided to switch to apache thrift.

Original comment by montoya....@gmail.com on 13 Jul 2012 at 10:57

GoogleCodeExporter commented 9 years ago
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 ?

Original comment by ssj...@gmail.com on 5 Nov 2012 at 2:58

GoogleCodeExporter commented 9 years ago
you can use protobuf dynamic complier to avoid this problem

Original comment by ssj...@gmail.com on 5 Nov 2012 at 4:49

GoogleCodeExporter commented 9 years ago
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 .

Original comment by ylee...@gmail.com on 13 Jan 2013 at 3:21

GoogleCodeExporter commented 9 years ago
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?

Original comment by richardg...@gmail.com on 1 Mar 2013 at 5:29

GoogleCodeExporter commented 9 years ago
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.

Original comment by richardg...@gmail.com on 6 Mar 2013 at 3:18

Attachments:

GoogleCodeExporter commented 9 years ago
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.

Original comment by ek.k...@gmail.com on 7 Mar 2013 at 4:21

GoogleCodeExporter commented 9 years ago
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.

Original comment by scpet...@osrfoundation.org on 3 Apr 2014 at 7:06