Re: [sqlite] More LSM leak

[Charles Samuels]

On Thursday, May 08, 2014 03:16:57 AM Dan Kennedy wrote:
> On 05/08/2014 06:59 AM, Charles Samuels wrote:
> > This leak cursor leak can be consistently reproduced by my test program,
> > but it doesn't occur every time you create and delete the cursor.
> 
> Hi,
> 
> Thanks for doing this.
> 
> I don't think the script is closing all the connections. There are
> 4 "open" commands and only 1 "close". I started adding a few "close"
> commands, which seemed to help, but then I got an LSM_MISUSE error
> (the tester program threw an exception) indicating that I was trying
> to close a connection without closing all of its cursors first.

You're right! I just noticed that I was doing something dumb while generating 
the trace that was causing certain closes to not be traced.

> 
> Even so - the "8 bytes definitely lost" is suspicious. I think that
> one at least might be a real leak.
It's not, now that I've fixed my problem.

> 
> I'm guessing the smaller.trace script is somehow created automatically.

Yes, definitely! The larger.trace is 4.8 GiB.

Thanks,

Charles
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] More LSM leak

[Dan Kennedy]

On 05/08/2014 06:59 AM, Charles Samuels wrote:

This leak cursor leak can be consistently reproduced by my test program, but
it doesn't occur every time you create and delete the cursor.

The files you'll need are:
http://www.derkarl.org/~charles/lsm/smaller.trace.bz2
http://www.derkarl.org/~charles/lsm/runlsm.cpp

(The latter of which has changed since the last time I provided it to this
list)


Hi,

Thanks for doing this.

I don't think the script is closing all the connections. There are
4 "open" commands and only 1 "close". I started adding a few "close"
commands, which seemed to help, but then I got an LSM_MISUSE error
(the tester program threw an exception) indicating that I was trying
to close a connection without closing all of its cursors first.

Even so - the "8 bytes definitely lost" is suspicious. I think that
one at least might be a real leak.

I'm guessing the smaller.trace script is somehow created automatically.
If it's easy enough to add the missing "close" commands (assuming they
really are missing), I'd like to see if it still leaks.

Thanks,
Dan.







$ cat smaller.trace | valgrind --leak-check=yes   ~/a.out lsm
==24046== Memcheck, a memory error detector
==24046== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==24046== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==24046== Command: /home/charles/a.out lsm
==24046==
==24046==
==24046== HEAP SUMMARY:
==24046== in use at exit: 39,507 bytes in 24 blocks
==24046==   total heap usage: 4,406,026 allocs, 4,406,002 frees, 149,648,738
bytes allocated
==24046==
==24046== 8 bytes in 1 blocks are definitely lost in loss record 1 of 22
==24046==at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==24046==by 0x41A61B: lsmPosixOsMalloc (lsm_unix.c:472)
==24046==by 0x40AF95: lsmMallocZero (lsm_mem.c:50)
==24046==by 0x40B000: lsmMallocZeroRc (lsm_mem.c:69)
==24046==by 0x40F5DC: multiCursorAddAll.isra.21 (lsm_sorted.c:2387)
==24046==by 0x40F64C: multiCursorInit (lsm_sorted.c:2400)
==24046==by 0x411C6E: lsmMCursorNew (lsm_sorted.c:2495)
==24046==by 0x40A52F: lsm_csr_open (lsm_main.c:774)
==24046==by 0x405539: main (runlsm.cpp:255)
==24046==


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users