possible bug in nfmpi_enddef?

[Jim Edwards]

This appears to be fixed in the latest parallel-netcdf svn - I built against
svn version 821 and ran to completion.
(although an inline operator has been introduced again that needs to be
removed for AIX)

On Fri, May 21, 2010 at 2:31 PM, Jim Edwards <edwards.jim at gmail.com> wrote:

> Hi Rob,
>
> It's pnetcdf-1.1.1  Art is seeing it on jaguar and I am reproducing it on
> bluefire.
>
>
> On Fri, May 21, 2010 at 2:25 PM, Rob Latham <robl at mcs.anl.gov> wrote:
>
>> On Fri, May 21, 2010 at 01:23:02PM -0600, Jim Edwards wrote:
>> > I am trying to do
>> >
>> > rocde = nfmpi_redef(file)
>> > rcode = nfmpi_put_att(cpl_io_file,pio_global,"file_version",version)
>> > rcode = nfmpi_enddef(cpl_io_file)
>>
>> > But this results in
>> >
>> >  Memory allocation (malloc) failure
>>
>> placing a single attribute on the dataset *might* result in growing
>> the header.  You'd know it if you ever hit that: performance would go
>> straight down the toilet.   If the header grows enough that you have
>> to shuffle all the other variables down, pnetcdf will do so at 4k (!)
>> at a time.
>>
>> So, that's one place that allocates memory in the redef case, but
>> there really aren't 4k bytes of memory to spare?  Seems unlikely.
>>
>> Do you maybe have a core file or a backtrace of where this happens?
>>
>> Is this on bluefire or bgp or something else?
>>
>> ==rob
>>
>> --
>> Rob Latham
>> Mathematics and Computer Science Division
>> Argonne National Lab, IL USA
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20100521/ad331732/attachment.htm>