> > You aren't doing anything strange like using dlopen() to dynamically > load/unload libraries, are you?
Actually, yes, we have a shared library containing our protobuf code, which we do load with dlopen. A command line option tells the app which protocol it needs to use, and the app loads the appropriate library. The open only happens once, very shortly after program launch. We're not constantly loading and unloading. This has worked very well, for several weeks, using the SerializeToString functions. Only when we added use of SerializeToOstream did we start to have this issue. I can't think of anything obvious that > might cause this kind of error. The FileDescriptorTables are "static" > objects of sorts, I think. As my example code showed, I'm creating an ostream that is wrapped around a string buffer. The buffer and the ostream are transient objects. What are the 'static' FileDescriptors protobuf is holding? What's the relation between those and my transient ostreams? Are you calling ShutdownProtobufLibrary() > somewhere? Maybe more than once? Memory leaks *will* be reported by > valgrind if you don't call ShutdownProtobufLibrary(), but I don't know > what could cause a double free. > No, there is no call to ShutdownProtobufLibrary(). I read the bits about that in the c++ tutorial, and I will try to work that call into the code as I try to weed out the leaks, but those are secondary concern to the double free. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@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.
