Oh, if all you're worried about is compatibility then I would definitely
upgrade to the latest version (currently 3.4.1). We take great care to
preserve wire format compatibility and so all your existing serialized
messages will be readable with the latest protobuf version. You just have
to make sure that the version of protoc you use matches the runtime library
version your code links against, so if you have prebuilt any pb.h and pb.cc
files then you will need to regenerate those with the new protoc.
On Fri, Oct 27, 2017 at 6:56 AM, Chris Vavruska <vavru...@gmail.com> wrote:
> Yes, very early on during initialization of the library. My only concern
> with upgrading to a new version of protobuf is backward compatibility.
> Should I stick with 2.6 or go with 3.x? I know I can't use any of the new
> features but will all my current messages be recognizable across the
> different versions?
>
> Thanks
>
> On Thursday, October 26, 2017 at 3:28:05 PM UTC-4, Adam Cozzette wrote:
>>
>> When you say early on in application initialization, do you mean before
>> main() begins? Because if so then that might make things a little more
>> complicated. Using the non-lite version would probably not help very much
>> with debugging, since actually it adds more complexity by including
>> descriptors.
>>
>> It sounds like you may be stuck using an old version now, but if it's all
>> possible then you might want to consider upgrading, because it could well
>> be that this is a bug we've already fixed some time in the past few years.
>>
>> On Wed, Oct 25, 2017 at 11:46 AM, Chris Vavruska <vavr...@gmail.com>
>> wrote:
>>
>>> Hey all,
>>>
>>> I am using 2.4.1-lite in an embedded project. I know it is a bit old but
>>> it is what I have to live with for now. We send a message simple
>>> synchronous request from one application to another to get a list of files.
>>> It returns the following message.
>>>
>>> message return_m {
>>> optional string data = 1;
>>> repeated info_m file_info = 3;
>>> optional uint32 error = 4;
>>> optional volsize_m size = 5;
>>> }
>>> When we parse the response occasionally, I see the following crash which
>>> occurs early on in application initialization.
>>>
>>> [bt] linux-vdso32.so.1(__kernel_sigtramp_rt32+0x0)[0x100370] [bt] [0x9]
>>> [bt] /usr/lib/libprotobuflite.so.7(_ZN6google8protobuf8internal14
>>> WireFormatLite10ReadStringEPNS0_2io16CodedInputStreamEPSs+0x8c)[0xa46f8dc]
>>>
>>> [bt] /opt/appfs/lib/cp/libpbcpp.so.1(_ZN5filer6info_m27MergeParti
>>> alFromCodedStreamEPN6google8protobuf2io16CodedInputStreamE+0x244)[0xa755450]
>>>
>>> [bt] /opt/appfs/lib/cp/libpbcpp.so.1(_ZN6google8protobuf8internal
>>> 14WireFormatLite20ReadMessageNoVirtualIN5filer6info_
>>> mEEEbPNS0_2io16CodedInputStreamEPT_+0xa4)[0xa75bdb8]
>>> [bt] /opt/appfs/lib/cp/libpbcpp.so.1(_ZN5filer8return_m27MergePar
>>> tialFromCodedStreamEPN6google8protobuf2io16CodedInputStreamE
>>> +0x25c)[0xa75754c]
>>> [bt] /usr/lib/libprotobuf-lite.so.7(_ZN6google8protobuf11MessageL
>>> ite14ParseFromArrayEPKvi+0xb8)[0xa46d428]
>>>
>>> Looking at the core file it appear to have some sort of corruption.
>>> Would using the non-lite version give some additional
>>> information/protection? If so, then I am getting the following during init.
>>>
>>> #0 0x00000000 in ?? ()
>>> #1 0x0f124a74 in __cxxabiv1::__dynamic_cast (src_ptr=0xf1ec340
>>> <(anonymous namespace)::num_put_c>,
>>> src_type=0xf1e5f94 <typeinfo for std::locale::facet>,
>>> dst_type=0xf1e24ac <typeinfo for std::__gnu_cxx_ldbl128::num_put<char,
>>> std::ostreambuf_iterator<char, std::char_traits<char> > >>, src2dst=0)
>>> at /opt/codesourcery/powerpc-linux-gnu/src/gcc/libstdc++-v3/
>>> libsupc++/dyncast.cc:60
>>> #2 0x0f157e30 in std::has_facet<std::__gnu_cxx_ldbl128::num_put<char,
>>> std::ostreambuf_iterator<char, std::char_traits<char> > > > (__loc=...)
>>> at /opt/codesourcery/powerpc-linux-gnu/src/generated/gcc/powerp
>>> c-linux-gnu/libstdc++-v3/include/bits/locale_classes.tcc:110
>>> #3 0x0f149320 in std::basic_ios<char, std::char_traits<char>
>>> >::_M_cache_locale (
>>> this=this@entry=0xf1eb990 <std::cout+4>, __loc=...)
>>> at /opt/codesourcery/powerpc-linux-gnu/src/generated/gcc/powerp
>>> c-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:164
>>> #4 0x0f1494cc in std::basic_ios<char, std::char_traits<char> >::init
>>> (this=this@entry=0xf1eb990 <std::cout+4>,
>>> __sb=__sb@entry=0xf1ebbec <__gnu_internal::buf_cout_sync>)
>>> at /opt/codesourcery/powerpc-linux-gnu/src/generated/gcc/powerp
>>> c-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:132
>>> #5 0x0f1384f0 in basic_ostream (__sb=<optimized out>, this=<optimized
>>> out>, __in_chrg=<optimized out>,
>>> __vtt_parm=<optimized out>)
>>> at /opt/codesourcery/powerpc-linux-gnu/src/generated/gcc/powerp
>>> c-linux-gnu/libstdc++-v3/include/ostream:85
>>> #6 std::ios_base::Init::Init (this=<optimized out>)
>>> at /opt/codesourcery/powerpc-linux-gnu/src/gcc/libstdc++-v3/
>>> src/c++98/ios_init.cc:91
>>> ---Type <return> to continue, or q <return> to quit---
>>> #7 0x0f288970 in __static_initialization_and_destruction_0
>>> (__initialize_p=1, __priority=65535)
>>> at /opt/corp/projects/cdntools/embedtools/codebench-2014.05-53-
>>> powerpc-linux-gnu/powerpc-linux-gnu/include/c++/4.8.3/iostream:74
>>> #8 _GLOBAL__sub_I_zero_copy_stream_impl.cc(void) ()
>>> at /usr/src/debug/protobuf/2.4.1-r0/protobuf-2.4.1/src/google/p
>>> rotobuf/io/zero_copy_stream_impl.cc:470
>>> #9 0x0f326cac in __do_global_ctors_aux () from
>>> /vob/cb_releases/ppc-cetus-stable/usr/lib/libprotobuf.so.7
>>> #10 0x0f28869c in _init () from /vob/cb_releases/ppc-cetus-sta
>>> ble/usr/lib/libprotobuf.so.7
>>> #11 0xb7b2d5c8 in call_init (l=0xb7b0f020, argc=argc@entry=3,
>>> argv=argv@entry=0xbfdee474,
>>> env=env@entry=0xbfdee484) at dl-init.c:69
>>> #12 0xb7b2d778 in call_init (env=<optimized out>, argv=<optimized out>,
>>> argc=<optimized out>, l=<optimized out>)
>>> at dl-init.c:36
>>> #13 _dl_init (main_map=0xb7b3f908, argc=3, argv=0xbfdee474,
>>> env=0xbfdee484) at dl-init.c:132
>>> #14 0xb7b35fb8 in got_label () at ../sysdeps/powerpc/powerpc32/d
>>> l-start.S:66
>>> Backtrace stopped: frame did not save the PC
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Protocol Buffers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to protobuf+u...@googlegroups.com.
>>> To post to this group, send email to prot...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/protobuf.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
