Re: assertion crash with debug build on windows
On Thu, Jul 16, 2009 at 11:14 AM, Mr Moosestephan.men...@gmail.com 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 stephan.men...@gmail.com 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 stephan.men...@gmail.com 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 ken...@google.com 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
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 stephan.men...@gmail.com 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 ken...@google.com 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
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 stephan.men...@gmail.com 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 stephan.men...@gmail.com 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 ken...@google.com 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 -~--~~~~--~~--~--~---
assertion crash with debug build on windows
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_iteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::operator+=(int _Off=0) Line 147 + 0x55 bytesC++
rpc.dll!
std::_Vector_iteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::operator+=(int _Off=0) Line 363 C++
rpc.dll!
std::_Vector_iteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::operator+(int _Off=0) Line 369 + 0xc bytes C++
rpc.dll!
std::vectorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::insert
(std::_Vector_iteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
_Where={_Bx={...} _Mysize=??? _Myres=??? }, const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Val=MyService.proto) Line 855 + 0x38 bytes C++
my.dll!
std::vectorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::push_back(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_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_stringchar,std::char_traitschar,std::allocatorchar
name=MyService.proto) Line 1231 + 0x3d bytes C++
my.dll!google::protobuf::DescriptorPool::FindFileByName(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
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
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 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 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_iteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::operator+=(int _Off=0) Line 147 + 0x55 bytesC++
rpc.dll!
std::_Vector_iteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::operator+=(int _Off=0) Line 363 C++
rpc.dll!
std::_Vector_iteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::operator+(int _Off=0) Line 369 + 0xc bytes C++
rpc.dll!
std::vectorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::insert
(std::_Vector_iteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
_Where={_Bx={...} _Mysize=??? _Myres=??? }, const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Val=MyService.proto) Line 855 + 0x38 bytes C++
my.dll!
std::vectorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::push_back(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_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_stringchar,std::char_traitschar,std::allocatorchar
name=MyService.proto) Line 1231 + 0x3d bytes C++
my.dll!google::protobuf::DescriptorPool::FindFileByName(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
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
