It has been mentioned here and in private e-mail messages repeatedly,
but the following exchange makes me think that it might be a good
idea to state it again.

Please inform us of any problem that you find. Just because you find
a problem doesn't mean that we will find it too (and how can we fix
problems that we don't now). Just because you find a workaround
doesn't mean that others will too.

Most helpful are reports that allows us easily to repeat the problem (the
report below was very good). If you think that this problem might happen
to other users too, please report the problem to 'GAP-Forum'.
Installation problems and other problems that you think are not
appropriate for the GAP forum should be reported to 'GAP-Trouble'.

Thank you in advance.

Martin.

Here is the exchange

Dietmar Koenig wrote in his e-mail message of 1994/08/24

A very curious problem occurs when running the following program in `gap':

[program deleted]

This program computes a presentation record for a finitely presented group
depending on two distinct odd primes p,q.
The occuring error looks like this:

gap> nprec(3,5);
Bus error (core dumped)
pell:nquot-44>

The same error occurs on any other machine available.
It occurs when trying to execute the line

r := PresentationFpGroup(FreeGroup(Length(gen))/[]);
(rem.: Length(gen) at that stage is 80)

and neither occurs with different primes (at least I did not find anymore)
nor when preceeded by a successful run of a previous version of the same
program nor if the command is divided into two parts.

I do not necessarily need an answer to this problem since there is the
easy solution of splitting the line, but people here asked me to report
the error.

Regards, Dietmar.

I answered in my e-mail message of 1994/08/24

You have indeed found a genuine bug in the GAP kernel. It is very
difficult to hit this problem, which is why it only happens for those two
numbers and no others. Also note that it has been in the kernel since
GAP 3.1, and it appears that you are the first to stumble over it.

The problem is indeed in the function call

PresentationFpGroup( FreeGroup(Length(gens))/[] );

When this is evaluated the following things happen

1) First 'PresentationFpGroup' is evaluated, which causes reading of the
file "fptietze.g".

2) 'EvFunCall' remembers the definition of this function in a local
variable 'hdDef'.

3) The argument is evaluated, causing evaluation of 'FreeGroup', which
in turn causes reading of the file "fpgroup.g", which causes
"fptietze.g" to be read again (this probably shouldn't happen in the
first place).

4) This second reading of "fptietze.g" causes a redefinition of
'PresentationFpGroup', so that the old definition is now obsolete
(of course both definitions are equal).

5) Creating the free group causes a garbage collection, which
deallocates the old definition of 'PresentationFpGroup'.

6) So 'hdDef' now points to a deallocated function bag, and from then on
things get progressively worse.

If you call 'nprec' with different arguments, the problem does not
appear, probably because no garbage collection happens between steps 4)
and 6).

If you split the statement into two statements, the problem does not
appear, because "fpgroup.g" is read first and when the time comes to
evaluate 'PresentationFpGroup' it is already known and "fptietze.g" is
not read again.

If you preceed the computation with a sucessful run of 'nprec', the
problem does not appear, because the first run already reads all the
appropriate files, so on redefinition of 'PresentationFpGroup' happens.

A patch to the kernel that fixes this problem will be made available with
the second upgrade.

Thanks for your bug report.

Martin.

-- .- .-. - .. -.  .-.. --- ...- . ...  .- -. -. .. -.- .-
Martin Sch"onert,   Martin.Schoenert@Math.RWTH-Aachen.DE,   +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany