On Dec 18, 2013, at 7:17 PM, Andreas Hartmetz wrote:
> 2) reminds me of a crazy idea I've had once... freeing memory (not
> object destruction!) at application exit really serves no other purpose
> than making leak checkers happy. Not saying that this isn't an
> important goal, btw. So shutdown c
On quinta-feira, 19 de dezembro de 2013 09:16:32, Albert Astals Cid wrote:
> But that needs:
> a) A central place to write down those investigated places that have been
> proven to be harmless so that not N people waste their time investigating
> b) Reinvestigation every X time to make sure it i
On 19 Dec 2013, at 11:29, Tim Blechmann wrote:
>>> Should Qt clean-up dynamically allocated reachable pointers, or is this
>>> useless / pointless work?
> [snip]
>> 2) static leak, which is when the pointer is overwritten at shutdown without
>> being freed
> i wonder: what is the definition of "s
>> In QtQuick, QSGRenderLoop::instance() can create a QSGWindowsRenderLoop
>> using new that it never destroys. The memory is always pointed to by a
>> static member pointer, so it's never "lost" exactly, but the memory is
>> never freed by Qt (but hopefully will be by any decent OS). Is this a bug
On Thursday 19 December 2013, Andreas Hartmetz wrote:
> On Wednesday 18 December 2013 09:34:37 Sorvig Morten wrote:
> > On 18 Dec 2013, at 01:22, Thiago Macieira
wrote:
> > > If it turns out that the failure to destroy is harmless, I'm not sure
> > > we should do anything. If it's harmless, that
On Wednesday 18 December 2013 16:52:06 Thiago Macieira wrote:
> On quarta-feira, 18 de dezembro de 2013 16:41:08, Alex Montgomery wrote:
> > I think Thiago made a great point when he said, "Objects not properly
> > destroyed at shutdown could be an indication of something else wrong". The
> > thing
On quarta-feira, 18 de dezembro de 2013 17:03:56, Alex Montgomery wrote:
> I especially like the idea of creating an ignore list for valgrind if we
> could use it for unit tests. Then at least people would have to be
> conscious about the memory leaks they create and add them to the valgrind
> igno
I especially like the idea of creating an ignore list for valgrind if we
could use it for unit tests. Then at least people would have to be
conscious about the memory leaks they create and add them to the valgrind
ignore list if they are intentional.
___
On quarta-feira, 18 de dezembro de 2013 16:41:08, Alex Montgomery wrote:
> I think Thiago made a great point when he said, "Objects not properly
> destroyed at shutdown could be an indication of something else wrong". The
> thing that scares me most about the philosophy that we don't have to delete
Hello,
I think Thiago made a great point when he said, "Objects not properly
destroyed at shutdown could be an indication of something else wrong". The
thing that scares me most about the philosophy that we don't have to delete
reachable dynamically allocated objects is that those objects never ha
On Wednesday 18 December 2013 09:34:37 Sorvig Morten wrote:
> On 18 Dec 2013, at 01:22, Thiago Macieira wrote:
> > If it turns out that the failure to destroy is harmless, I'm not sure we
> > should do anything. If it's harmless, that means the extra work required
> > to
> > free the memory is was
On 18 Dec 2013, at 01:22, Thiago Macieira wrote:
>
> If it turns out that the failure to destroy is harmless, I'm not sure we
> should do anything. If it's harmless, that means the extra work required to
> free the memory is wasted, since it has no benefit to anyone. Just wasted CPU
> cycles.
On terça-feira, 17 de dezembro de 2013 15:42:36, Alex Montgomery wrote:
> In QtQuick, QSGRenderLoop::instance() can create a QSGWindowsRenderLoop
> using new that it never destroys. The memory is always pointed to by a
> static member pointer, so it's never "lost" exactly, but the memory is
> never
Hi everybody,
We had a small discussion on the #qt-labs IRC channel about memory leaks
earlier, and I'd like to get a feel from the community in general.
In QtQuick, QSGRenderLoop::instance() can create a QSGWindowsRenderLoop
using new that it never destroys. The memory is always pointed to by a
14 matches
Mail list logo
