Did you make sure to compile your debug build against a debug build of
libprotobuf? MSVC fails miserably when trying to mix and match debug vs.
release, apparently because the STL classes have different representations
between the two.
On Wed, Jul 15, 2009 at 7:38 AM, Mr Moose <stephan.men...@gmail.com> wrote:
>
> Hi there,
>
> I am experiencing crashes in a protocol buffers file using debug build
> on windows (VC2005). On Linux, debug or not and on Windows release
> everything is fine but when I try to run the code on debug it raises
> an assertion to crash right afterwards. I'm using 2.1
>
> here's what the stacktrace looks like:
>
> > msvcr80d.dll!_crt_debugger_hook(int _Reserved=) Line 62 C
> msvcr80d.dll!_invoke_watson(const wchar_t *
> pszExpression=0x1de19fc0, const wchar_t * pszFunction=0x1de27140,
> const wchar_t * pszFile=0x1de197a0, unsigned int nLine=147, unsigned
> int pReserved=0) Line 181 + 0x7 bytes C++
> msvcr80d.dll!_invalid_parameter(const wchar_t *
> pszExpression=0x1de19fc0, const wchar_t * pszFunction=0x1de27140,
> const wchar_t * pszFile=0x1de197a0, unsigned int nLine=147, unsigned
> int pReserved=0) Line 88 + 0x19 bytes C++
> rpc.dll!
>
> std::_Vector_const_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> > > >::operator+=(int _Off=0) Line 147 + 0x55 bytes C++
> rpc.dll!
>
> std::_Vector_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> > > >::operator+=(int _Off=0) Line 363 C++
> rpc.dll!
>
> std::_Vector_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> > > >::operator+(int _Off=0) Line 369 + 0xc bytes C++
> rpc.dll!
>
> std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> > > >::insert
>
> (std::_Vector_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> > > > _Where={_Bx={...} _Mysize=??? _Myres=??? }, const
> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
> _Val="MyService.proto") Line 855 + 0x38 bytes C++
> my.dll!
>
> std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> > > >::push_back(const
> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
> _Val="MyService.proto") Line 800 + 0x2d bytes C++
> my.dll!google::protobuf::DescriptorBuilder::BuildFile(const
> google::protobuf::FileDescriptorProto & proto={...}) Line 2715 C++
> my.dll!google::protobuf::DescriptorPool::BuildFileFromDatabase(const
> google::protobuf::FileDescriptorProto & proto={...}) Line 2193 + 0x4a
> bytes C++
> my.dll!
> google::protobuf::DescriptorPool::TryFindFileInFallbackDatabase(const
> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
> name="MyService.proto") Line 1231 + 0x3d bytes C++
> my.dll!google::protobuf::DescriptorPool::FindFileByName(const
> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
> name="MyService.proto") Line 875 + 0xc bytes C++
> my.dll!pwh::rpc::protobuf_AssignDesc_MyService_2eproto() Line 66 +
> 0x37 bytes C++
> my.dll!google::protobuf::GoogleOnceType::Init(void (void)*
> init_func=0x1dac3ddc) Line 73 + 0x5 bytes C++
> my.dll!google::protobuf::GoogleOnceInit
> (google::protobuf::GoogleOnceType * once=0x1dec2f74, void (void)*
> init_func=0x1dac3ddc) Line 104 C++
> my.dll!myns::`anonymous namespace'::protobuf_AssignDescriptorsOnce
> () Line 292 + 0xf bytes C++
> my.dll!myns::MyService::GetDescriptor() Line 3516 C++
>
>
> It all happens here:
>
> // If we have a fallback_database_, attempt to load all dependencies
> now,
> // before checkpointing tables_. This avoids confusion with
> recursive
> // checkpoints.
> if (pool_->fallback_database_ != NULL) {
> tables_->pending_files_.push_back(proto.name());
> for (int i = 0; i < proto.dependency_size(); i++) {
> if (tables_->FindFile(proto.dependency(i)) == NULL &&
> (pool_->underlay_ == NULL ||
> pool_->underlay_->FindFileByName(proto.dependency(i)) ==
> NULL)) {
> // We don't care what this returns since we'll find out below
> anyway.
> pool_->TryFindFileInFallbackDatabase(proto.dependency(i));
> }
> }
> tables_->pending_files_.pop_back();
> }
>
>
> So why actually any fallthrough? Is that supposed to happen or an
> indication for misusage?
> Using 2.0.3 this didn't happen.
>
> Unfortunately I really need to run on debug now to find some other
> problem in the code. Everything that comes to mind such as complete
> rebuilds I have tried over and over again.
>
> Maybe somebody here knows what to do...?
>
> Cheers,
>
> Stephan
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---
