I've been tracking a rare and strange bug in our simulation program
for the ILC, Mokka, and it seems to be something related with the
G4Transportation process.

 In this bug a back scatter starts at (308,-713,2.5e+03) as the follow
output from the tracking verbose level 1 :
...
...
   25      308     -715  2.5e+03     0.397  0.00721     0.17      6.28
     TPCEnd eIoni
   26      308     -715  2.5e+03     0.388  0.00885     0.23      6.51
 TPCChamber Transportation
   27      306     -715 2.47e+03      0.38  0.00668     27.9      34.4
 TPCChamber eIoni

 At this point, as it enters in the tracker region, Mokka suspends the
track. When it came back to be tracked again we get the following steps:

    28      306     -715 2.47e+03     0.379 0.000621     1.85      36.3
   SiBarrel Transportation
   29      306     -715 2.47e+03     0.358   0.0146   0.0466      36.3
   SiBarrel eIoni

  The particle was in the TPCChamber volume before being suspended. As soon as
it's restarted, the Transportation decides that it's on the boundary of the
SiBarrel volume. The problem is that the SiBarrel volume normally is in the Ecal
barrel, far away from the TPCChamber. The Ecal barrel starts at R= ~1700 mm!
Both volumes are not neighbors, so it should not be a problem of ktolerance on
the boundary.

 I guess that I found the problem but not the solution. At the beginning of the
G4Transportation::AlongStepGetPhysicalInteractionLength method, a test against
the current step number decides if it need to reset several things in the
navigator. The code is:

  if( track.GetCurrentStepNumber()==1 )
  {
     // reset safety value
     //
     fPreviousSafety    = 0.0 ;
     fPreviousSftOrigin = G4ThreeVector(0.,0.,0.) ;

     // reset counter for looping particles in field
     fNoLooperTrials= 0;

     // ChordFinder reset internal state
     //
     if ( DoesGlobalFieldExist() )
     {
        G4ChordFinder* chordF= fFieldPropagator->GetChordFinder();
        if( chordF ) chordF->ResetStepEstimate();
     }

     // We need to update the current transportation's touchable handle
     // to the track's one
     //
     fCurrentTouchableHandle = track.GetTouchableHandle();
  }

 It's obvious that this reset has to be done when the track object changes. The
problem, I guess, arises when a suspended track came back to be tracked. This
code is not executed because track.GetCurrentStepNumber() is bigger than one (in
my example it returns "28"). So the transportation will track the next steps
using a bad touchable handle (the previous one) and several internal variables
with bad values.

 I forced the reset for my special test case, just replacing

  if( track.GetCurrentStepNumber()==1 )
by
  if( track.GetCurrentStepNumber()==1 ||
      (track.GetTrackID() == lookfor &&
       track.GetCurrentStepNumber() == 28))
 where lookfor is the trackID. And it works! See below:
...
...
   26      308     -715  2.5e+03     0.388  0.00885     0.23      6.51
TPCChamber Transportation
   27      306     -715 2.47e+03      0.38  0.00668     27.9      34.4
TPCChamber eIoni
the track is suspended. Later:
   28      306     -715 2.47e+03     0.378 0.000621     1.85      36.3
TPCChamber eIoni
   29      305     -715 2.46e+03      0.37  0.00397     17.8      54.1
TPCChamber eIoni
   30      305     -714 2.44e+03     0.351  0.00271     16.7      70.8
TPCChamber eIoni
...

 So I guess that it's really a bug in the G4Transportation process
and a problem for other users using suspended track.