Bug #357

Conditional depends on uninitialized value in GMT_read_table

Added by Eduardo about 5 years ago. Updated almost 5 years ago.

Status:ClosedStart date:2013-08-21
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:5.1.0
Affected version:5.x-dev Platform:Linux

Description

I was ploting a lon/lat file in OGR/GMT format with psxy (5.0.1b_r12069) and I've got this error:

psxy (GMT_fix_up_path): Error: Could not reallocate memory [16.01 kb, 2049 items of 8 bytes]

psxy -Vd output is:

psxy (GMT_Report): Processing input table data
psxy (GMT_Report): Projected values in meters: -353702 353702 -4.07685e+06 -3.07571e+06
psxy (GMT_Report): GMTAPI_Init_Import: Passed family = Data Table and geometry = Line
psxy (GMT_Report): Object ID 0 : Registered Data Table File sa_riv_15s.gmt as an Input resource with geometry Line
psxy (GMT_Report): GMTAPI_Init_Import: Added 1 new sources
psxy (GMT_Report): GMT_Init_IO: Returned first Input object ID = 0
psxy (GMT_Report): GMTAPI_Begin_IO: Input resource access is now enabled [container]
psxy (GMT_Report): GMTAPI_Import_Dataset: Passed ID = -1 and mode = 0
psxy (GMT_Report): Reading Data Table from File sa_riv_15s.gmt
psxy (GMT_Report): GMT_End_IO: Input resource access is now disabled
psxy (GMT_fix_up_path): Error: Could not reallocate memory [16.01 kb, 2049 items of 8 bytes]

minmax reports this:

$ minmax sa_riv_15s.gmt
sa_riv_15s.gmt: N = 3810565 ←91.5729166667/-34.8020833333> ←55.6229166667/14.8520833333>

The file is 150 MB, 3810565 data points in 4281512 segments, my machine is a Linux box with 8 MB, so I suspected a memory problem so I ran it on another machine (5.0.1b_r12071M) with more memory. Success!

psxy -Vd output is:

psxy (GMT_Report): Processing input table data
psxy (GMT_Report): Projected values in meters: -353702 353702 -4.07685e+06 -3.07571e+06
psxy (GMT_Report): GMTAPI_Init_Import: Passed family = Data Table and geometry = Line
psxy (GMT_Report): Object ID 0 : Registered Data Table File sa_riv_15s.gmt as an Input resource with geometry Line
psxy (GMT_Report): GMTAPI_Init_Import: Added 1 new sources
psxy (GMT_Report): GMT_Init_IO: Returned first Input object ID = 0
psxy (GMT_Report): GMTAPI_Begin_IO: Input resource access is now enabled [container]
psxy (GMT_Report): GMTAPI_Import_Dataset: Passed ID = -1 and mode = 0
psxy (GMT_Report): Reading Data Table from File sa_riv_15s.gmt
psxy (GMT_Report): GMT_End_IO: Input resource access is now disabled
psxy (GMT_Report): GMT_Garbage_Collection: Destroying object: C=0 A=1 ID=0 W=Input F=Data Table M=File S=Used P=0 D=1b63680 N=sa_riv_15s.gmt
psxy (GMT_Report): GMTAPI_Garbage_Collection freed 1 memory objects
psxy (GMT_Report): GMTAPI_Unregister_IO: Unregistering object no 0

But the other machine is 64 bits, so I was interested to see if the error was memory or something else. Then I ran it on anoter Linux box, 64 bits 2 MB machine (5.0.1b_r12071). After 4 minutes, success!

psxy -Vd output is:

psxy (GMT_Report): Processing input table data
psxy (GMT_Report): Projected values in meters: -353702 353702 -4.07685e+06 -3.07571e+06
psxy (GMT_Report): GMTAPI_Init_Import: Passed family = Data Table and geometry = Line
psxy (GMT_Report): Object ID 0 : Registered Data Table File sa_riv_15s.gmt as an Input resource with geometry Line
psxy (GMT_Report): GMTAPI_Init_Import: Added 1 new sources
psxy (GMT_Report): GMT_Init_IO: Returned first Input object ID = 0
psxy (GMT_Report): GMTAPI_Begin_IO: Input resource access is now enabled [container]
psxy (GMT_Report): GMTAPI_Import_Dataset: Passed ID = -1 and mode = 0
psxy (GMT_Report): Reading Data Table from File sa_riv_15s.gmt
psxy (GMT_Report): GMT_End_IO: Input resource access is now disabled
psxy (GMT_Report): GMT_Garbage_Collection: Destroying object: C=0 A=1 ID=0 W=Input F=Data Table M=File S=Used P=0 D=202cee0 N=sa_riv_15s.gmt
psxy (GMT_Report): GMTAPI_Garbage_Collection freed 1 memory objects
psxy (GMT_Report): GMTAPI_Unregister_IO: Unregistering object no 0

So I ran psxy thru valgrind on my 32 bits machine and got this:

18522 Memcheck, a memory error detector
18522 Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
18522 Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
18522 Command: gmt psxy sa_riv_15s.gmt -R -J -W0.5p,blue,solid -O -K
18522
18522 Invalid read of size 4
18522 at 0x412ED8C: GMT_Parse_Common (gmt_parse.c:548)
18522 by 0x42CBAAA: GMT_psxy (psxy.c:547)
18522 by 0x406A752: GMT_Call_Module (gmt_api.c:5502)
18522 by 0x804890B: main (gmt.c:156)
18522 Address 0xa0584ec is 4 bytes inside a block of size 7 alloc'd
18522 at 0x402B498: malloc (vg_replace_malloc.c:270)
18522 by 0x412ED6F: GMT_Parse_Common (gmt_parse.c:573)
18522 by 0x42CBAAA: GMT_psxy (psxy.c:547)
18522 by 0x406A752: GMT_Call_Module (gmt_api.c:5502)
18522 by 0x804890B: main (gmt.c:156)
18522
18522 Invalid read of size 4
18522 at 0x412EE5C: GMT_Parse_Common (gmt_parse.c:548)
18522 by 0x42CBAAA: GMT_psxy (psxy.c:547)
18522 by 0x406A752: GMT_Call_Module (gmt_api.c:5502)
18522 by 0x804890B: main (gmt.c:156)
18522 Address 0xa0584ec is 4 bytes inside a block of size 7 alloc'd
18522 at 0x402B498: malloc (vg_replace_malloc.c:270)
18522 by 0x412ED6F: GMT_Parse_Common (gmt_parse.c:573)
18522 by 0x42CBAAA: GMT_psxy (psxy.c:547)
18522 by 0x406A752: GMT_Call_Module (gmt_api.c:5502)
18522 by 0x804890B: main (gmt.c:156)
18522
18522 Conditional jump or move depends on uninitialised value(s)
18522 at 0x40BB6BD: GMT_read_table (gmt_io.c:6068)
18522 by 0x40771E3: GMTAPI_Import_Dataset (gmt_api.c:1564)
18522 by 0x407844B: GMTAPI_Import_Data (gmt_api.c:2666)
18522 by 0x4078549: GMT_Get_Data (gmt_api.c:3803)
18522 by 0x407871B: GMT_Read_Data (gmt_api.c:3874)
18522 by 0x42CC9BD: GMT_psxy (psxy.c:1067)
18522 by 0x406A752: GMT_Call_Module (gmt_api.c:5502)
18522 by 0x804890B: main (gmt.c:156)
18522
18522
18522 HEAP SUMMARY:
18522 in use at exit: 8,620 bytes in 6 blocks
18522 total heap usage: 10,851,219 allocs, 10,851,213 frees, 15,833,543,316 bytes allocated
18522
18522 LEAK SUMMARY:
18522 definitely lost: 28 bytes in 1 blocks
18522 indirectly lost: 28 bytes in 1 blocks
18522 possibly lost: 0 bytes in 0 blocks
18522 still reachable: 8,564 bytes in 4 blocks
18522 suppressed: 0 bytes in 0 blocks
18522 Rerun with --leak-check=full to see details of leaked memory
18522
18522 For counts of detected and suppressed errors, rerun with: -v
18522 Use --track-origins=yes to see where uninitialised values come from
18522 ERROR SUMMARY: 1403623 errors from 3 contexts (suppressed: 0 from 0)

In a strange way, when ran the command thru valgrind it did not trigger any error, and I did the same run on 64 bits:

8438 Memcheck, a memory error detector
8438 Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
8438 Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
8438 Command: gmt psxy sa_riv_15s.gmt -R -J -W0.5p,blue,solid -O -K
8438
8438 Invalid read of size 4
8438 at 0x4F27D5A: GMT_Parse_Common (gmt_parse.c:548)
8438 by 0x5082AB7: GMT_psxy (psxy.c:547)
8438 by 0x4E859CF: GMT_Call_Module (gmt_api.c:5502)
8438 by 0x400D41: main (gmt.c:156)
8438 Address 0x1540a1c4 is 4 bytes inside a block of size 7 alloc'd
8438 at 0x4C2BE2B: malloc (vg_replace_malloc.c:270)
8438 by 0x4F27D3E: GMT_Parse_Common (gmt_parse.c:573)
8438 by 0x5082AB7: GMT_psxy (psxy.c:547)
8438 by 0x4E859CF: GMT_Call_Module (gmt_api.c:5502)
8438 by 0x400D41: main (gmt.c:156)
8438
8438 Invalid read of size 4
8438 at 0x4F27E1B: GMT_Parse_Common (gmt_parse.c:548)
8438 by 0x5082AB7: GMT_psxy (psxy.c:547)
8438 by 0x4E859CF: GMT_Call_Module (gmt_api.c:5502)
8438 by 0x400D41: main (gmt.c:156)
8438 Address 0x1540a1c4 is 4 bytes inside a block of size 7 alloc'd
8438 at 0x4C2BE2B: malloc (vg_replace_malloc.c:270)
8438 by 0x4F27D3E: GMT_Parse_Common (gmt_parse.c:573)
8438 by 0x5082AB7: GMT_psxy (psxy.c:547)
8438 by 0x4E859CF: GMT_Call_Module (gmt_api.c:5502)
8438 by 0x400D41: main (gmt.c:156)
8438
8438 Conditional jump or move depends on uninitialised value(s)
8438 at 0x4EC6F70: GMT_read_table (gmt_io.c:6068)
8438 by 0x4E8F001: GMTAPI_Import_Dataset (gmt_api.c:1564)
8438 by 0x4E8FC3C: GMTAPI_Import_Data (gmt_api.c:2666)
8438 by 0x4E8FCF9: GMT_Get_Data (gmt_api.c:3803)
8438 by 0x4E8FEA2: GMT_Read_Data (gmt_api.c:3874)
8438 by 0x5084A4D: GMT_psxy (psxy.c:1067)
8438 by 0x4E859CF: GMT_Call_Module (gmt_api.c:5502)
8438 by 0x400D41: main (gmt.c:156)
8438
8438
8438 HEAP SUMMARY:
8438 in use at exit: 17,080 bytes in 6 blocks
8438 total heap usage: 10,849,817 allocs, 10,849,811 frees, 15,870,254,498 bytes allocated
8438
8438 LEAK SUMMARY:
8438 definitely lost: 48 bytes in 1 blocks
8438 indirectly lost: 48 bytes in 1 blocks
8438 possibly lost: 0 bytes in 0 blocks
8438 still reachable: 16,984 bytes in 4 blocks
8438 suppressed: 0 bytes in 0 blocks
8438 Rerun with --leak-check=full to see details of leaked memory
8438
8438 For counts of detected and suppressed errors, rerun with: -v
8438 Use --track-origins=yes to see where uninitialised values come from
8438 ERROR SUMMARY: 1403623 errors from 3 contexts (suppressed: 2 from 2)

History

#1 Updated by Florian about 5 years ago

Hi, I removed the unnecessary strdup in gmt_parse.c:573 (r12073) but I cannot find the uninitialised value in the conditional (gmt_io.c:6068). Could you add these to your ConfigUser.cmake
set(CMAKE_C_FLAGS "-fstrict-aliasing -Wall -Wextra ${CMAKE_C_FLAGS}")
set(CMAKE_C_FLAGS_DEBUG "-g3 -O0")
set(CMAKE_C_FLAGS_RELEASE "-Wuninitialized -Wstrict-aliasing ${CMAKE_C_FLAGS_RELEASE}")
and then do two builds:
  1. release build with set(CMAKE_BUILD_TYPE relwithdebinfo)
  2. debug build with set(CMAKE_BUILD_TYPE Debug)
    Check carefully for compiler warnings that indicate uninitialized values and repeat the valgrind test for each build. Also could you attach a minimal example table file, e.g., a subset of sa_riv_15s.gmt for us to reproduce?

#2 Updated by Eduardo about 5 years ago

You can get the file:

1.- Download http://earlywarning.usgs.gov/hydrodata/sa_shapefiles_zip/sa_riv_15s.zip
2.- unzip sa_riv_15s.zip
3.- ogr2ogr -f GMT sa_riv_15s.gmt sa_riv_15s.shp

#3 Updated by Eduardo about 5 years ago

Hi Florian,

I've tryed with the flags you suggested and I didn't get any uninitialized variable.

Also, I compiled GMT-5 with the last gcc (4.8.1, vanilla). Same error.

Last I've used 75%, 50% and 25% data points and psxy worked only with 25% data points, roughly 970000 points.

#4 Updated by Eduardo about 5 years ago

Hi Florian,

compiled with -g3 and -ggdb3 I got this:

30986 Memcheck, a memory error detector
30986 Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
30986 Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
30986 Command: gmt psxy prueba3.gmt -R -J -W0.5p,blue,solid -O -K
30986
30986 Conditional jump or move depends on uninitialised value(s)
30986 at 0x40BDC9B: GMT_read_table (gmt_io.c:6068)
30986 by 0x406A698: GMTAPI_Import_Dataset (gmt_api.c:1549)
30986 by 0x4070DF5: GMTAPI_Import_Data (gmt_api.c:2666)
30986 by 0x4074115: GMT_Get_Data (gmt_api.c:3803)
30986 by 0x407451D: GMT_Read_Data (gmt_api.c:3874)
30986 by 0x432C098: GMT_psxy (psxy.c:1067)
30986 by 0x407A318: GMT_Call_Module (gmt_api.c:5502)
30986 by 0x80490BF: main (gmt.c:156)
30986 Uninitialised value was created by a heap allocation
30986 at 0x402B6BE: realloc (vg_replace_malloc.c:662)
30986 by 0x4110688: GMT_memory_func (gmt_support.c:3610)
30986 by 0x40BCB6A: GMT_alloc_segment (gmt_io.c:5852)
30986 by 0x40BDF4E: GMT_read_table (gmt_io.c:6079)
30986 by 0x406A698: GMTAPI_Import_Dataset (gmt_api.c:1549)
30986 by 0x4070DF5: GMTAPI_Import_Data (gmt_api.c:2666)
30986 by 0x4074115: GMT_Get_Data (gmt_api.c:3803)
30986 by 0x407451D: GMT_Read_Data (gmt_api.c:3874)
30986 by 0x432C098: GMT_psxy (psxy.c:1067)
30986 by 0x407A318: GMT_Call_Module (gmt_api.c:5502)
30986 by 0x80490BF: main (gmt.c:156)
30986
30986
30986 HEAP SUMMARY:
30986 in use at exit: 8,620 bytes in 6 blocks
30986 total heap usage: 1,853,276 allocs, 1,853,270 frees, 3,831,332,166 bytes allocated
30986
30986 LEAK SUMMARY:
30986 definitely lost: 28 bytes in 1 blocks
30986 indirectly lost: 28 bytes in 1 blocks
30986 possibly lost: 0 bytes in 0 blocks
30986 still reachable: 8,564 bytes in 4 blocks
30986 suppressed: 0 bytes in 0 blocks
30986 Rerun with --leak-check=full to see details of leaked memory
30986
30986 For counts of detected and suppressed errors, rerun with: -v
30986 ERROR SUMMARY: 372946 errors from 1 contexts (suppressed: 0 from 0)

#5 Updated by Florian about 5 years ago

So the compiler does not warn about possible uninitialized values. But valgrind shows us that in gmt_io.c:6068

6068         if (!greenwich && T->segment[seg]->coord[GMT_X][row] < 0.0)  T->segment[seg]->coord[GMT     _X][row] += 360.0;
a value is not initialized and that this value was created on the heap by GMT_alloc_segment()
6079         GMT_alloc_segment (GMT, T->segment[seg], T->segment[seg]->n_alloc, T->segment[seg]->n_columns, false);
If the allocated memory was not initialized this is a bug. I can reproduce this with
head -n 50 sa_riv_15s.gmt  > sa_riv_15s.sub
valgrind --track-origins=yes gmt psxy sa_riv_15s.sub -R-92/-34/-56/15 -JM10c>/dev/null

==7245== Memcheck, a memory error detector
==7245== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==7245== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==7245== Command: gmt psxy sa_riv_15s.sub -R-92/-34/-56/15 -JM10c
==7245== 
==7245== Conditional jump or move depends on uninitialised value(s)
==7245==    at 0x4EB379D: GMT_read_table (gmt_io.c:6068)
==7245==    by 0x4E7CF06: GMTAPI_Import_Dataset (gmt_api.c:1564)
==7245==    by 0x4E7DBA4: GMTAPI_Import_Data (gmt_api.c:2666)
==7245==    by 0x4E7DC7E: GMT_Get_Data (gmt_api.c:3803)
==7245==    by 0x4E7DE4A: GMT_Read_Data (gmt_api.c:3874)
==7245==    by 0x509241B: GMT_psxy (psxy.c:1067)
==7245==    by 0x4E721E7: GMT_Call_Module (gmt_api.c:5502)
==7245==    by 0x400CCA: main (gmt.c:156)
==7245==  Uninitialised value was created by a heap allocation
==7245==    at 0x4C2220D: realloc (vg_replace_malloc.c:476)
==7245==    by 0x4EFECD0: GMT_memory_func (gmt_support.c:3610)
==7245==    by 0x4EA3CED: GMT_alloc_segment (gmt_io.c:5852)
==7245==    by 0x4EB37D1: GMT_read_table (gmt_io.c:6079)
==7245==    by 0x4E7CF06: GMTAPI_Import_Dataset (gmt_api.c:1564)
==7245==    by 0x4E7DBA4: GMTAPI_Import_Data (gmt_api.c:2666)
==7245==    by 0x4E7DC7E: GMT_Get_Data (gmt_api.c:3803)
==7245==    by 0x4E7DE4A: GMT_Read_Data (gmt_api.c:3874)
==7245==    by 0x509241B: GMT_psxy (psxy.c:1067)
==7245==    by 0x4E721E7: GMT_Call_Module (gmt_api.c:5502)
==7245==    by 0x400CCA: main (gmt.c:156)
==7245== 
==7245== 
==7245== HEAP SUMMARY:
==7245==     in use at exit: 17,080 bytes in 6 blocks
==7245==   total heap usage: 1,873 allocs, 1,867 frees, 3,186,492 bytes allocated
==7245== 
==7245== LEAK SUMMARY:
==7245==    definitely lost: 48 bytes in 1 blocks
==7245==    indirectly lost: 48 bytes in 1 blocks
==7245==      possibly lost: 0 bytes in 0 blocks
==7245==    still reachable: 16,984 bytes in 4 blocks
==7245==         suppressed: 0 bytes in 0 blocks
==7245== Rerun with --leak-check=full to see details of leaked memory
==7245== 
==7245== For counts of detected and suppressed errors, rerun with: -v
==7245== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 4 from 4)
but unfortunately I was not able to debug with vgdb because my gdb is too old. Maybe you can try this (http://tromey.com/blog/?p=731).

#6 Updated by Eduardo about 5 years ago

The problem es in GMT_memory_func (gmt_support.c)inthe line which says

tmp = realloc ( prev_addr, nelem * size);

I can imagine that prev_addr is the problem.

#7 Updated by Paul about 5 years ago

  • Status changed from New to Feedback

I will look at this on the weekend, but I think it is because that 360 test happens before the value from the in[] array has been assigned to the coord[] array. It is the same problem in GMT4. However, I don't yet see why this would cause any memory problem per se.

#8 Updated by Florian about 5 years ago

  • Subject changed from psxy 32 bit memory error to Conditional depends on uninitialized value in GMT_read_table

I don't yet see why this would cause any memory problem per se.

There are two problems. One is that the memory is exhausted on Eduardo's machine because the table file is huge (this is not the bug). By chance this revealed the actual bug which ofc does not cause a memory violation. Nevertheless it has to be fixed because comparing a double value to some junk could cause troubles.

#9 Updated by Paul about 5 years ago

  • Status changed from Feedback to In Progress

Yes, we agree Florian. I have fixed the bug causing the uninitiated value and this exposed a few other problems that I need to work on before I can commit. Specifically, correcting the problem causes intersect.sh, hexagone.sh, and sample.sh to fail, probably not noticed because the dateline/greenwich check failed due to the above bug. So I don't want to commit until I have had a look at those cases, but have an appointment at 10 am so this will be later today.

#10 Updated by Paul about 5 years ago

  • Status changed from In Progress to Resolved

I have implemented a fix that seems to work; please report any troubles to this issue. In r12074 (r10080 for GMT 4).

#11 Updated by Florian about 5 years ago

Seems to work but we still leak memory:

valgrind --leak-check=full src/gmt psxy sa_riv_15s.sub -R-92/-34/-56/15 -JM10c >/dev/null

==47456== Memcheck, a memory error detector
==47456== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==47456== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==47456== Command: src/gmt psxy sa_riv_15s.sub -R-92/-34/-56/15 -JM10c
==47456== 
==47456== 
==47456== HEAP SUMMARY:
==47456==     in use at exit: 352,581 bytes in 625 blocks
==47456==   total heap usage: 2,541 allocs, 1,916 frees, 3,525,936 bytes allocated
==47456== 
==47456== 96 (48 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 336 of 432
==47456==    at 0xD4EB: calloc (vg_replace_malloc.c:597)
==47456==    by 0xE61E3: GMT_memtrack_init (gmt_support.c:191)
==47456==    by 0x167604: New_GMT_Ctrl (gmt_init.c:9682)
==47456==    by 0x167C84: GMT_begin (gmt_init.c:9817)
==47456==    by 0x2E639: GMT_Create_Session (gmt_api.c:3122)
==47456==    by 0x10000323C: main (gmt.c:51)
==47456== 
==47456== LEAK SUMMARY:
==47456==    definitely lost: 48 bytes in 1 blocks
==47456==    indirectly lost: 48 bytes in 1 blocks
==47456==      possibly lost: 0 bytes in 0 blocks
==47456==    still reachable: 352,397 bytes in 622 blocks
==47456==         suppressed: 88 bytes in 1 blocks
==47456== Reachable blocks (those to which a pointer was found) are not shown.
==47456== To see them, rerun with: --leak-check=full --show-reachable=yes
==47456== 
==47456== For counts of detected and suppressed errors, rerun with: -v
==47456== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

#12 Updated by Eduardo about 5 years ago

still broken... (5.0.1b_r12074)

psxy (GMT_fix_up_path): Error: Could not reallocate memory [16.01 kb, 2049 items of 8 bytes]

#13 Updated by Eduardo about 5 years ago

this is the otput of

valgrind --track-origins=yes --leak-check=full --show-reachable=yes

22051 Memcheck, a memory error detector
22051 Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
22051 Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
22051 Command: gmt psxy sa_riv_15s.gmt -R -J -W0.5p,blue,solid -O -K
22051
22051
22051 HEAP SUMMARY:
22051 in use at exit: 8,620 bytes in 6 blocks
22051 total heap usage: 10,851,218 allocs, 10,851,212 frees, 15,833,543,337 bytes allocated
22051
22051 20 bytes in 1 blocks are still reachable in loss record 1 of 6
22051 at 0x402937B: calloc (vg_replace_malloc.c:593)
22051 by 0x5265495: _dlerror_run (dlerror.c:141)
22051
22051 28 bytes in 1 blocks are indirectly lost in loss record 2 of 6
22051 at 0x402937B: calloc (vg_replace_malloc.c:593)
22051 by 0x4101A7B: GMT_memtrack_init (gmt_support.c:188)
22051 by 0x4168CE6: New_GMT_Ctrl (gmt_init.c:9682)
22051 by 0x41691D6: GMT_begin (gmt_init.c:9817)
22051 by 0x4072382: GMT_Create_Session (gmt_api.c:3122)
22051 by 0x8048A08: main (gmt.c:51)
22051
22051 56 (28 direct, 28 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 6
22051 at 0x402937B: calloc (vg_replace_malloc.c:593)
22051 by 0x4101AB5: GMT_memtrack_init (gmt_support.c:191)
22051 by 0x4168CE6: New_GMT_Ctrl (gmt_init.c:9682)
22051 by 0x41691D6: GMT_begin (gmt_init.c:9817)
22051 by 0x4072382: GMT_Create_Session (gmt_api.c:3122)
22051 by 0x8048A08: main (gmt.c:51)
22051
22051 352 bytes in 1 blocks are still reachable in loss record 4 of 6
22051 at 0x402B498: malloc (vg_replace_malloc.c:270)
22051 by 0x52FB01B: __fopen_internal (iofopen.c:73)
22051 by 0x4142695: GMT_verify_sharedir_version (common_runpath.c:373)
22051 by 0x415AF6C: GMT_set_env (gmt_init.c:6302)
22051 by 0x4168D79: New_GMT_Ctrl (gmt_init.c:9698)
22051 by 0x41691D6: GMT_begin (gmt_init.c:9817)
22051 by 0x4072382: GMT_Create_Session (gmt_api.c:3122)
22051 by 0x8048A08: main (gmt.c:51)
22051
22051 4,096 bytes in 1 blocks are still reachable in loss record 5 of 6
22051 at 0x402B498: malloc (vg_replace_malloc.c:270)
22051 by 0x44341AB: nc_local_initialize (dfile.c:73)
22051 by 0x4434BEC: NC_open (dfile.c:1578)
22051 by 0x4434FFA: nc_open (dfile.c:572)
22051 by 0x40A88D0: GMT_fopen (gmt_io.c:573)
22051 by 0x40BD31C: GMT_read_table (gmt_io.c:5946)
22051 by 0x406A6F5: GMTAPI_Import_Dataset (gmt_api.c:1550)
22051 by 0x4070E64: GMTAPI_Import_Data (gmt_api.c:2667)
22051 by 0x4074184: GMT_Get_Data (gmt_api.c:3804)
22051 by 0x407458C: GMT_Read_Data (gmt_api.c:3875)
22051 by 0x432C144: GMT_psxy (psxy.c:1067)
22051 by 0x407A387: GMT_Call_Module (gmt_api.c:5503)
22051
22051 4,096 bytes in 1 blocks are still reachable in loss record 6 of 6
22051 at 0x402B498: malloc (vg_replace_malloc.c:270)
22051 by 0x44341C5: nc_local_initialize (dfile.c:75)
22051 by 0x4434BEC: NC_open (dfile.c:1578)
22051 by 0x4434FFA: nc_open (dfile.c:572)
22051 by 0x40A88D0: GMT_fopen (gmt_io.c:573)
22051 by 0x40BD31C: GMT_read_table (gmt_io.c:5946)
22051 by 0x406A6F5: GMTAPI_Import_Dataset (gmt_api.c:1550)
22051 by 0x4070E64: GMTAPI_Import_Data (gmt_api.c:2667)
22051 by 0x4074184: GMT_Get_Data (gmt_api.c:3804)
22051 by 0x407458C: GMT_Read_Data (gmt_api.c:3875)
22051 by 0x432C144: GMT_psxy (psxy.c:1067)
22051 by 0x407A387: GMT_Call_Module (gmt_api.c:5503)
22051
22051 LEAK SUMMARY:
22051 definitely lost: 28 bytes in 1 blocks
22051 indirectly lost: 28 bytes in 1 blocks
22051 possibly lost: 0 bytes in 0 blocks
22051 still reachable: 8,564 bytes in 4 blocks
22051 suppressed: 0 bytes in 0 blocks
22051
22051 For counts of detected and suppressed errors, rerun with: -v
22051 ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

#14 Updated by Florian about 5 years ago

psxy (GMT_fix_up_path): Error: Could not reallocate memory [16.01 kb, 2049 items of 8 bytes]

It would be helpful to run this with a debug build. Then we get the line numbers of the failure. You should also run the command in gdb and set a break point in gmt_support.c:3568. Then you can investigate your memory situation in another terminal with

ps -o rss= -g <PID>
free
We don't learn anything new from the valgrind output.

#15 Updated by Eduardo about 5 years ago

this is useful?

psxy (gmt_vector.c:1125): Error: Could not reallocate memory [16.01 kb, 2049 items of 8 bytes]
psxy (gmt_vector.c:1125): GMT_memory [realloc] called

OK, I've used gdb and the crash is in gmt_support.c (GMT_memory_func) line 3610:

3609 else
3610 tmp = realloc ( prev_addr, nelem * size);
3611 if (tmp == NULL)
3612 die_if_memfail (GMT, nelem, size, where);

#16 Updated by Paul about 5 years ago

I notice that GMT_memtrack_init is listed in the valgrid report from Florian. It points to line 191 which is the allocation of the list_head. However, that is freed in GMT_memtrack_report so not sure why this is listed. Try to recompile without defining MEMDEBUG. Is there still a leak?

#17 Updated by Florian about 5 years ago

OK, I've used gdb and the crash is in gmt_support.c (GMT_memory_func) line 3610:

3609 else
3610 tmp = realloc ( prev_addr, nelem * size);
3611 if (tmp == NULL)
3612 die_if_memfail (GMT, nelem, size, where);

This is not exactly a crash. Your system cannot allocate enough memory and gmt exits gracefully in die_if_memfail(). This is why I suggested to set a breakpoint in die_if_memfail(), e.g., gmt_support.c:3568. If you do so, you can figure out the reason of the memory exhaustion with ps and free. When I run psxy with sa_riv_15s.gmt the process chews up about 4G of memory. When you don't have enough swap and free shows you that all memory is occupied you are out of luck.

#18 Updated by Florian about 5 years ago

I notice that GMT_memtrack_init is listed in the valgrid report from Florian. It points to line #191 which is the allocation of the list_head. However, that is freed in GMT_memtrack_report so not sure why this is listed. Try to recompile without defining MEMDEBUG. Is there still a leak?

Btw, -DMEMDEBUG is still hardcoded in gmt_dev.h. Anyway, the leak of 28 bytes is not the problem.

#19 Updated by Florian about 5 years ago

When I run psxy with sa_riv_15s.gmt the process chews up about 4G of memory. When you don't have enough swap and free shows you that all memory is occupied you are out of luck.

And ofc with your 32-bit system you are stuck with a 4G per-process memory limit.

#20 Updated by Eduardo about 5 years ago

Florian wrote:

When I run psxy with sa_riv_15s.gmt the process chews up about 4G of memory. When you don't have enough swap and free shows you that all memory is occupied you are out of luck.

And ofc with your 32-bit system you are stuck with a 4G per-process memory limit.

OK, I can understand that. But why when I run it in a 64 bit machine with 2 GB psxy runs OK? She is swapping?

And why if I compile GMT-5 with -fsanitize=address or if I run psxy under valgrind it runs OK in my 32bit machine

To me this is a clue that there is a subtle bug that triggers only with some compilation parameters or runing modes.

To take away all my doubts, I just ran the psxy on the 64-bit and 2GB machine. In another terminal I ran "watch free" to see how much swap was used. The amount of swap came only up to ~ 650 MB.

#21 Updated by Eduardo about 5 years ago

when

Breakpoint 1, die_if_memfail (GMT=0xb1eb3008, nelem=2049, size=8,
where=0xb766ceb4 "/root/software/gmt/GMTdev/gmt5/trunk/src/gmt_vector.c:1125") at /root/software/gmt/GMTdev/gmt5/trunk/src/gmt_support.c:3568
3568 GMT_exit (GMT→parent→do_not_exit, EXIT_FAILURE);

free
total used free shared buffers cached
Mem: 8243424 7978920 264504 0 237084 5755804
-/+ buffers/cache: 1986032 6257392
Swap: 16464892 5444 16459448

ps o vsize,rss,size,comm -C gmt
VSZ RSS SIZE COMMAND
3143952 982352 3054940 gmt

#22 Updated by Florian about 5 years ago

free
total used free shared buffers cached
Mem: 8243424 7978920 264504 0 237084 5755804

So you are running a PAE enabled kernel which probably means any process is limited to about 3GB (1GB is reserved for the kernel). You can experiment with example program B from http://www.linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html to find out the exact limit on your machine.

ps o vsize,rss,size,comm -C gmt
VSZ RSS SIZE COMMAND
3143952 982352 3054940 gmt

At this moment gmt already allocated 3GB and cannot claim more.

#23 Updated by Florian about 5 years ago

And why if I compile GMT-5 with -fsanitize=address or if I run psxy under valgrind it runs OK in my 32bit machine

To take away all my doubts, I just ran the psxy on the 64-bit and 2GB machine. In another terminal I ran "watch free" to see how much swap was used. The amount of swap came only up to ~ 650 MB.

Strange. I do not know whether valgrind has ways to overcome the 3/4GB limit. Are you sure that valgrind succeeds on your 32 bit machine? The discrepancy in swap usage or vsize and size of allocated memory might come from allocated but uninitialized memory. I do not know if by accident gmt allocates much more memory than it fills with data.

#24 Updated by Eduardo about 5 years ago

So you are running a PAE enabled kernel which probably means any process is limited to about 3GB (1GB is reserved for the kernel). You can experiment with example program B from http://www.linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html to find out the exact limit on your machine.

yes, it's a PAE kernel.

The second program gives 3055 MB.

I have one question, how to plot a file of 150 MB psxy needs 4GB?

#25 Updated by Florian about 5 years ago

I have one question, how to plot a file of 150 MB psxy needs 4GB?

That is an excellent question indeed

#26 Updated by Eduardo about 5 years ago

Solved for me in 5.0.1b_r1209, I'm doing more tests with big files.

Thanks!

#27 Updated by Paul about 5 years ago

Please update to r12096 which uses a new memory allocation model that should work better as it avoids lots of reallocs. Let me know how it works on your systems.

#28 Updated by Eduardo about 5 years ago

file size 176 M, 4900035 lines, 165601 segments, 4568827 points

with 5.0.1b_r12095 top reported VIRT: 272m RES: 195m

10 psxy in:

real 7m20.428s
user 6m42.673s
sys 0m10.657s

with 5.0.1b_r12097 top reported VIRT: 274m RES: 165m

10 psxy in:

real 7m8.042s
user 6m28.712s
sys 0m8.397s

#29 Updated by Paul almost 5 years ago

Eduardo, what is the status on your end for this one. Did our changes help? Can I close the case? What issues remains, if any?

#30 Updated by Eduardo almost 5 years ago

Excuse me, it works like a charm in my 32 bit box!

Thank you!

#31 Updated by Paul almost 5 years ago

  • Status changed from Resolved to Closed

Great, closing this issue.

Also available in: Atom PDF