Re: assertion crash with debug build on windows
I'm sorry to revive this old thread but I HAD to thank you. I've been working on porting some C++ code from Linux to Windows and was getting assertion failures when dealing with vectors. I spent countless hours trying to fix the problem but could not find a solution. Adding the preprocessor defines you specified fixed my issues. Thank you so very much! On Jul 16, 5:14 am, Mr Moose wrote: > It is found! > > After 4 interesting days of debugging the bastard I realized that I > rercently had to add 3 preprocessor defines to my build system: > > _CRT_SECURE_NO_WARNINGS > _SECURE_SCL=0 > _HAS_ITERATOR_DEBUGGING=0 > > If they are missing, many things[tm] won't work properly in debug > build. Things such as several boost components for instance. So I set > them defines and forgot about them. Hence the crashes in libprotobuf. > Now I added same defines to the libprotobuf target in the .sln file of > 2.1.0. After a complete rebuild things work fine. > > Which one of the defines was responsible and why remains obscure but I > tend to think _SECURE_SCL might alter headers and type definitions to > the using app and the lib are using differently sized types. > > Cheers, > > Stephan > > On 16 Jul., 09:29, Mr Moose wrote: > > > OK, just for the records: Now I can be really sure. I've deleted > > everything that remotely resembles a release build and changed my > > build system so it won't create any and work without. And still the > > bug occurs. So I don't think it is related to Microsoft runtime > > issues. > > > Cheers, > > Stephan > > > On 16 Jul., 08:33, Mr Moose wrote: > > > > Kenton, > > > > well, I checked this over and over again and I really think I did make > > > sure. I also checked the linker settings for all other libs I link > > > against and they are all set to Debug. Also, this is the same build > > > environment I used with 2.0.3. where it did work. On the other hand, > > > it's Microsoft so you can never be really sure what's going on. > > > Anyway, is there any other possible explanation for said crashes? > > > > Cheers, > > > > Stephan > > > > On 15 Jul., 20:25, Kenton Varda wrote: > > > > > 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: assertion crash with debug build on windows
On Thu, Jul 16, 2009 at 5:41 PM, Henner Zeller wrote: > I wonder how many millions of hours of programmer productivity is lost > due to Microsofts build environment :/ > Yeah, I have the chance to compare it directly. Coming from pure Linux dev I am now on multiplatform Linux and Windows. And even though the code is 99% C++ and identical, I waste an incredible amount of time on such crap. Lib incompatibilities, build errors, libs that still linger around and are not actually replaced when restarting, debug vs release build and dependent libs and so on. When I first started to dev on that MS platform I tried to approach open minded and without much regards to all that preconcieved MS-is-bad attitude but now, half a year later, I am astonished every day at just how bad Windows as an application platform really is. I couldn't believe it and I absolutely don't understand why MS insists in making life so hard for developers. It practically forces the good guys and those who have a choice to choose something real. Please excuse my off topic rant but it was necessary 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 -~--~~~~--~~--~--~---
Re: assertion crash with debug build on windows
On Thu, Jul 16, 2009 at 11:14 AM, Mr Moose wrote: > > It is found! > > After 4 interesting days of debugging the bastard I realized that I > rercently had to add 3 preprocessor defines to my build system: > > _CRT_SECURE_NO_WARNINGS > _SECURE_SCL=0 > _HAS_ITERATOR_DEBUGGING=0 > > If they are missing, many things[tm] won't work properly in debug > build. Things such as several boost components for instance. So I set > them defines and forgot about them. Hence the crashes in libprotobuf. > Now I added same defines to the libprotobuf target in the .sln file of > 2.1.0. After a complete rebuild things work fine. > > Which one of the defines was responsible and why remains obscure but I > tend to think _SECURE_SCL might alter headers and type definitions to > the using app and the lib are using differently sized types. Yes, indeed. Changing _SECURE_SCL causes layout-changes in *all* STL containers. If you get weird crashes inside STL-containers, this is the first thing to check. > Cheers, > > Stephan > > > On 16 Jul., 09:29, Mr Moose wrote: >> OK, just for the records: Now I can be really sure. I've deleted >> everything that remotely resembles a release build and changed my >> build system so it won't create any and work without. And still the >> bug occurs. So I don't think it is related to Microsoft runtime >> issues. >> >> Cheers, >> Stephan >> >> On 16 Jul., 08:33, Mr Moose wrote: >> >> > Kenton, >> >> > well, I checked this over and over again and I really think I did make >> > sure. I also checked the linker settings for all other libs I link >> > against and they are all set to Debug. Also, this is the same build >> > environment I used with 2.0.3. where it did work. On the other hand, >> > it's Microsoft so you can never be really sure what's going on. >> > Anyway, is there any other possible explanation for said crashes? >> >> > Cheers, >> >> > Stephan >> >> > On 15 Jul., 20:25, Kenton Varda wrote: >> >> > > 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. > > > -- /Jesper #include "witty-quote.h" --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: assertion crash with debug build on windows
I wonder how many millions of hours of programmer productivity is lost due to Microsofts build environment :/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: assertion crash with debug build on windows
It is found! After 4 interesting days of debugging the bastard I realized that I rercently had to add 3 preprocessor defines to my build system: _CRT_SECURE_NO_WARNINGS _SECURE_SCL=0 _HAS_ITERATOR_DEBUGGING=0 If they are missing, many things[tm] won't work properly in debug build. Things such as several boost components for instance. So I set them defines and forgot about them. Hence the crashes in libprotobuf. Now I added same defines to the libprotobuf target in the .sln file of 2.1.0. After a complete rebuild things work fine. Which one of the defines was responsible and why remains obscure but I tend to think _SECURE_SCL might alter headers and type definitions to the using app and the lib are using differently sized types. Cheers, Stephan On 16 Jul., 09:29, Mr Moose wrote: > OK, just for the records: Now I can be really sure. I've deleted > everything that remotely resembles a release build and changed my > build system so it won't create any and work without. And still the > bug occurs. So I don't think it is related to Microsoft runtime > issues. > > Cheers, > Stephan > > On 16 Jul., 08:33, Mr Moose wrote: > > > Kenton, > > > well, I checked this over and over again and I really think I did make > > sure. I also checked the linker settings for all other libs I link > > against and they are all set to Debug. Also, this is the same build > > environment I used with 2.0.3. where it did work. On the other hand, > > it's Microsoft so you can never be really sure what's going on. > > Anyway, is there any other possible explanation for said crashes? > > > Cheers, > > > Stephan > > > On 15 Jul., 20:25, Kenton Varda wrote: > > > > 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: assertion crash with debug build on windows
OK, just for the records: Now I can be really sure. I've deleted everything that remotely resembles a release build and changed my build system so it won't create any and work without. And still the bug occurs. So I don't think it is related to Microsoft runtime issues. Cheers, Stephan On 16 Jul., 08:33, Mr Moose wrote: > Kenton, > > well, I checked this over and over again and I really think I did make > sure. I also checked the linker settings for all other libs I link > against and they are all set to Debug. Also, this is the same build > environment I used with 2.0.3. where it did work. On the other hand, > it's Microsoft so you can never be really sure what's going on. > Anyway, is there any other possible explanation for said crashes? > > Cheers, > > Stephan > > On 15 Jul., 20:25, Kenton Varda wrote: > > > 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: assertion crash with debug build on windows
Kenton, well, I checked this over and over again and I really think I did make sure. I also checked the linker settings for all other libs I link against and they are all set to Debug. Also, this is the same build environment I used with 2.0.3. where it did work. On the other hand, it's Microsoft so you can never be really sure what's going on. Anyway, is there any other possible explanation for said crashes? Cheers, Stephan On 15 Jul., 20:25, Kenton Varda wrote: > 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: assertion crash with debug build on windows
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 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 62C
>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::allocator
>
> >,std::allocator,std::allocator
> > > >::operator+=(int _Off=0) Line 147 + 0x55 bytesC++
>rpc.dll!
>
> std::_Vector_iterator,std::allocator
>
> >,std::allocator,std::allocator
> > > >::operator+=(int _Off=0) Line 363 C++
>rpc.dll!
>
> std::_Vector_iterator,std::allocator
>
> >,std::allocator,std::allocator
> > > >::operator+(int _Off=0) Line 369 + 0xc bytes C++
>rpc.dll!
>
> std::vector,std::allocator
>
> >,std::allocator,std::allocator
> > > >::insert
>
> (std::_Vector_iterator,std::allocator
>
> >,std::allocator,std::allocator
> > > > _Where={_Bx={...} _Mysize=??? _Myres=??? }, const
> std::basic_string,std::allocator > &
> _Val="MyService.proto") Line 855 + 0x38 bytes C++
>my.dll!
>
> std::vector,std::allocator
>
> >,std::allocator,std::allocator
> > > >::push_back(const
> std::basic_string,std::allocator > &
> _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,std::allocator > &
> name="MyService.proto") Line 1231 + 0x3d bytes C++
>my.dll!google::protobuf::DescriptorPool::FindFileByName(const
> std::basic_string,std::allocator > &
> 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 bytesC++
>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
-~--~~~~--~~--~--~---
