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 prope
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
<[EMAIL PROTECTED]>wrote:
>
> There are at least two problems w
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 co
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, co
It's the list of function calls which lead to the point of the crash.
On Tue, Sep 16, 2008 at 1:48 PM, Niall <[EMAIL PROTECTED]> wrote:
>
> 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
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
sy
It sounds like output_ is not a valid pointer. What's the full stack trace?
On Tue, Sep 16, 2008 at 1:25 PM, Niall <[EMAIL PROTECTED]> wrote:
>
> For some reason the debugger didn't even come to mind...
>
> OK. It crashes at the 'bool
> OstreamOutputStream::CopyingOstreamOutputStream::Write( con
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
crashe
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.
On Tue, Sep 16, 2008 at 1:03 PM, Niall <[EMAIL PROTECTED]> wrote:
>
> Finally. I see w
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
On Tue, Sep 16, 2008 at 12:26 PM, Niall <[EMAIL PROTECTED]> 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 altog
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.
--~--~-~--~~~---~
> 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,
th
> 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,
th
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 M
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 chang
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.
On Tue, Sep 16, 2008 at 4:44 AM, Niall <[EMAIL PROTECTED]> wrote:
>
> I get the same runtime error with
d 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 ?
> >
>
--~--~-~--~~
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 ? anyon
19 matches
Mail list logo
