Hi Rob,
Is there any way to get more information about the objects it says have
leaked?
I'm surprised that your tool is showing objects being freed on exit that
aren't freed by deleting outp and calling
google::protobuf::ShutdownProtobufLibrary(). I don't think the protobuf
library installs
Well, not technically a leak because the memory eventually does get deleted
on exit, but for my every call to ParseFromArray() I'm seeing a few hundred
small allocations which stick around until exit, These add up when I need
to call ParseFromArray() >100k times and cause quite a memory surge
Updates:
Status: Fixed
Owner: xiaof...@google.com
Labels: FixedIn-2.6.1
Comment #1 on issue 675 by xiaof...@google.com: memory leak
https://code.google.com/p/protobuf/issues/detail?id=675
Fixed in:
https://github.com/google/protobuf/commit
Status: New
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 675 by vxm...@gmail.com: memory leak
https://code.google.com/p/protobuf/issues/detail?id=675
A memory leak is detected by vld(visual leak detector).
I think the problem is caused by this function:
void
Status: New
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 661 by wbenf...@gmail.com: Python: memory leak in
protobuf.reflection.ParseMessage()
http://code.google.com/p/protobuf/issues/detail?id=661
What steps will reproduce the problem?
import google
import
Status: New
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 542 by leening0...@gmail.com: The memory leak problem
http://code.google.com/p/protobuf/issues/detail?id=542
In the resume of protocol buffer, there are some descriptions like
these: Reuse message objects when
issue 542 by leening0...@gmail.com: The memory leak problem
http://code.google.com/p/**protobuf/issues/detail?id=542http://code.google.com/p/protobuf/issues/detail?id=542
In the resume of protocol buffer, there are some descriptions like these:
Reuse message objects when possible. Messages try
Updates:
Status: OutOfScope
Comment #1 on issue 542 by xiaof...@google.com: The memory leak problem
http://code.google.com/p/protobuf/issues/detail?id=542
As Stephen Tu mentioned in the discussion group, using tcmalloc doesn't
require any code change.
--
You received this message
#2 on issue 542 by leening0...@gmail.com: The memory leak problem
http://code.google.com/p/**protobuf/issues/detail?id=542http://code.google.com/p/protobuf/issues/detail?id=542
You means I will still use new, and it will call the tcmalloc
automatically.
--
You received this message because
Any new process of this issue? .
On Monday, September 26, 2011 9:12:09 PM UTC+8, kyo...@gmail.com wrote:
when you running The C++ implementation for Python.
from proto import test_pb2
r = tes_pb2.SkillResult()
import gc
gc.set_debug(gc.DEBUG_LEAK)
gc.garbage
[]
when you running The C++ implementation for Python.
from proto import test_pb2
r = tes_pb2.SkillResult()
import gc
gc.set_debug(gc.DEBUG_LEAK)
gc.garbage
[]
gc.collect()
0
gc.set_debug(gc.DEBUG_LEAK)
gc.collect()
0
del r
gc.collect()
gc: collectable SkillResult 0x26d012ec
gc:
js.stoe...@gmail.com
wrote:
Hello,
I am observing a memory leak after including the protobufs in my
project. I would like to investigate whether this leak is due to this
library or the use I make of it.
I am using the protobufs (latest version) with VC++, running 3
threads.
2 server threads
Hello,
I am observing a memory leak after including the protobufs in my
project. I would like to investigate whether this leak is due to this
library or the use I make of it.
I am using the protobufs (latest version) with VC++, running 3
threads.
2 server threads are pending, waiting
On Thu, Sep 2, 2010 at 08:03, Jean-Sebastien Stoezel
js.stoe...@gmail.com wrote:
Hello,
I am observing a memory leak after including the protobufs in my
project. I would like to investigate whether this leak is due to this
library or the use I make of it.
I am using the protobufs (latest
'dirToFill.set_name(this-getName
().toStdString());'[4] to avoid memory leak from my code and kept only
the Protocol Buffer methods. I also removed the serialize call
'Common::PersistantData::setValue(FILE_CACHE, hashes);'[3].
Nonetheless I always observe some memory leak.
Does it due to memory fragmentation
Tried to remove all 'set' like 'dirToFill.set_name(this-getName
().toStdString());'[4] to avoid memory leak from my code and kept only
the Protocol Buffer methods. I also removed the serialize call
'Common::PersistantData::setValue(FILE_CACHE, hashes);'[3].
Nonetheless I always observe some memory
Jason Hsueh wrote:
Are you sure the leak is due to persistCacheToFile()?
Does it due to memory fragmentation ? It's very strange because this
method 'FileManager::persistCacheToFile()'[3] should delete all its
memory when it returns. Should I use a other memory allocater like
tcmalloc ?
I
Thanks.
From: Kenton Varda [mailto:ken...@google.com]
Sent: Monday, July 06, 2009 1:32 PM
To: Alex Black
Cc: Protocol Buffers
Subject: Re: GoogleOnceType showing up as a memory leak
Yes, this is a known bug resulting from the fact that I developed the
shutdown
Isn't this a common scenario in C++ for which stdlib provides a simple
solution, std::auto_ptr? std::auto_ptr is a lightweight class designed
to RAIIify pointers. What am I missing?
On Mar 4, 3:06 pm, Kenton Varda ken...@google.com wrote:
http://code.google.com/p/protobuf/issues/detail?id=54
On Fri, Mar 6, 2009 at 5:50 AM, marc vaill...@cis.jhu.edu wrote:
Isn't this a common scenario in C++ for which stdlib provides a simple
solution, std::auto_ptr? std::auto_ptr is a lightweight class designed
to RAIIify pointers. What am I missing?
Deleting the objects on shutdown is easy.
The only reason you aren't seeing a problem with that code is because it
exits very quickly after ~B() is called, before the other thread gets a
chance to be scheduled again. In a large program, shutdown might not be so
fast. Try putting a sleep(1) at the end of B::~B() -- you'll see that the
Ok, thanks. There are other problems though. If A::b was a B* instead
of a std::auto_ptrB, then the data that A::b points to will be ok
because it won't be deleted. However, A::b would get deleted so access
to the data via A::b may be undefined.
Also I found that static vars local to the
On Fri, Mar 6, 2009 at 6:41 PM, Marc Vaillant m...@jhu.edu wrote:
Ok, thanks. There are other problems though. If A::b was a B* instead
of a std::auto_ptrB, then the data that A::b points to will be ok
because it won't be deleted. However, A::b would get deleted so access
to the data via
Hi,
I'm using protocol buffers in my project (C++), and while I was
hunting for memory leaks, I discovered that in the generated code,
static members are being allocated, but there's no way to free them.
It's not a major issue, because the leak only occur when you exit the
application (and the
I'm using protocol buffers in my project (C++), and while I was
hunting for memory leaks, I discovered that in the generated code,
static members are being allocated, but there's no way to free them.
yes.
It's not a major issue, because the leak only occur when you exit the
application
Perhaps you could use protobuf-c which uses global variables for its
metadata and hence has no leaks upon unload (as long as you free all
your messages of course).
- dave
On Mar 4, 4:08 am, Ivan Kharin korsar.ak...@gmail.com wrote:
I'm using protocol buffers in my project (C++), and while I
http://code.google.com/p/protobuf/issues/detail?id=54
On Wed, Mar 4, 2009 at 3:50 AM, Adam adamo...@gmail.com wrote:
Hi,
I'm using protocol buffers in my project (C++), and while I was
hunting for memory leaks, I discovered that in the generated code,
static members are being allocated,
27 matches
Mail list logo
