Memory errors with 2D variable with incorrectly sized first dimension.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Execute python bug_script.py (from within gdb allows the trace to be caught)

*** glibc detected *** /home/jhelmus/bin/epd_free-7.3-2-rh5-x86_64/bin/python: 
free(): invalid next size (fast): 0x0000000000d5aea0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7ffff6dcab96]

What is the expected output? What do you see instead?

[[ 0.  1.]
 [ 2.  3.]
 [ 4.  5.]
 [ 0.  0.]
 [ 0.  0.]
 [ 0.  0.]
 [ 0.  0.]
 [ 0.  0.]
 [ 0.  0.]
 [ 0.  0.]]

Basically I believe the bar value should be zero filled.  

Raising an Error when only a portion of bar is set, bar[:] = np.arange(dim0_bar 
* 2, dtype='float32').reshape(dim0_bar, 2), would also be an expected results.  

What version of the product are you using? On what operating system?

All modules are from EPD Free version 7.3-2-rh5-x86_64
netCDF4 version 1.0.2
Running on a 64 bit Ubuntu 12.04 Linux install.

Please provide any additional information below.

Playing with dim0_foo will cause different errors.  7 seems to give the 
expected results.  Also if the data types match the error seems to go away.   

Original issue reported on code.google.com by jjhelmus@gmail.com on 21 May 2013 at 9:55

Attachments:

• bug_script.py

[GoogleCodeExporter]

It should be added that the file created (buggy.nc) can be read in a Python 
shell with netCDF4.  In fact the 'bar' variable can be extracted and the 
correct values are given.  The memory error only arise when the shell is shut 
down.   So this is probably a problem when the memory is freed (I'm guessing a 
reference counting issue).  I'll dig into this more tomorrow.

Original comment by jjhelmus@gmail.com on 21 May 2013 at 10:21

[GoogleCodeExporter]

The script executes for me with no error and produces

[[0.0 1.0]
 [2.0 3.0]
 [4.0 5.0]
 [-- --]
 [-- --]
 [-- --]
 [-- --]
 [-- --]]

which I believe is correct.

Original comment by whitaker.jeffrey@gmail.com on 21 May 2013 at 10:45

[GoogleCodeExporter]

Updating to a newer version of the netcdf library (was 4.1.1 now 4.3.0) solved 
this problem.  I believe the issue was stemming from the bug described in 
NCF-143, https://bugtracking.unidata.ucar.edu/browse/NCF-143

Original comment by jjhelmus@gmail.com on 22 May 2013 at 3:03

[GoogleCodeExporter]

Original comment by whitaker.jeffrey@gmail.com on 26 Feb 2014 at 2:04

• Changed state: Fixed