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?

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?

On Sunday, September 11, 2022 at 11:52:36 PM UTC+10, db wrote:
> 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?
..
You could try deallocating each one separately.

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.

On 9/11/2022 7:52 AM, db wrote:
> 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?

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

Louis

On 11.09.2022 18.44, Robin Vowels wrote:
> On Sunday, September 11, 2022 at 11:52:36 PM UTC+10, db wrote:
>> 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?
> .
> 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.

Thank you all.

--
Dieter Britz

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.

On Monday, September 12, 2022 at 11:43:16 PM UTC+10, db wrote:
> On 11.09.2022 18.44, Robin Vowels wrote:
> > On Sunday, September 11, 2022 at 11:52:36 PM UTC+10, db wrote:
> >> 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?
> > .
> > 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?

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

On 9/14/22 5:58 AM, db wrote:
> 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 \
>
> ...

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

$.02 -Ron Shepard

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.

On 9/14/2022 4:58 AM, db wrote:
> 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 \
>
> ...
>
>

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

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.
..
> 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.

On 14.09.2022 19.22, Louis Krupp wrote:
> On 9/14/2022 4:58 AM, db wrote:
>> 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 \
>>
>> ...
>>
>>
>
> 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
>

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

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.

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.

On 9/17/2022 5:24 AM, db wrote:
> On 14.09.2022 19.22, Louis Krupp wrote:
>> On 9/14/2022 4:58 AM, db wrote:
>>> 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 \
>>>
>>> ...
>>>
>>>
>>
>> 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
>>
>
> 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.
>

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

Louis

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.

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? 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

On 9/18/2022 11:24 AM, 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? 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
>
Careful, bit strings will raise its ugly head again...

On Sunday, September 18, 2022 at 9:28:11 PM UTC+12, 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.

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.)

On Monday, September 19, 2022 at 11:28:31 AM UTC+12, jfh wrote:
> On Sunday, September 18, 2022 at 9:28:11 PM UTC+12, 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.
> 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.)

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

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

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.
..
> 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.

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.

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