Poking further, since the last error is that of MPI and not of CRYSTAL, I launched the same input with NEWK 8 8 as a single-core process (with Pproperties), and this time the error was different:

  85-C(  3  2  4)  86-C(  4  2  4)  87-C(  5  2  4)  88-C(  3  3  4)
  89-C(  4  3  4)  90-R(  4  4  4)
 ERROR **** PROJVR **** NULL COMPONENT
   0.222045E-15   0.100000E-07

for

ROTREF
ATOMS
10 # this is Manganese
0 0 0 # I also tried this with different cell indices
12 # P5
0 0 0
8 # P2
0 0 0

and then

  85-C(  3  2  4)  86-C(  4  2  4)  87-C(  5  2  4)  88-C(  3  3  4)
  89-C(  4  3  4)  90-R(  4  4  4)
 ERROR **** RHOLSK **** BASIS SET LINEARLY DEPENDENT

for the following input:

ROTREF
ATOMS
10
1 0 0
12
1 0 1
8
1 1 0

As well as for other indices

What I have realised is that I may not need to perform an actual rotation. Quote from the manual:

A rotation of the eigenvectors can be
obtained in properties by entering the keyword ROTREF, allowing AO projected Density
of States or Population Analysis orienting the cartesian frame along the principal axes of the
octahedron.

I was hoping that defining a plane with three atoms that include the Mn-P axis and one of the two O atoms would be sufficient

For instance,

ROTREF
ATOMS
10 # this is Manganese
0 0 0 # I also tried this with different cell indices
12 # P5
0 0 0
8 # P2
0 0 0
NEWK
8 8 
1 0
DOSS

Or , when that resulted in an error immediately after k-point generation, I thought that maybe changing k-points will help, but both

NEWK
1    1
1    0

and

NEWK
11  11 
1   0

end up in

181-C(  6  3  5) 182-C(  7  3  5) 183-C(  4  4  5) 184-C(  5  4  5)
185-C(  6  4  5) 186-C(  5  5  5)
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 19 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[lasc110:51218] PMIX ERROR: UNREACHABLE in file server/pmix_server.c at line 2198
forrtl: error (78): process killed (SIGTERM)
Image              PC                Routine            Line        Source             
Pproperties        00000000061B7B8B  for__signal_handl     Unknown  Unknown
libpthread-2.17.s  00007FE293190630  Unknown               Unknown  Unknown
Pproperties        000000000141ADBC  Unknown               Unknown  Unknown
Pproperties        0000000000548C2C  Unknown               Unknown  Unknown
Pproperties        0000000000543D3B  Unknown               Unknown  Unknown
Pproperties        000000000040F5DC  Unknown               Unknown  Unknown
Pproperties        000000000040DB92  Unknown               Unknown  Unknown
Pproperties        000000000040D9A2  Unknown               Unknown  Unknown
libc-2.17.so       00007FE292DD5555  __libc_start_main     Unknown  Unknown
Pproperties        000000000040D8AA  Unknown               Unknown  Unknown

JohnKendrick
I have had the same problem in a slightly different task. I have found a solution, but it may not work for your particular task: I have reduced the number of k-points.
I am modelling Mn5+ ion in a AlPO4 cell in which one P is replaced by Mn.
My input is

EXTERNAL
FREQCALC
ANALYSIS
INTENS
INTRAMAN
INTCPHF
END
END
BASISSET
POB-TZVP-REV2
DFT
WC1LYP
SPIN
END
EXCHSIZE 
44000000
BIPOSIZE
44000000
SHRINK
6 6
TOLINTEG
9 9 9 12 20
MAXCYCLE
400
TOLDEE
10
SPINLOCK
2
-6
ATOMSPIN
1
10 1
SLOSHING
END

The same input with

SHRINK
8 8

Produced the same error as yours, regardless of convergence tools (DIIS / NODIIS (in CPHF block) / buffer sizes / etc):

ELECTRIC FIELD APPLIED ALONG CARTESIAN DIRECTIONS XX
[some lines omitted]

BECKE WEIGHT FUNCTION
RADSAFE =     2.00
TOLERANCES - DENSITY:10**- 6; POTENTIAL:10**- 9; GRID WGT:10**-14

RADIAL INTEGRATION  - INTERVALS (POINTS,UPPER LIMIT):            1( 75,  4.0*R)

ANGULAR INTEGRATION - INTERVALS (ACCURACY LEVEL [N. POINTS] UPPER LIMIT):
 1(  4[  86]   0.2)  2(  8[ 194]   0.5)  3( 12[ 350]   0.9)  4( 16[ 974]   3.5)
 5( 12[ 350]9999.0)
TTTTTTTTTTTTTTTTTTTTTTTTTTTTTT MOQGAD      TELAPSE     7695.33 TCPU     7664.63
forrtl: severe (67): input statement requires too much data, unit 81, file /scratch/tmp_p267436_student/fort.81.pe11

All running on a single machine: Dell EMC C6400 Server (2x20-Core Intel XEON Gold 6148 2.40GHz, 192GB RAM, 3x480GB SSD).

Hello!
I am struggling to understand the way in which CRYSTAL rotates the atoms. Here is my structure:
reference.f34
I want to rotate all atoms so that Mn remains in place, and oxygens NN 21&23 move to the ac (xz) plane. This, in essence, is a rotation around the axis 10Mn-12P, the result of which should be that
Y coordinate of Mn = Y(O21) = Y(O23). The angle that should work is +-24.7159 degrees, depending on the direction that CRYSTAL uses.
So, I tried

ATOMROT
0 # include all atoms
999 1 # no translation & rotation around a specified axis
10 12 # atom labels that define rotation axis
+/-24.7159 # angle (degrees)

To the effect of

ALL THE  36 ATOMS IN THE REFERENCE CELL ARE MANIPULATED

SELECTED ATOMS ARE ROTATED AROUND THE AXIS DEFINED BY TWO ATOMS:  10  12
(DIRECTION COSINES  0.000  0.000 -1.000) BY AN ANGLE:  24.72

ATOM  10 AT.N.  25 COORDINATES   4.46889   0.00000   2.24246
ATOM  21 AT.N.   8 COORDINATES  -2.74300   2.67751   3.17915
ATOM  23 AT.N.   8 COORDINATES   3.56177   1.05955   3.17915

and

ALL THE  36 ATOMS IN THE REFERENCE CELL ARE MANIPULATED

SELECTED ATOMS ARE ROTATED AROUND THE AXIS DEFINED BY TWO ATOMS:  10  12
(DIRECTION COSINES  0.000  0.000 -1.000) BY AN ANGLE:  -24.72

ATOM  10 AT.N.  25 COORDINATES   4.46889   0.00000   2.24246
ATOM  21 AT.N.   8 COORDINATES  -2.25530  -3.73706   3.17915
ATOM  23 AT.N.   8 COORDINATES   3.07407   0.00001   3.17915

So the second method maybe worked? Except that I have been unable to visualize/confirm it using VESTA, because the output of edited geometry section looks the same as the input*.

So, my questions are:

1. how to validate the result of rotation?
2. when using ROTCRY+MATROT, where is the origin of rotation?
3. which method of rotation I should use in this situation?

*VESTA, of course, does not open .f34 files, so my usual workflow is to convert CRYSTAL output to a VASP-POSCAR format:

Structure description line
1.0 #scaling factor
[DIRECT LATTICE VECTORS CARTESIAN COMPONENTS (ANGSTROM)]
List-of-elements
Amounts-of-each-element
Direct or Cartesian # coordinate format
[list of coordinates in the selected format]

Hello!
I found the source file. I have also learned that the .f9 was calculated with Crystal17, and that malloc happened in Props17, not in Props23 (I am likewise not sure whether the calculation that failed for my colleague was done using v17 or v23). This might have been a limitation of the machine that I was using, because the same calculation didn't crash with NEWK 36 72.
malloc.d12

I am sorry if that turns out irrelevant, and of no use in the current version of Crystal.

What is the point of setting any value of TOLINTEG past 20?
A quote from the manual:

CRYSTAL adopts truncation criteria for Coulomb and exchange sums: to remove them,
in input block 3 insert:
TOLINTEG
20 20 20 20 20

Or is this particular set of values a hard-coded switch, like the line "99 0" that terminates the basis set input?

Dear Aleks,
thank you for helpful suggestoins! The issue of divergence slipped past my attention, as a very similar calculation -- started from the same geometry, with the same values of FDOCCUP and SPINLOCK, but without NODIIS and EIGSHIFT -- converged in just 31 SCF cycles.

I tested your suggestion of adding to this input FMIXING (I went with 65%) and increasing TOLINTEG to 9 9 9 11 20, but it still diverges:

 CYC   0 ETOT(AU) -3.272838921072E+04 DETOT -3.27E+04 tst  0.00E+00 PX  1.00E+00
 CYC   1 ETOT(AU) -3.265248439176E+04 DETOT  7.59E+01 tst  0.00E+00 PX  1.00E+00
 CYC   2 ETOT(AU) -3.264532086387E+04 DETOT  7.16E+00 tst  3.64E-01 PX  9.98E-01
 CYC   3 ETOT(AU) -3.265874325232E+04 DETOT -1.34E+01 tst  1.16E+00 PX  2.45E+00
 CYC   4 ETOT(AU) -3.264891945690E+04 DETOT  9.82E+00 tst  7.87E-01 PX  2.27E+00
 CYC   5 ETOT(AU) -3.254860144024E+04 DETOT  1.00E+02 tst  4.49E-01 PX  2.71E+01
 CYC   6 ETOT(AU) -3.058859793674E+04 DETOT  1.96E+03 tst  3.20E+00 PX  3.32E+02
 CYC   7 ETOT(AU) -2.155342398855E+04 DETOT  9.04E+03 tst  3.59E+03 PX  1.30E+03
 CYC   8 ETOT(AU) -1.061409920226E+04 DETOT  1.09E+04 tst  6.90E+03 PX  6.97E+02
 CYC   9 ETOT(AU) -1.534233758958E+04 DETOT -4.73E+03 tst  6.48E+03 PX  6.91E+02
 CYC  10 ETOT(AU) -2.109155329839E+04 DETOT -5.75E+03 tst  2.31E+04 PX  5.40E+02
...
 CYC  20 ETOT(AU) -2.714221021396E+04 DETOT  1.99E+01 tst  1.56E+02 PX  3.07E+02
 CYC  21 ETOT(AU) -2.682694963926E+04 DETOT  3.15E+02 tst  7.09E+01 PX  2.97E+02

I guess, there is just no simple way of forcing a particular spin configuration AND a particular charge state to an ion

Here is an old input that caused malloc on two different computer systems (I think one of these was Cineca, but that one was run for me by my colleague). I do not need the result of this calculation anymore, but I was told to share it during Crystal school this autumn.
malloc.d3
sb_wyckoff_tzvp.f9

Hello!
I was running several jobs with different combinations of FDOCCUP, SPINLOCK, and EIGSHIFT. I abandoned most of them, but two crashed with an error message that I have never seen before. All jobs were using the same external geometry file.

alpo4_186_mn_conf_01_ddd.out

alpo4_186_mn_conf_22_ddd.out