Deallocate problem

[db]

In a Fortran program I have these lines

...
print '(" ALLOCATED C:", l4)', ALLOCATED (C)
print '(" ALLOCATED X:", l4)', ALLOCATED (X)
print '(" ALLOCATED Z:", l4)', ALLOCATED (Z)
print '(" ALLOCATED p:", l4)', ALLOCATED (p)
print '(" ALLOCATED r:", l4)', ALLOCATED (r)
DEALLOCATE (C, X, Z, p, r,stat=i)
print '(" DEALLOCATE status =", i4)', i
...

When I run the program, this produces

ALLOCATED C: T
ALLOCATED X: T
ALLOCATED Z: T
ALLOCATED p: T
ALLOCATED r: T
munmap_chunk(): invalid pointer

It is the DEALLOCATE statement where it happens. Any idea why?

[John]

Are some of the values pointers? For example, if p and r are pointers to the same target,
deallocating a pointer target causes the pointer association status of any other pointer that is associated with the target or a portion of the target to become undefined. So once p is deallocated r is indefined. That is just one possibility.

How are the values defined and what declaration do they have?

[Robin Vowels]

.
You could try deallocating each one separately.

[FortranFan]

On Sunday, September 11, 2022 at 9:52:36 AM UTC-4, db wrote:
>..

> DEALLOCATE (C, X, Z, p, r,stat=i)
> print '(" DEALLOCATE status =", i4)', i
> ...
>
> When I run the program, this produces

> ..

> munmap_chunk(): invalid pointer
>
> It is the DEALLOCATE statement where it happens. Any idea why?

@db,

Re: "Any idea why?," you can best answer the question by yourself.

If you have a processor supporting Fortran 2003 or newer version of the standard, you can try introducing the ERRMSG= argument to your DEALLOCATE statement and check the message to see if that helps you figure out the problem.

You can also try to deallocate the objects one by one with the ERRMSG= option and see if that helps.

[Louis Krupp]

Can you post a small, complete program that reproduces the problem?

Louis

[db]

That was the way to the solution. I found that C, X and Z were fine
but it baulked at p. So I looked further and found that although I
had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
values to (p(0,i) and r(0,i), so I overwrote something. When I removed
that, the problem went away. A hard one.

Thank you all.

--
Dieter Britz

[gah4]

On Monday, September 12, 2022 at 6:43:16 AM UTC-7, db wrote:

(snip, someone wrote)

> > You could try deallocating each one separately.

> That was the way to the solution. I found that C, X and Z were fine
> but it baulked at p. So I looked further and found that although I
> had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
> values to (p(0,i) and r(0,i), so I overwrote something. When I removed
> that, the problem went away. A hard one.

The C deallocation funtion, free(), does not need to be told how long the
variable being deallocated is. A popular implementation puts just before
the actual array. Assigning one or two elements before the start of the
array destroys that, or sometimes the address of the next array, and
so free() fails in some bad ways.

Random stores outside the array are less likely to cause this, though that
means easier to miss during debugging.

[Robin Vowels]

.
You hadn't used array bounds checking?

[db]

On 13.09.2022 15.11, Robin Vowels wrote:
[...]

>>> .
>>> You could try deallocating each one separately.
>> That was the way to the solution. I found that C, X and Z were fine
>> but it baulked at p. So I looked further and found that although I
>> had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
>> values to (p(0,i) and r(0,i), so I overwrote something. When I removed
>> that, the problem went away. A hard one.
> .
> You hadn't used array bounds checking?

I thought I did:

gfortran -o expexpsor.out -g -fcheck=bounds \

...


--
Dieter Britz

[Ron Shepard]

It might be worth the effort to understand why the compiler did not
catch that array bounds mistake immediately.

$.02 -Ron Shepard

[gah4]

On Wednesday, September 14, 2022 at 8:42:56 AM UTC-7, Ron Shepard wrote:
> On 9/14/22 5:58 AM, db wrote:

(snip)

> > gfortran -o expexpsor.out -g -fcheck=bounds \

> It might be worth the effort to understand why the compiler did not
> catch that array bounds mistake immediately.

I agree.

There are a number of ways to trick the bounds-check system.

Assumed size arrays can't check the upper bound, but even for them,
I think it still checks the lower bound.

If you do separate compilation, you need bounds check on all.

It seems that it should either find a compiler bug, or some
unusual trick done by the program, that could cause problems.

[Louis Krupp]

That's why it's good to post a small program that reproduces the
problem; it helps everyone else see exactly what you're seeing.

Louis

[Robin Vowels]

On Thursday, September 15, 2022 at 2:17:46 AM UTC+10, gah4 wrote:
> On Wednesday, September 14, 2022 at 8:42:56 AM UTC-7, Ron Shepard wrote:
> > On 9/14/22 5:58 AM, db wrote:
> (snip)
> > > gfortran -o expexpsor.out -g -fcheck=bounds \
> > It might be worth the effort to understand why the compiler did not
> > catch that array bounds mistake immediately.
> I agree.
>
> There are a number of ways to trick the bounds-check system.
>
> Assumed size arrays can't check the upper bound,

.
Silverfrost F95 checks bounds for these arrays.
.

[db]

You are right. But before I found the error I didn't know how to produce
a small program that caused it; and now that I know what did, it seems
pointless. I doubt that it woulkd explain why the bounds check didn't
complain. I use gfortran btw.

--
Dieter Britz

[jfh]

On Thursday, September 15, 2022 at 6:36:47 AM UTC+12, Robin Vowels wrote:
> On Thursday, September 15, 2022 at 2:17:46 AM UTC+10, gah4 wrote: h

> > On Wednesday, September 14, 2022 at 8:42:56 AM UTC-7, Ron Shepard wrote:
> > > On 9/14/22 5:58 AM, db wrote:
> > (snip)
> > > > gfortran -o expexpsor.out -g -fcheck=bounds \
> > > It might be worth the effort to understand why the compiler did not
> > > catch that array bounds mistake immediately.
> > I agree.
> >
> > There are a number of ways to trick the bounds-check system.
> >
> > Assumed size arrays can't check the upper bound,
> .
> Silverfrost F95 checks bounds for these arrays.

Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) . Gfortran, ifort and g95 all accepted ithat. Does Silverfrost still have that bug/feature? Of course I changed my program to use selected_int_kind(1), but
I don't think selected-int-kind(0) should have been disallowed.

[gah4]

On Saturday, September 17, 2022 at 9:05:48 PM UTC-7, jfh wrote:

(snip)

> Someone trying one of my programs with Silverfrost told me years ago
> that it wouldn't compile because i had tried to declare an integer variable

> with the smallest number of bits with selected-int-kind(0). Gfortran,

> ifort and g95 all accepted ithat. Does Silverfrost still have that bug/feature?
> Of course I changed my program to use selected_int_kind(1), but
> I don't think selected-int-kind(0) should have been disallowed.

I suppose I believe that negative ones shouldn't be allowed, but zero
seems like it should work.

[Louis Krupp]

Having an example where bounds checking apparently failed might be
interesting. You never know.

Louis

[Robin Vowels]

On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:

> Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .

You mean, selected_int_kind(0).
.
You wanted an integer variable capable of storing values between -1 and +1 ?
In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
You have to be joking.

[Ron Shepard]

If there were ever a 1-bit integer kind introduced into the language,
then how would it be specified? selected_int_kind(1) would require at
least 5 bits, rounded up to 8-bits on most modern computers. So unless
the selected_int_kind() function is changed somehow (e.g. to specify
directly the minimum number of bits), asking for 0 decimal digits might
be the only way -- you ask for 0-bits and it would get rounded up to 1-bit.

$.02 -Ron Shepard

[Gary Scott]

Careful, bit strings will raise its ugly head again...

[jfh]

I was not joking because selected_int_kind(1) requires all 19 integers n in the range -10 < n < +10 to be available. If there was a compiler allowing 4-bit integers, hence 16 different possible values, then selected_int_kind(0) would be a way to get them. I note that the f2018 standard does not say that r has to be non-negative. And indeed the program below prints 127 with g95 and gfortran, showing that their lowest integer kind has 8 bits. (I don't have access to a computer with ifort this morning to test what it would do.)

[jfh]

Sorry, I forgot to provide the 3-line program:

integer, parameter:: ifew = selected_int_kind(-1)
print *, huge(0_ifew)
end program

[Robin Vowels]

On Monday, September 19, 2022 at 2:24:21 AM UTC+10, Ron Shepard wrote:
> On 9/18/22 4:28 AM, Robin Vowels wrote:
> > On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:
> >
> >> Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .
> > You mean, selected_int_kind(0).
> > .
> > You wanted an integer variable capable of storing values between -1 and +1 ?
> > In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
> > You have to be joking.
.
> If there were ever a 1-bit integer kind introduced into the language,
> then how would it be specified?

.
Well, selected_int_kind(0) won't do it, because the only value that
could be stored is '0'. And maybe -1 if 2 bits are allocated.
.
Might need a BIT type for that.
.

[gah4]

On Sunday, September 18, 2022 at 2:28:11 AM UTC-7, Robin Vowels wrote:

(snip)

> You mean, selected_int_kind(0).

> You wanted an integer variable capable of storing values between -1 and +1 ?
> In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
> You have to be joking.

No. It is supposed to be a kind that can hold at least that many digits.

But okay, a selected_int_kind(1) should hold at least between -9 and +9.

Selected_int_kind(0) could be less, or maybe not.

[jfh]

On Monday, September 19, 2022 at 2:10:00 PM UTC+12, Robin Vowels wrote:
> On Monday, September 19, 2022 at 2:24:21 AM UTC+10, Ron Shepard wrote:

> > On 9/18/22 4:28 AM, Robin Vowels wrote: am

> > > On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:
> > >
> > >> Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .
> > > You mean, selected_int_kind(0).
> > > .
> > > You wanted an integer variable capable of storing values between -1 and +1 ?
> > > In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
> > > You have to be joking.
> .
> > If there were ever a 1-bit integer kind introduced into the language,
> > then how would it be specified?
> .
> Well, selected_int_kind(0) won't do it, because the only value that
> could be stored is '0'. And maybe -1 if 2 bits are allocated.
> .
> Might need a BIT type for that.
> .
> > selected_int_kind(1) would require at
> > least 5 bits, rounded up to 8-bits on most modern compute

s. So unless
> > the selected_int_kind() function is changed somehow (e.g. to specify
> > directly the minimum number of bits), asking for 0 decimal digits might
> > be the only way -- you ask for 0-bits and it would get rounded up to 1-bit.

Robin Vowels seems to assume that selected_int_kind(0) is asking for an integer kind that can only provide integers n such that -1 < n < 1. It is not. It is asking for the integer kind with the least decimal exponent range that includes 0. I have now found that ifort agrees with gfortran and g95 by giving 8-bit integers with huge = 127. If Robin were right then selected_int_kind(1) would give an integer type that allows -10 < n < 10 but not one that allows -100 < n < 100. I was not surprised that all three of those compilers print 127 four times with this program, and they are standard-conforming in that respect because none of those compilers has a 4-bit integer type. My revised 4-line program:

integer, parameter:: ineg = selected_int_kind(-1), i0 = selected_int_kind(0),&
i1 = selected_int_kind(1), i2 = selected_int_kind(2)
print *, huge(0_ineg),huge(0_i0),huge(0_i1),huge(0_i2)
end program

[gah4]

On Sunday, September 18, 2022 at 10:43:36 PM UTC-7, jfh wrote:

(snip)

> I was not surprised that all three of those compilers print 127 four
> times with this program, and they are standard-conforming in that
> respect because none of those compilers has a 4-bit integer type.
> My revised 4-line program:

> integer, parameter:: ineg = selected_int_kind(-1), i0 = selected_int_kind(0),&
> i1 = selected_int_kind(1), i2 = selected_int_kind(2)
> print *, huge(0_ineg),huge(0_i0),huge(0_i1),huge(0_i2)
> end program

And especially that allows, in case anyone implemented it, a 4 bit type
that would not allow for selected_int_kind(1).

It would be nice to have a selector that allowed selecting the base
of the computation. (Not necessarily the base of the selected type.)

There could be machines with types that could not be distinguished
by whole decimal digits.

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:

> On Sunday, September 18, 2022 at 10:43:36 PM UTC-7, jfh wrote:
>
> (snip)
>
>> I was not surprised that all three of those compilers print 127 four
>> times with this program, and they are standard-conforming in that
>> respect because none of those compilers has a 4-bit integer type.
>> My revised 4-line program:
>
>> integer, parameter:: ineg = selected_int_kind(-1), i0 = selected_int_kind(0),&
>> i1 = selected_int_kind(1), i2 = selected_int_kind(2)
>> print *, huge(0_ineg),huge(0_i0),huge(0_i1),huge(0_i2)
>> end program
>
> And especially that allows, in case anyone implemented it, a 4 bit type
> that would not allow for selected_int_kind(1).
>
> It would be nice to have a selector that allowed selecting the base
> of the computation. (Not necessarily the base of the selected type.)

For real types, you can select the radix with the corresponding
argument to SELECTED_REAL_KIND, if the hardware allows for it.
I suppose this is for decimal floats.

> There could be machines with types that could not be distinguished
> by whole decimal digits.

Real or complex arguments to SELECTED_INT_KIND, anybody? A base
of 2i sounds really promising (and Knuth proposed it, so it
must be good :-)

[Robin Vowels]

.
PL/I has had COMPLEX integer (as well as COMPLEX FLOAT)
SINCE 1966.