I was trying to run the Atlas detector simulation from 11.0.41 on a file
produced with mcatnlo/herwig (let me know and i'll send the input file). I'm
using G4Atlas_Sim.py.
This uses geant4.7.1.p01.clhep1.9.2.1.
Processing the first event, the program ran for a while, then suddenly
started growing in memory size, until it filled up the entire address
space and crashed.

It looks like the problem is with the geant4 decay tables.
G4ExcitedMesonConstructor.cc sets up the following decays
for k2(1770) (and no others):

k2(1770)+ -> k2(1770)0 + pi+
-> k2(1770)+ + pi0
k2(1770)0 -> k2(1770)+ + pi-
-> k2(1770)0 + pi0

This is a cyclic set of decays. If i look with the debugger while
the memory is rapidly growing, it is these decays that are being
processed. Each time through, the track stack grows by one entry.
If i look in the input file, i see that it does contain instances
of these k2(1770) particles (PDGIDs +-10315 and +-10325).

From the PDG tables, k2(1770) decays dominantly to k2*(1430)+pi.
So i tried the appended patch, which seems to fix the memory exposion,
at least. What i do not understand at this point is why i didn't
see the same problem in the 10.0 simulation. The decay tables
are set up the same way, and i checked the input files i was using,
and they also contained k2(1770) particles.

Other notes:

- G4PhaseSpaceDecayChannel::TwoBodyDecayIt() will happily do a decay,
even if it violates energy conservation. If the total rest mass of the
daughters is greater than that of the parent, Pmx, which is supposed
to return the daughters' momena (in the parent's rest frame), returns -1.
TwoBodyDecayIt does not, however, test for this case, and treats
this as a physical momemtum.

- I occasionally see messages about a missing decay table
for D mesons:

G4Decay::DoIt : decay table not defined for D0
G4Decay::DoIt : decay table not defined for D-