Protocol Buffers can't use in visual studio 2003 ?

[篾片]

I build vsprojects in vs2003,get libprotobuf.lib and
libprotobuf.dll,and build add_person example successful,but when the
example running,popup some application error messagebox with memory
written error,both Debug and Release .Does Protocol Buffers can't use
in visual studio 2003 ? anyone can help me ?

[Lenjoy]

i don't know the dll and lib issue,

you can create a new project under the solution of vsprojects, then select the dependencies to lib*, then it will work.

 

2008/9/11 篾片 <mie...@gmail.com>

[Niall]

I get the same runtime error with MSVC 03.

Could some make available the required *.dlls and *.libs which I could
download and test with my IDE? This should tell whether it's the dll/
libs that MSVC 2003 makes are the root of the problem or whether it's
with program that's linking to them? Right?

> you can create a new project under the solution of vsprojects, then select
> the dependencies to lib*, then it will work.

I'm not certain what you mean there...

Thanks, Niall

[Kenton Varda]

I don't think DLLs or LIBs created with a never version of MSVC will work with MSVC 2003.  Protobufs use STL heavily in the interface, and I think the STL classes change from version to version.

[Niall]

Thanks for the reply. You're probably right... but I'm still not
convinced it wouldn't work. I couldn't imagine the STL's interface
changing. The implementation, sure, but I'd be surprised if the
interface would (There'd need to be a real good reason with all that
reference paperwork needing changing).

> Protobufs use STL heavily in the interface, and I think
> the STL classes change from version to version.

Sure, but if I can compile the DLL's and LIB's anyway I can't see this
being a problem.

This is just gut feeling, though. I can't find anything online to say
either way which would happen. Would it be worth trying anyway? If
possible.

[Kenton Varda]

Even if only the implementation changes -- specifically, the class's memory layout -- that will cause a binary incompatibility, especially since STL is all templates.  It seems the debug vs. release versions of MSVC's STL are not even binary compatible, so being compatible between two versions of MSVC seems doubtful.

[Niall]

> It seems the debug vs. release versions of MSVC's STL are
> not even binary compatible,

I hadn't heard of that before so I wrote a test case. Wrote a release
dll/lib and was able to compile both debug and release versions of a
'third party' application that would use the dll/lib/h files. Now,
this is similar in structure to how I have my own protobufs library
set up. Release dll/lib, that is. Though the binaries I compiled were
pitifully simple.

But, suppose you have the dll, a lib and the required header files.
You have all the things you need. The functions, their location, how
they are called. Surely the DLL would worry about itself. It's a
separate moster altogether to the source code you're trying to
compile, no? The DLL doesn't have to interface to anything. No
headers, no nothing. It only worries about itself, right? Just needs
to know what in the dll to execute, and that's managed by the lib
file, correct? All you should need are the entry/exit points I'd've
though. Though my understanding of DLLs is by no means infallible.

[Niall]

Sorry for the double post. I hit F5 stupidly. If someone could delete
one of the two above it'd be great.

Also, meant to say it sooner, but it's in the SerializeToOstream (and
I believe the Istream version too), function where the runtime errors
come.

[Kenton Varda]

On Tue, Sep 16, 2008 at 12:26 PM, Niall <two...@gmail.com> wrote:

But, suppose you have the dll, a lib and the required header files.

You have all the things you need. The functions, their location, how
they are called. Surely the DLL would worry about itself. It's a
separate moster altogether to the source code you're trying to
compile, no? The DLL doesn't have to interface to anything. No
headers, no nothing. It only worries about itself, right? Just needs
to know what in the dll to execute, and that's managed by the lib
file, correct? All you should need are the entry/exit points I'd've
though. Though my understanding of DLLs is by no means infallible.

If the STL implementations used by the DLL and its client are not compatible, then passing STL objects between the two will fail.  Microsoft even says explicitly in their docs that you cannot pass STL objects across DLL interfaces.  I've ignored this in protocol buffers because adhering to this rule would require huge changes to the interface (which was originally designed on Linux which has no such problems), and in practice it works so long as you compile the DLL with the same STL version as the rest of your app.  But, this is why we cannot distribute precompiled binaries -- they won't be compatible between versions of MSVC.

[Niall]

Finally. I see what you mean. Thanks for your help and clarification.
I wasn't aware of those issues. Thanks again!

Any suggestions on how I could use protobufs with MSVC '03? Without
the runtime errors when calling SerializeToOstream, that is. Lenjoy,

in the second post, said:

>you can create a new project under the solution of vsprojects, then
>select the dependencies to lib*, then it will work.

But I don't know what that means... I tried a couple of things, like
adding a new project to the solution I used in generating the DLLs,
libs etc. But with the same result.

[Kenton Varda]

I think you'll have to run it in a debugger and try to figure out the cause of the crash you're seeing.  I don't have a copy of MSVC '03, but if you send me the stack trace I could try to guess what's going on.

[Niall]

For some reason the debugger didn't even come to mind...

OK. It crashes at the 'bool
OstreamOutputStream::CopyingOstreamOutputStream::Write( const void*
buffer, int size )' function call. I think it's in the output_->write
function, but I'm not sure. If I try to step into output_->write it
crashes... without stepping into it... Not sure what that means.
What's the stack trace? Or I suppose how do I find it? Sounds fairly
self explanatory.

[Kenton Varda]

It sounds like output_ is not a valid pointer.  What's the full stack trace?

[Niall]

What's the stack trace?

If it's the debugging output this is what I have:

'protobuf_test.exe': Loaded 'C:\Documents and Settings\Niall\My
Documents\Visual Studio Projects\protobuf_test\Release
\protobuf_test.exe', Symbols loaded.
'protobuf_test.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No
symbols loaded.
'protobuf_test.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No
symbols loaded.
'protobuf_test.exe': Loaded 'C:\Documents and Settings\Niall\My
Documents\Visual Studio Projects\protobuf_test\Release
\libprotobuf.dll', Symbols loaded.
'protobuf_test.exe': Loaded 'C:\WINDOWS\system32\msvcp71.dll', No
symbols loaded.
'protobuf_test.exe': Loaded 'C:\WINDOWS\system32\msvcr71.dll', No
symbols loaded.
'protobuf_test.exe': Loaded 'C:\WINDOWS\system32\shimeng.dll', No
symbols loaded.
'protobuf_test.exe': Unloaded 'C:\WINDOWS\system32\shimeng.dll'
First-chance exception at 0x7c901010 in protobuf_test.exe: 0xC0000005:
Access violation reading location 0x50000075.
Unhandled exception at 0x7c901010 in protobuf_test.exe: 0xC0000005:
Access violation reading location 0x50000075.
The program '[3000] protobuf_test.exe: Native' has exited with code 0
(0x0).

[Kenton Varda]

It's the list of function calls which lead to the point of the crash.

[Niall]

Sorry about the delay. Took me ages to find it for some reason. And it
was a little tab in a window called 'Call Stack', which I assume is
the thing you mean.

ntdll.dll!7c918fea()
> libprotobuf.dll!google::protobuf::internal::WireFormat::WriteBytes(int field_number=2083927443, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & value={...}, google::protobuf::io::CodedOutputStream * output=0x00000000) Line 264 + 0x70 C++
ntdll.dll!7c91056d()
msvcr71.dll!7c363598()
libprotobuf.dll!
google::protobuf::internal::GeneratedMessageReflection::ListFields(const
google::protobuf::Message & message={...},
std::vector<google::protobuf::FieldDescriptor const
*,std::allocator<google::protobuf::FieldDescriptor const *> > *
output=0x7c3edae4) Line 279 + 0x1f C++
ntdll.dll!7c90104b()
msvcp71.dll!7c3c2cff()
msvcp71.dll!7c3c4083()
msvcp71.dll!7c3c12c3()
msvcp71.dll!7c3d0af8()
libprotobuf.dll!
google::protobuf::io::OstreamOutputStream::CopyingOstreamOutputStream::Write(const
void * buffer=0x00035a90, int size=24) Line 668 C++
libprotobuf.dll!
google::protobuf::io::CopyingOutputStreamAdaptor::WriteBuffer() Line
380 + 0xe C++
libprotobuf.dll!
google::protobuf::io::OstreamOutputStream::~OstreamOutputStream()
Line 643 C++
libprotobuf.dll!
google::protobuf::Message::SerializeToOstream(std::basic_ostream<char,std::char_traits<char>
> * output=0x0013fe20) Line 272 C++
protobuf_test.exe!main() Line 26 C++
protobuf_test.exe!mainCRTStartup() Line 259 + 0x12 C
kernel32.dll!7c816fd7()
ntdll.dll!7c915b4f()

[mcdowella]

There are at least two problems with using STL and even ordinary code
across DLL boundaries with MSVC, both of which can be hard to get
round. One is that if you link statically (select the non-DLL version
of the run time libraries) the code inside the DLL will use a
different storage pool from code outside the DLL, so store allocated
on one side of the boundary and freed on the other side of the
boundary will break the storage pool that tries to free it. This will
also happen if the run time library selected by the code in the DLL is
not identical to that selected by the program using it. Another
problem is that much of the STL implementation selected by Microsoft
does not use 0 as a special pointer value to mark the ends of linked
lists and such things. It tends to allocate a little chunk of memory
and use that instead. These marker values are not exported across the
DLL boundary, so somebody reading an STL structure created on the
other side of the DLL boundary will not recognise the end list marker
and will fall of the end and start using rubbish pointers.

See
http://support.microsoft.com/kb/172396
http://support.microsoft.com/kb/168958
http://www.deez.info/sengelha/2006/03/03/c-stl-dlls-and-buggy-optimizations/

[Kenton Varda]

Ugh.  More evidence that libprotobuf should be statically-linked, not a DLL.

Niall:  Maybe this explains your problem.  Can you try compiling static libs only and see if that fixes anything?

[mass...@gmail.com]

Make sure you link your client .exe to the same C runtime as
libprotobuf.dll (which should be the multi-threaded dll version). I
ran into this same exception and got it to work by making that change.
For debug builds use /MDd switch, for release builds use /MD. These
are set in the project's property pages under C/C++ --> Code
Generation --> Runtime Library. The problem the link above refers to
regarding NULL and class static variables has been fixed in VC7
(Visual Studio 2003) and thus should not be an issue for that
compiler.

On Sep 17, 12:16 pm, "Kenton Varda" <ken...@google.com> wrote:
> Ugh.  More evidence that libprotobuf should be statically-linked, not a DLL.
> Niall:  Maybe this explains your problem.  Can you try compiling static libs
> only and see if that fixes anything?
>
> On Tue, Sep 16, 2008 at 9:31 PM, mcdowella

> <mcdowe...@mcdowella.demon.co.uk>wrote:

>
>
>
> > There are at least two problems with using STL and even ordinary code
> > across DLL boundaries with MSVC, both of which can be hard to get
> > round. One is that if you link statically (select the non-DLL version
> > of the run time libraries) the code inside the DLL will use a
> > different storage pool from code outside the DLL, so store allocated
> > on one side of the boundary and freed on the other side of the
> > boundary will break the storage pool that tries to free it. This will
> > also happen if the run time library selected by the code in the DLL is
> > not identical to that selected by the program using it. Another
> > problem is that much of the STL implementation selected by Microsoft
> > does not use 0 as a special pointer value to mark the ends of linked
> > lists and such things. It tends to allocate a little chunk of memory
> > and use that instead. These marker values are not exported across the
> > DLL boundary, so somebody reading an STL structure created on the
> > other side of the DLL boundary will not recognise the end list marker
> > and will fall of the end and start using rubbish pointers.
>
> > See
> >http://support.microsoft.com/kb/172396
> >http://support.microsoft.com/kb/168958
>

> >http://www.deez.info/sengelha/2006/03/03/c-stl-dlls-and-buggy-optimiz...