Google Groups

Re: Building without RTTI support causes "make check" to hang (recursive call to pthread_once?)


Kenton Varda Aug 19, 2009 12:45 PM
Posted in group: Protocol Buffers
Sigh.  More bugs in descriptor bootstrapping, eh?

The problem is that without RTTI, MergeFrom(const Message& other) cannot tell if "other" is actually the exact same class as "this", so it has to fall back to reflection...  but reflection does not work if descriptors aren't available...  and we're in the middle of building said descriptors at the time.  So you get a deadlock, because descriptor initialization cannot complete until descriptor initialization completes.

The solution is to avoid calling the generic version of MergeFrom anywhere in descriptor.cc.  I'll put it on my TODO to fix this.  Note that this only matters if you use custom options -- if not you should be safe.

On Tue, Aug 18, 2009 at 8:42 PM, Oliver Jowett <oliver...@gmail.com> wrote:

Oliver Jowett wrote:

>> #4  0x00002b85e3ffb67a in google::protobuf::internal::ReflectionOps::Merge (from=@0x262e320, to=0x268f0e0) at ./google/protobuf/message.h:311
>> #5  0x000000000071dc4a in protobuf_unittest::ComplexOpt6::MergeFrom (this=0x268f0e0, from=@0x262e320) at google/protobuf/unittest_custom_options.pb.cc:3753
>> #6  0x00002b85e3fa844e in google::protobuf::internal::ExtensionSet::MergeFrom (this=0x268f048, other=<value optimized out>) at google/protobuf/extension_set.cc:644
>> #7  0x00002b85e3fdf191 in google::protobuf::MessageOptions::MergeFrom (this=0x268f040, from=@0x268a530) at google/protobuf/descriptor.pb.cc:4732

> The difference in behaviour is in this bit of generated code:
>
>> void MessageOptions::MergeFrom(const ::google::protobuf::Message& from) {

Sorry, wrong bit of code. The MessageOptions::MergeFrom in the
stacktrace is actually the "const MessageOptions &from" variant. It
looks like it's actually ComplexOpt6::MergeFrom that differs in
behaviour with RTTI off.

-O