| running error [message #4636] |
Mon, 09 July 2007 12:48  |
asanchez
Messages: 350
Registered: March 2006
|
first-grade participant |
From: *kph.uni-mainz.de
|
|
hi
When i run my macro by using geant4
i get this error. I really don't understand
because it was working well in the old version and now it doesn't
work anymore.
any ideas.
*** Break *** floating point exception
Using host libthread_db library "/lib/libthread_db.so.1".
Attaching to program: /proc/13364/exe, process 13364
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
done.
done.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 13364)]
done.
done.
done.
done.
done.
done.
done.
done.
done.
0x419cb788 in waitpid () from /lib/libc.so.6
#1 0x41a538c0 in __DTOR_END__ () from /lib/libc.so.6
#2 0x41964442 in do_system () from /lib/libc.so.6
#3 0x418dfc5f in system () from /lib/libpthread.so.0
#4 0x402cc2a5 in TUnixSystem::Exec () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#5 0x402cc78a in TUnixSystem::StackTrace () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#6 0x402ca507 in TUnixSystem::DispatchSignals ()
from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#7 0x402c84cc in SigHandler () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#8 0x402cf758 in sighandler () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#9 0x418de825 in __pthread_sighandler () from /lib/libpthread.so.0
#10 <signal handler called>
#11 0x452f0e8f in G4UrbanMscModel::SampleCosineTheta ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4emstanda rd.so
#12 0x452f0a52 in G4UrbanMscModel::SampleSecondaries ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4emstanda rd.so
#13 0x45278496 in G4VMultipleScattering::PostStepDoIt ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4emutils. so
#14 0x4657e08b in G4SteppingManager::InvokePSDIP ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4tracking .so
#15 0x4657dfff in G4SteppingManager::InvokePostStepDoItProcs ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4tracking .so
#16 0x4657f9ca in G4SteppingManager::Stepping ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4tracking .so
#17 0x46585da3 in G4TrackingManager::ProcessOneTrack ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4tracking .so
#18 0x465ea138 in G4EventManager::DoProcessing ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4event.so
#19 0x465eac6d in G4EventManager::ProcessOneEvent ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4event.so
#20 0x46678195 in G4RunManager::DoEventLoop ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4run.so
#21 0x46677861 in G4RunManager::BeamOn ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4/lib/Linux-g++/libG4run.so
#22 0x470985fe in TG4RunManager::ProcessRun ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4_vmc/lib/tgt_linux/libgeant4 vmc.so
#23 0x4709c867 in TGeant4::ProcessRun ()
from /misc/cbmsoft/Debian3.1/new/transport/geant4_vmc/lib/tgt_linux/libgeant4 vmc.so
#24 0x44949b34 in CbmMCApplication::RunMC (this=0x8c90638, nofEvents=19)
at /u/asanchez/fairroot_prueba/pandaroot/base/CbmMCApplication.cxx:229
#25 0x4495aed5 in CbmRunSim::Run (this=0x8b9e7b8, NStart=19, NStop=0)
at /u/asanchez/fairroot_prueba/pandaroot/base/CbmRunSim.cxx:129
#26 0x4498aac2 in G__CbmDict_777_0_7 (result7=0xbfd72560, funcname=0x8b98f80 "\001", libp=0xbfd6efb0,
hash=0) at /u/asanchez/fairroot_prueba/build/base/CbmDict.cxx:9497
#27 0x40927d5d in Cint::G__ExceptionWrapper ()
from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#28 0x409eb809 in G__call_cppfunc () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#29 0x409d8371 in G__interpret_func () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#30 0x409bd57f in G__getfunction () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#31 0x40a5e994 in G__getstructmem () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#32 0x40a55e85 in G__getvariable () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#33 0x409b2544 in G__getitem () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#34 0x409b0876 in G__getexpr () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#35 0x40a06b40 in G__exec_function () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#36 0x40a0ed99 in G__exec_statement () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#37 0x40991416 in G__exec_tempfile_core () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#38 0x40991743 in G__exec_tempfile () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#39 0x40a17d1d in G__process_cmd () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCint.so.5.14
#40 0x40222b9d in TCint::ProcessLine () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#41 0x40222d3b in TCint::ProcessLineSynch () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#42 0x4014c117 in TApplication::ProcessFile ()
from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#43 0x4014b6bf in TApplication::ProcessLine ()
from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libCore.so.5.14
#44 0x417af33b in TRint::Run () from /misc/cbmsoft/Debian3.1/new/tools/root/lib/libRint.so.5.14
#45 0x08048e64 in main ()
Root >
|
|
|
|
| Re: running error [message #4638 is a reply to message #4636] |
Mon, 09 July 2007 13:23  |
Florian Uhlig
Messages: 424
Registered: May 2007
|
first-grade participant |
From: *gsi.de
|
|
Hi Alicia
This has to do with our cmake generated libraries compared to automake generated libraries.
If there is a mathematical not defined operation like sqrt(-1) or a division by zero with cmake generated libraries you get a floating point exception. With automake generated libraries the result of such an operation is NaN (Not a Number). With this all
mathematical operation can work and the result is again a NaN.
But going on like that you don't know what's going on in your
program.
In my opinion the better way is that the program crashes when
there is an error.
The problem in this case is that the error don't occur in our code. I' am on a conference this week, but i will try to locate the error in GEANT4 and try to correct it as fast as possible.
Ciao
Florian
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
