Opened 6 years ago
Closed 6 years ago
#923 closed defect (fixed)
Memory leak in GEOSNode
| Reported by: | Algunenano | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 3.8.0 |
| Component: | Default | Version: | main |
| Severity: | Significant | Keywords: | |
| Cc: |
Description
Small repro test: geos_leak.c (attached)
Leak (full log in leak_summary.log):
$ clang -fsanitize=address geos_leak.c -lgeos_c -L/usr/lib -I/usr/include/geos
$ ./a.out
=================================================================
==15579==ERROR: LeakSanitizer: detected memory leaks
Indirect leak of 88 byte(s) in 1 object(s) allocated from:
#0 0x563c03fb26a1 in __interceptor_malloc (/home/raul/dev/public/postgis/a.out+0xe66a1)
#1 0x7fdddba9e5fc in operator new(unsigned long) /build/gcc/src/gcc/libstdc++-v3/libsupc++/new_op.cc:50:40
#2 0x7fdddbcaa3e2 in geos::noding::GeometryNoder::extractSegmentStrings(geos::geom::Geometry const&, std::vector<geos::noding::SegmentString*, std::allocator<geos::noding::SegmentString*> >&) /usr/src/debug/geos/src/noding/GeometryNoder.cpp:157:12
#3 0x7fdddbcaa88b in geos::noding::GeometryNoder::getNoded() /usr/src/debug/geos/src/noding/GeometryNoder.cpp:123:24
#4 0x7fdddbcaaa55 in geos::noding::GeometryNoder::node(geos::geom::Geometry const&) /usr/src/debug/geos/src/noding/GeometryNoder.cpp:80:25
#5 0x7fdddc10f497 in GEOSNode_r /usr/src/debug/geos/capi/geos_ts_c.cpp:2450:76
#6 0x563c03fe6a75 in main (/home/raul/dev/public/postgis/a.out+0x11aa75)
#7 0x7fdddbd7f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
...
SUMMARY: AddressSanitizer: 360 byte(s) leaked in 8 allocation(s).
The issue wasn't there in rc1 (geos-git-3.7.0rc1.r9.g1be02b36 building from git) but it is there with current master/HEAD (geos-git-3.7.0rc1.r21.gbe8b3ffb).
Attachments (2)
Change History (20)
by , 6 years ago
| Attachment: | geos_leak.c added |
|---|
comment:1 by , 6 years ago
The issue was introduced in https://github.com/libgeos/geos/commit/e7adbc55a20633064d3af49f2662b17e5ca02e47
comment:2 by , 6 years ago
I am trying to reproduce the problem.
- I had to install clang (I did not have it on my computer
- build:
mkdir build cd build cmake .. make -j 2 && ctest --output-on-failure
- the tests results
[100%] Built target test_geos_unit Test project /home/vicky/potree/geos/vicky/build Start 1: test_geos_unit 1/8 Test #1: test_geos_unit ................... Passed 0.38 sec Start 2: test_xmltester 2/8 Test #2: test_xmltester ................... Passed 11.53 sec Start 3: test_bug234 3/8 Test #3: test_bug234 ...................... Passed 0.00 sec Start 4: test_sweep_line_speed 4/8 Test #4: test_sweep_line_speed ............ Passed 1.97 sec Start 5: perf_class_sizes 5/8 Test #5: perf_class_sizes ................. Passed 0.00 sec Start 6: perf_iterated_buffer 6/8 Test #6: perf_iterated_buffer ............. Passed 12.28 sec Start 7: perf_rectangle_intersects 7/8 Test #7: perf_rectangle_intersects ........ Passed 0.63 sec Start 8: perf_memleak_mp_prep 8/8 Test #8: perf_memleak_mp_prep ............. Passed 11.49 sec 100% tests passed, 0 tests failed out of 8 Total Test time (real) = 38.29 sec
- doing the install:
sudo make install sudo updatedb
- finnaly I could execute:
$ clang -fsanitize=address geos_leak.c -lgeos_c -L/usr/lib -I/usr/include/geos $ ./a.out ./a.out: error while loading shared libraries: libgeos.so.3.8.0dev: cannot open shared object file: No such file or directory
What am I missing?
comment:3 by , 6 years ago
You need to change the paths for your local environment (-L/usr/lib -I/usr/include/geos to, I guess, -L. -I./include or maybe -L/usr/local/lib -I/usr/include/geos).
If you need it I could try to setup the dev environment tomorrow and create an step by step guide from there.
comment:4 by , 6 years ago
You should also be able to see the same leak when compiling with gcc using the standard flags, by running the test executable through valgrind,
comment:5 by , 6 years ago
So, I am testing on the commit that merged to master: building with gcc
git checkout -b test-try2 8a9600bb2e617c788fdcdad8eb9e9045925bbd23
cleaned the build, and testing this
$ clang -fsanitize=address geos_leak.c -lgeos_c -L/home/vicky/geos/vicky/build/lib -I/home/vicky/geos/vicky/build/include -I /home/vicky/geos/vicky/include
geos_leak.c:1:10: fatal error: '/home/vicky/geos/vicky/build/capi/geos_c.h' file not found
#include "/home/vicky/geos/vicky/build/capi/geos_c.h"
^
1 error generated.
As you can see I adjusted to what is being build.
Building again.
Here, the missing file has being created, but not the libraries (they are on the process of building)
clang -fsanitize=address geos_leak.c -lgeos_c -L/home/vicky/geos/vicky/build/lib -I/home/vicky/geos/vicky/build/include -I /home/vicky/geos/vicky/include /usr/bin/ld: cannot find -lgeos_c clang: error: linker command failed with exit code 1 (use -v to see invocation)
So far so good (I think)
$clang -fsanitize=address geos_leak.c -lgeos_c -L/home/vicky/geos/vicky/build/lib -I/home/vicky/geos/vicky/build/include -I /home/vicky/geos/vicky/include $ ./a.out $
this didnt reproduce the problem
Now I am doing with valgrind:
$ gcc geos_leak.c -lgeos_c -L/home/vicky/geos/vicky/build/lib -I/home/vicky/geos/vicky/build/include -I /home/vicky/geos/vicky/include $ valgrind --leak-check=yes ./a.out ==761== Memcheck, a memory error detector ==761== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==761== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==761== Command: ./a.out ==761== ==761== ==761== HEAP SUMMARY: ==761== in use at exit: 73,848 bytes in 4 blocks ==761== total heap usage: 65 allocs, 61 frees, 81,840 bytes allocated ==761== ==761== LEAK SUMMARY: ==761== definitely lost: 0 bytes in 0 blocks ==761== indirectly lost: 0 bytes in 0 blocks ==761== possibly lost: 0 bytes in 0 blocks ==761== still reachable: 73,848 bytes in 4 blocks ==761== suppressed: 0 bytes in 0 blocks ==761== Reachable blocks (those to which a pointer was found) are not shown. ==761== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==761== ==761== For counts of detected and suppressed errors, rerun with: -v ==761== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
comment:6 by , 6 years ago
Doing the same but with
git checkout -b three-weeks-ago 1be02b3644672ac97842bfa2ad4cb2810696dc75
with clang
$clang -fsanitize=address geos_leak.c -lgeos_c -L/home/vicky/geos/vicky/build/lib -I/home/vicky/geos/vicky/build/include -I /home/vicky/geos/vicky/include $ ./a.out $
using vlagrind
$ gcc geos_leak.c -lgeos_c -L/home/vicky/geos/vicky/build/lib -I/home/vicky/geos/vicky/build/include -I /home/vicky/geos/vicky/include $ valgrind --leak-check=yes ./a.out ==6163== Memcheck, a memory error detector ==6163== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==6163== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==6163== Command: ./a.out ==6163== ==6163== ==6163== HEAP SUMMARY: ==6163== in use at exit: 73,848 bytes in 4 blocks ==6163== total heap usage: 65 allocs, 61 frees, 81,840 bytes allocated ==6163== ==6163== LEAK SUMMARY: ==6163== definitely lost: 0 bytes in 0 blocks ==6163== indirectly lost: 0 bytes in 0 blocks ==6163== possibly lost: 0 bytes in 0 blocks ==6163== still reachable: 73,848 bytes in 4 blocks ==6163== suppressed: 0 bytes in 0 blocks ==6163== Reachable blocks (those to which a pointer was found) are not shown. ==6163== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==6163== ==6163== For counts of detected and suppressed errors, rerun with: -v ==6163== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The output looks the same to me for both commits on the commit history.
Maybe I am doing something wrong, I cant reproduce the problem.
comment:7 by , 6 years ago
mentioned in the issue
geos-git-3.7.0rc1.r21.gbe8b3ffb
I am getting this:
So I am trying to checkout that number as git commit
git checkout -b the-one-mentioned gbe8b3ffb fatal: Cannot update paths and switch to branch 'the-one-mentioned' at the same time. Did you intend to checkout 'gbe8b3ffb' which can not be resolved as commit?
comment:8 by , 6 years ago
So I am trying to checkout that number as git commit
It comes from calling git describe --long --tags in what was at that moment the current master/HEAD:
$ git checkout be8b3ffb4532c5302e004a400bf0069493df7302 Previous HEAD position was 642744e5 Fix typos in getGeometryN() docs. HEAD is now at be8b3ffb Merge branch 'fix-shadow4.8' of cvvergara/geos into master $ git describe --long --tags 3.7.0rc1-21-gbe8b3ffb
To be honest, I'm not sure how gbe8b3ffb relates to the commit.
Here is a step by step guide to reproduce the issue:
- Checkout commit before the one responsible (
^means commit before this one):git checkout e7adbc55a20633064d3af49f2662b17e5ca02e47^
- Build the library (set up flags as needed):
./autogen.sh ./configure make
- Build the test file (I placed it in the same folder as the library (
~/dev/public/geos):clang -fsanitize=address geos_leak.c -lgeos_c -L./capi/.libs -L./src/.libs -Iinclude/geos
- Run forcing the use of the local built library:
LD_LIBRARY_PATH=./capi/.libs:./src/.libs ./a.out (no output)
- Switch to the offending commit:
git checkout e7adbc55a20633064d3af49f2662b17e5ca02e47
- Rebuild the library:
make
- Run the test binary using the newly compiled library (There is no need to recompile it since it was linked dynamically):
LD_LIBRARY_PATH=./capi/.libs:./src/.libs ./a.out ================================================================= ==14385==ERROR: LeakSanitizer: detected memory leaks Indirect leak of 88 byte(s) in 1 object(s) allocated from: #0 0x55d4cca326a1 in __interceptor_malloc (/home/raul/dev/public/geos/a.out+0xe66a1) #1 0x7f9d7c33a5fc in operator new(unsigned long) /build/gcc/src/gcc/libstdc++-v3/libsupc++/new_op.cc:50:40 #2 0x7f9d7c5463a2 in geos::noding::GeometryNoder::extractSegmentStrings(geos::geom::Geometry const&, std::vector<geos::noding::SegmentString*, std::allocator<geos::noding::SegmentString*> >&) /home/raul/dev/public/geos/src/noding/GeometryNoder.cpp:157:12 #3 0x7f9d7c54684b in geos::noding::GeometryNoder::getNoded() /home/raul
You can also avoid clang and instead build the test file normally and use valgrind:
gcc geos_leak.c -lgeos_c -L./capi/.libs -L./src/.libs -Iinclude/geos
Valgrind with the last good commit:
$ LD_LIBRARY_PATH=./capi/.libs:./src/.libs valgrind ./a.out ==24076== Memcheck, a memory error detector ==24076== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==24076== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==24076== Command: ./a.out ==24076== ==24076== ==24076== HEAP SUMMARY: ==24076== in use at exit: 1,152 bytes in 3 blocks ==24076== total heap usage: 65 allocs, 62 frees, 81,848 bytes allocated ==24076== ==24076== LEAK SUMMARY: ==24076== definitely lost: 0 bytes in 0 blocks ==24076== indirectly lost: 0 bytes in 0 blocks ==24076== possibly lost: 0 bytes in 0 blocks ==24076== still reachable: 1,152 bytes in 3 blocks ==24076== suppressed: 0 bytes in 0 blocks ==24076== Rerun with --leak-check=full to see details of leaked memory ==24076== ==24076== For counts of detected and suppressed errors, rerun with: -v ==24076== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Valgrind with the last valid commit:
$ LD_LIBRARY_PATH=./capi/.libs:./src/.libs valgrind --leak-check=full ./a.out ==8512== Memcheck, a memory error detector ==8512== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8512== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==8512== Command: ./a.out ==8512== ==8512== ==8512== HEAP SUMMARY: ==8512== in use at exit: 1,512 bytes in 11 blocks ==8512== total heap usage: 65 allocs, 54 frees, 81,848 bytes allocated ==8512== ==8512== 360 (88 direct, 272 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 11 ==8512== at 0x4837DEF: operator new(unsigned long) (vg_replace_malloc.c:334) ==8512== by 0x4B854E3: geos::noding::(anonymous namespace)::SegmentStringExtractor::filter_ro(geos::geom::Geometry const*) (GeometryNoder.cpp:61) ==8512== by 0x4B853A2: geos::noding::GeometryNoder::extractSegmentStrings(geos::geom::Geometry const&, std::vector<geos::noding::SegmentString*, std::allocator<geos::noding::SegmentString*> >&) (GeometryNoder.cpp:157) ==8512== by 0x4B8584B: geos::noding::GeometryNoder::getNoded() (GeometryNoder.cpp:123) ==8512== by 0x4B85A15: geos::noding::GeometryNoder::node(geos::geom::Geometry const&) (GeometryNoder.cpp:80) ==8512== by 0x4865497: GEOSNode_r (geos_ts_c.cpp:2450) ==8512== by 0x1092F0: main (in /home/raul/dev/public/geos/a.out) ==8512== ==8512== LEAK SUMMARY: ==8512== definitely lost: 88 bytes in 1 blocks ==8512== indirectly lost: 272 bytes in 7 blocks ==8512== possibly lost: 0 bytes in 0 blocks ==8512== still reachable: 1,152 bytes in 3 blocks ==8512== suppressed: 0 bytes in 0 blocks ==8512== Reachable blocks (those to which a pointer was found) are not shown. ==8512== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==8512== ==8512== For counts of detected and suppressed errors, rerun with: -v ==8512== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Hope this is useful. Let me know if you need any help.
comment:10 by , 6 years ago
@strk Can you verify this:
From what I see:
The commits of the tag: https://github.com/libgeos/geos/releases/tag/3.7.0
are listed here: https://github.com/libgeos/geos/commits/673b993976709d2f72c35c4886327d6f2752fe48
As you can see there is no commit (from me) involving the shadows on 3.7.0
I made sure when merging to master that it was done after master was changed to 3.8
On: https://git.osgeo.org/gitea/geos/geos/pulls/44
cvvergara merged 1 commits from cvvergara/geos:fix-shadow into master 2 weeks ago.
The history of commits on master shows that the shadow PR was merged after the commit labeled: "Flip master to 3.8 development" that was done one month ago. https://git.osgeo.org/gitea/geos/geos/commits/branch/master
So, if something is wrong because of the shadows "fixes", then my conclusion is that the milestone for this issue is for 3.8.0-dev not for 3.7.0
@Algunenano Can you please test if the problem happens on that commit on the following commit: 673b993976709d2f72c35c4886327d6f2752fe48 (on the mean time I will try to understand your process)
Version 0, edited 6 years ago by (next)
comment:11 by , 6 years ago
| Milestone: | 3.7.0 → 3.8.0 |
|---|
So, if something is wrong because of the shadows "fixes", then my conclusion is that the milestone for this issue is for 3.8.0-dev not for 3.7.0
Yes, this does not affect 3.7.0. My bad, I'll change the milestone.
@Algunenano Can you please test if the problem happens on the following commit: 673b993976709d2f72c35c4886327d6f2752fe48 (on the mean time I will try to understand your process)
No it doesn't. It only affects master from e7adbc55a20633064d3af49f2662b17e5ca02e47 and after.
comment:12 by , 6 years ago
I am making a valgrind memory leak test on tag 3.7.0, I am including the test file submitted by @algunenano
$ git checkout 3.7.0
M .editorconfig
M CMakeLists.txt
M tests/CMakeLists.txt
A tests/issue923/CMakeLists.txt
A tests/issue923/Makefile.am
A tests/issue923/geos_leak.c
Note: checking out '3.7.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 673b993... Prepare for 3.7.0 release
$ make -j 2 && time ctest -T memcheck
[ 0%] Built target geos_revision
[ 38%] Built target geos
[ 39%] Built target geos_c
[ 41%] Built target test_xmltester
[ 80%] Built target geos-static
[ 80%] Built target test_simplewkttester
[ 80%] Built target test_sweep_line_speed
[ 80%] Built target perf_class_sizes
[ 80%] Built target test_bug234
[ 81%] Built target perf_iterated_buffer
[ 81%] Built target perf_rectangle_intersects
[ 81%] Built target perf_memleak_mp_prep
[ 81%] Built target perf_geos_leak
[100%] Built target test_geos_unit
Site: vicky-desktop
Build name: Linux-c++
Memory check project /home/vicky/geos/vicky/build
Start 1: test_geos_unit
1/9 MemCheck #1: test_geos_unit ................... Passed 27.61 sec
Start 2: test_xmltester
2/9 MemCheck #2: test_xmltester ................... Passed 393.84 sec
Start 3: test_bug234
3/9 MemCheck #3: test_bug234 ...................... Passed 1.55 sec
Start 4: test_sweep_line_speed
4/9 MemCheck #4: test_sweep_line_speed ............ Passed 50.89 sec
Start 5: perf_class_sizes
5/9 MemCheck #5: perf_class_sizes ................. Passed 0.51 sec
Start 6: perf_iterated_buffer
6/9 MemCheck #6: perf_iterated_buffer ............. Passed 720.40 sec
Start 7: perf_rectangle_intersects
7/9 MemCheck #7: perf_rectangle_intersects ........ Passed 20.56 sec
Start 8: perf_memleak_mp_prep
8/9 MemCheck #8: perf_memleak_mp_prep ............. Passed 600.99 sec
Start 9: perf_geos_leak
9/9 MemCheck #9: perf_geos_leak ................... Passed 1.00 sec
100% tests passed, 0 tests failed out of 9
Total Test time (real) = 1817.34 sec
-- Processing memory checking output: ########
Memory checking results:
Memory Leak - 69
Potential Memory Leak - 23
real 30m17.426s
user 30m5.035s
sys 0m3.905s
As you can see version 3.7.0 tests have
Memory Leak - 69 Potential Memory Leak - 23
By doing the valgrind test only on perf_geos_leak, it shows only Potential Memory Leak - 3
make -j 2 && ctest -T memcheck -R perf_geos_leak
[ 0%] Built target geos_revision
[ 38%] Built target geos
[ 77%] Built target geos-static
[ 78%] Built target geos_c
[ 80%] Built target test_xmltester
[ 80%] Built target test_simplewkttester
[ 80%] Built target test_sweep_line_speed
[ 80%] Built target test_bug234
[ 80%] Built target perf_class_sizes
[ 81%] Built target perf_iterated_buffer
[ 81%] Built target perf_rectangle_intersects
[ 81%] Built target perf_memleak_mp_prep
[ 81%] Built target perf_geos_leak
[100%] Built target test_geos_unit
Site: vicky-desktop
Build name: Linux-c++
Create new tag: 20180920-0002 - Experimental
Memory check project /home/vicky/geos/vicky/build
Start 9: perf_geos_leak
1/1 MemCheck #9: perf_geos_leak ................... Passed 1.03 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 1.03 sec
-- Processing memory checking output:
Memory checking results:
Potential Memory Leak - 3
Will do the test on master results will be posted on a next comment
comment:13 by , 6 years ago
on master:
git checkout upstream/master
M .editorconfig
M CMakeLists.txt
M tests/CMakeLists.txt
A tests/issue923/CMakeLists.txt
A tests/issue923/Makefile.am
A tests/issue923/geos_leak.c
HEAD is now at f7867f9... Merge branch 'no-exception-pointers'
$ make -j 2 && time ctest -T memcheck
[ 0%] Built target geos_revision
[ 38%] Built target geos
[ 39%] Built target geos_c
[ 41%] Built target test_xmltester
[ 80%] Built target geos-static
[ 80%] Built target test_simplewkttester
[ 80%] Built target test_sweep_line_speed
[ 80%] Built target test_bug234
[ 80%] Built target perf_class_sizes
[ 81%] Built target perf_iterated_buffer
[ 81%] Built target perf_rectangle_intersects
[ 81%] Built target perf_geos_leak
[ 81%] Built target perf_memleak_mp_prep
[100%] Built target test_geos_unit
Site: vicky-desktop
Build name: Linux-c++
Memory check project /home/vicky/geos/vicky/build
Start 1: test_geos_unit
1/9 MemCheck #1: test_geos_unit ................... Passed 27.28 sec
Start 2: test_xmltester
2/9 MemCheck #2: test_xmltester ................... Passed 415.55 sec
Start 3: test_bug234
3/9 MemCheck #3: test_bug234 ...................... Passed 1.58 sec
Start 4: test_sweep_line_speed
4/9 MemCheck #4: test_sweep_line_speed ............ Passed 56.95 sec
Start 5: perf_class_sizes
5/9 MemCheck #5: perf_class_sizes ................. Passed 0.52 sec
Start 6: perf_iterated_buffer
6/9 MemCheck #6: perf_iterated_buffer ............. Passed 786.23 sec
Start 7: perf_rectangle_intersects
7/9 MemCheck #7: perf_rectangle_intersects ........ Passed 21.77 sec
Start 8: perf_memleak_mp_prep
8/9 MemCheck #8: perf_memleak_mp_prep ............. Passed 706.61 sec
Start 9: perf_geos_leak
9/9 MemCheck #9: perf_geos_leak ................... Passed 1.02 sec
100% tests passed, 0 tests failed out of 9
Total Test time (real) = 2017.52 sec
-- Processing memory checking output: ########
Memory checking results:
Memory Leak - 73
Potential Memory Leak - 24
real 33m37.631s
user 33m16.057s
sys 0m4.542s
in particular:
$ make -j 2 && ctest -T memcheck -R perf_geos_leak
[ 0%] Built target geos_revision
[ 38%] Built target geos
[ 39%] Built target geos_c
[ 41%] Built target test_xmltester
[ 41%] Built target test_simplewkttester
[ 80%] Built target geos-static
[ 80%] Built target test_sweep_line_speed
[ 80%] Built target test_bug234
[ 80%] Built target perf_class_sizes
[ 81%] Built target perf_iterated_buffer
[ 81%] Built target perf_rectangle_intersects
[ 81%] Built target perf_memleak_mp_prep
[ 81%] Built target perf_geos_leak
[100%] Built target test_geos_unit
Site: vicky-desktop
Build name: Linux-c++
Memory check project /home/vicky/geos/vicky/build
Start 9: perf_geos_leak
1/1 MemCheck #9: perf_geos_leak ................... Passed 1.05 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 1.05 sec
-- Processing memory checking output:
Memory checking results:
Memory Leak - 1
Potential Memory Leak - 3
3.7.0
Memory Leak - 69 Potential Memory Leak - 23
3.8.0-dev
Memory Leak - 73 Potential Memory Leak - 24
Now that I have a test that I can run to catch memory leaks with valgrind, I can proceed to test my commits, one by one to see which of the 16 commits that I had to squash added leaks.
comment:14 by , 6 years ago
@algun enano
can you make this tests
Can you try on 3.7.0 and on master:
test 1: add at the end of the script finishGEOS();
test 2: only have in the script initGEOS(test_log, test_error); finishGEOS();
For me without finishGEOS I get
Memory checking results: Potential Memory Leak - 4
and with finishGEOS
Memory checking results: Potential Memory Leak - 3
Note that in valgrind the Potential Memory leak mean: That "Memory was allocated and was not subsequently freed before the program terminated."
comment:15 by , 6 years ago
Adding finishGeos() to the script:
3.7.0:
==5574== Memcheck, a memory error detector ==5574== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==5574== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==5574== Command: ./a.out ==5574== ==5574== ==5574== HEAP SUMMARY: ==5574== in use at exit: 56 bytes in 2 blocks ==5574== total heap usage: 65 allocs, 63 frees, 81,848 bytes allocated ==5574== ==5574== LEAK SUMMARY: ==5574== definitely lost: 0 bytes in 0 blocks ==5574== indirectly lost: 0 bytes in 0 blocks ==5574== possibly lost: 0 bytes in 0 blocks ==5574== still reachable: 56 bytes in 2 blocks ==5574== suppressed: 0 bytes in 0 blocks ==5574== Reachable blocks (those to which a pointer was found) are not shown. ==5574== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==5574== ==5574== For counts of detected and suppressed errors, rerun with: -v ==5574== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Master:
==17645== Memcheck, a memory error detector ==17645== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==17645== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==17645== Command: ./a.out ==17645== ==17645== ==17645== HEAP SUMMARY: ==17645== in use at exit: 416 bytes in 10 blocks ==17645== total heap usage: 65 allocs, 55 frees, 81,848 bytes allocated ==17645== ==17645== 360 (88 direct, 272 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 10 ==17645== at 0x4837DEF: operator new(unsigned long) (vg_replace_malloc.c:334) ==17645== by 0x4B854B3: geos::noding::(anonymous namespace)::SegmentStringExtractor::filter_ro(geos::geom::Geometry const*) (GeometryNoder.cpp:61) ==17645== by 0x4B85372: geos::noding::GeometryNoder::extractSegmentStrings(geos::geom::Geometry const&, std::vector<geos::noding::SegmentString*, std::allocator<geos::noding::SegmentString*> >&) (GeometryNoder.cpp:157) ==17645== by 0x4B8581B: geos::noding::GeometryNoder::getNoded() (GeometryNoder.cpp:123) ==17645== by 0x4B859E5: geos::noding::GeometryNoder::node(geos::geom::Geometry const&) (GeometryNoder.cpp:80) ==17645== by 0x4865497: GEOSNode_r (geos_ts_c.cpp:2450) ==17645== by 0x109300: main (in /home/raul/dev/public/geos/a.out) ==17645== ==17645== LEAK SUMMARY: ==17645== definitely lost: 88 bytes in 1 blocks ==17645== indirectly lost: 272 bytes in 7 blocks ==17645== possibly lost: 0 bytes in 0 blocks ==17645== still reachable: 56 bytes in 2 blocks ==17645== suppressed: 0 bytes in 0 blocks ==17645== Reachable blocks (those to which a pointer was found) are not shown. ==17645== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==17645== ==17645== For counts of detected and suppressed errors, rerun with: -v ==17645== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Only initGeos() and finishGeos() in the script:
3.7.0:
==6083== Memcheck, a memory error detector ==6083== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==6083== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==6083== Command: ./a.out ==6083== ==6083== ==6083== HEAP SUMMARY: ==6083== in use at exit: 56 bytes in 2 blocks ==6083== total heap usage: 10 allocs, 8 frees, 80,096 bytes allocated ==6083== ==6083== LEAK SUMMARY: ==6083== definitely lost: 0 bytes in 0 blocks ==6083== indirectly lost: 0 bytes in 0 blocks ==6083== possibly lost: 0 bytes in 0 blocks ==6083== still reachable: 56 bytes in 2 blocks ==6083== suppressed: 0 bytes in 0 blocks ==6083== Reachable blocks (those to which a pointer was found) are not shown. ==6083== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==6083== ==6083== For counts of detected and suppressed errors, rerun with: -v ==6083== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Master:
==26299== Memcheck, a memory error detector ==26299== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==26299== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==26299== Command: ./a.out ==26299== ==26299== ==26299== HEAP SUMMARY: ==26299== in use at exit: 56 bytes in 2 blocks ==26299== total heap usage: 10 allocs, 8 frees, 80,096 bytes allocated ==26299== ==26299== LEAK SUMMARY: ==26299== definitely lost: 0 bytes in 0 blocks ==26299== indirectly lost: 0 bytes in 0 blocks ==26299== possibly lost: 0 bytes in 0 blocks ==26299== still reachable: 56 bytes in 2 blocks ==26299== suppressed: 0 bytes in 0 blocks ==26299== Reachable blocks (those to which a pointer was found) are not shown. ==26299== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==26299== ==26299== For counts of detected and suppressed errors, rerun with: -v ==26299== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The issue are not the still reachable blocks, they refer to the default geometry factory. The issue are the indirectly lost and definitely lost blocks when using GEOSNode in master.
comment:16 by , 6 years ago
Here is the PR that fixes it: https://github.com/libgeos/geos/pull/124
The change missed renaming lineList in the cleanup.
Note:
See TracTickets
for help on using tickets.
C test case