Helgrind report:

==17243== Possible data race during write of size 8 at 0x29FF0788 by thread #3
==17243== Locks held: none
==17243==    at 0x29911BB4: G4QuasiElRatios::FetchElTot(double, int, bool) (G4QuasiElRatios.cc:713)
==17243==    by 0x29912192: G4QuasiElRatios::GetElTot(double, int, int, int) (G4QuasiElRatios.cc:729)
==17243==    by 0x2991241D: G4QuasiElRatios::GetRatios(double, int, int, int) (G4QuasiElRatios.cc:99)
==17243==    by 0x2994903F: G4QuasiElasticChannel::GetFraction(G4Nucleus&, G4DynamicParticle const&) (G4QuasiElasticChannel.cc:83)
==17243==    by 0x29949BB3: G4TheoFSGenerator::ApplyYourself(G4HadProjectile const&, G4Nucleus&) (G4TheoFSGenerator.cc:83)
==17243==    by 0x29574378: G4HadronicProcess::PostStepDoIt(G4Track const&, G4Step const&) (G4HadronicProcess.cc:303)
==17243==    by 0x2A0A4FDA: G4SteppingManager::InvokePSDIP(unsigned long) (G4SteppingManager2.cc:530)
==17243==    by 0x2A0A548E: G4SteppingManager::InvokePostStepDoItProcs() (G4SteppingManager2.cc:502)
==17243==    by 0x2A0A2765: G4SteppingManager::Stepping() (G4SteppingManager.cc:209)
==17243==    by 0x2A0AD17C: G4TrackingManager::ProcessOneTrack(G4Track*) (G4TrackingManager.cc:126)
==17243==    by 0x2861D064: G4EventManager::DoProcessing(G4Event*) (G4EventManager.cc:185)
==17243==    by 0x28462D9D: RunManagerMTWorker::produce(edm::Event const&, edm::EventSetup const&, RunManagerMT const&) (RunManagerMTWorker.cc:377)
==17243==    by 0x2840485B: OscarMTProducer::produce(edm::Event&, edm::EventSetup const&) (OscarMTProducer.cc:171)
==17243== 
==17243== This conflicts with a previous write of size 8 by thread #1
==17243== Locks held: none
==17243==    at 0x29911BB4: G4QuasiElRatios::FetchElTot(double, int, bool) (G4QuasiElRatios.cc:713)
==17243==    by 0x29912192: G4QuasiElRatios::GetElTot(double, int, int, int) (G4QuasiElRatios.cc:729)
==17243==    by 0x2991241D: G4QuasiElRatios::GetRatios(double, int, int, int) (G4QuasiElRatios.cc:99)
==17243==    by 0x2994903F: G4QuasiElasticChannel::GetFraction(G4Nucleus&, G4DynamicParticle const&) (G4QuasiElasticChannel.cc:83)
==17243==    by 0x29949BB3: G4TheoFSGenerator::ApplyYourself(G4HadProjectile const&, G4Nucleus&) (G4TheoFSGenerator.cc:83)
==17243==    by 0x29574378: G4HadronicProcess::PostStepDoIt(G4Track const&, G4Step const&) (G4HadronicProcess.cc:303)
==17243==    by 0x2A0A4FDA: G4SteppingManager::InvokePSDIP(unsigned long) (G4SteppingManager2.cc:530)
==17243==    by 0x2A0A548E: G4SteppingManager::InvokePostStepDoItProcs() (G4SteppingManager2

Comments from the expert:

Code in G4QuasiElRatios::FetchElTot() (G4QuasiElRatios.cc) 

602    static std::pair<G4double,G4double> lastR(0.,0.); // The last result
...
611    static G4ThreadLocal std::pair<G4double,G4double>* *lastX_G4MT_TLS_ = 0 ; if (!lastX_G4MT_TLS_) {lastX_G4MT_TLS_ = new  std::pair<G4double,G4double>*  ; *lastX_G4MT_TLS_=0 ; }  std::pair<G4double,G4double>* &lastX = *lastX_G4MT_TLS_; // The Last ETPointers to LogTable in heap
...
713    lastR.second=t+d*(lastX[n+1].second-t)/dl; // T-Result

I think the race is on the static lastR variable, which is being written from multiple threads (so the G4QuasiElRatios object is also shared between worker threads). I guess lastR should also be thread-local.