[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: errors/seg-fault in hdgeant

To: Richard Jones <richard.t.jones@uconn.edu>
Subject: Re: errors/seg-fault in hdgeant
From: David Lawrence <davidl@jlab.org>
Date: Fri, 24 Oct 2008 10:47:27 -0400
CC: halld-offline@jlab.org
In-Reply-To: <4901DADD.30808@uconn.edu>
References: <4900783C.7000007@jlab.org> <49008733.9030903@jlab.org> <4901DADD.30808@uconn.edu>
Reply-To: David Lawrence <davidl@jlab.org>
Sender: owner-halld-offline@jlab.org
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)


Hi Richard,

    I see that the bimsel.F file is in the gelhad directory and it is 
being compiled with by BMS with the following:

gfortran -DCERNLIB_MOTIF -D_GELH_ -DCERNLIB_TYPE -I.. -I. -I.. 
-I../include -I/Users/davidl/HallD/builds/latest/include 
-I/usr/local/cern/PRO/include -I/usr/include/cernlib/PRO -Wall   -c -o 
bimsel.o bimsel.F
ar rv .lib/Darwin_macosx10.4-i386-gcc4.0.1/libgelhad.a bimsel.o
a - bimsel.o


Notice though that it is being placed in the gelhad library file 
libgelhad.a. The link command from my Mac is below. The main thing to 
note is that the bimsel.o object comes in through one of two libraries. 
A cernlib one or libgelhad.a. The gelhad library comes first on the link 
command, but experience tells me that does not guarantee that is where 
the object is pulled from.

I think it might be worthwhile if Mark tried using your Makefile first 
to see if he can reproduce the problem when the executable is linked in 
a different way since I don't think we can rule out that this isn't the 
bug you already fixed.


Regards,
-David

========= hdgeant link command =========
g++ -multiply_defined suppress -bind_at_load 
-L/Users/davidl/12GeV/builds/latest/Darwin_macosx10.4-i386-gcc4.0.1/lib 
-L/Users/davidl/HallD/builds/latest/lib/Darwin_macosx10.4-i386-gcc4.0.1 \
   .obj/Darwin_macosx10.4-i386-gcc4.0.1/hdgeant.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/beamgen.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/bintree.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/calibDB.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/cobrems.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/fint.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gltrac.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/goptimize.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gpairg.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gsrotm.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gsstak.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gthion.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/guhadr.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gukine.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/guout.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/guphad.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gustep.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/guxcs.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gxcs.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gxint.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/gxphys.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hddmInput.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hddmOutput.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hddsGeant3.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hdgeant_f.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitBCal.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitCDC.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitCerenkov.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitFCal.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitFDC.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitFTOF.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitGCal.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitStart.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitTag.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/hitUPV.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/memcheck.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/savehits.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/seteventid.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/settofg.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/storeTrajectory.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/timel.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/trapfpe.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/uginit.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/uglast.o 
.obj/Darwin_macosx10.4-i386-gcc4.0.1/vunit.o \
   -lHDDM -lHDGEOMETRY -lJANA -L/sw/lib -lXm -L/usr/X11R6/lib -lXt 
-lgelhad -lhitutil /usr/local/cern/PRO/lib/libgeant321.a 
/usr/local/cern/PRO/lib/libpawlib.a /usr/local/cern/PRO/lib/liblapack3.a 
/usr/local/cern/PRO/lib/libblas.a /usr/local/cern/PRO/lib/libgraflib.a 
/usr/local/cern/PRO/lib/libgrafX11.a 
/usr/local/cern/PRO/lib/libgrafX11.a 
/usr/local/cern/PRO/lib/libpacklib.a 
/usr/local/cern/PRO/lib/libmathlib.a 
/usr/local/cern/PRO/lib/libkernlib.a -L/usr/X11R6/lib -lX11 
-L/usr/local/cern/PRO/lib -ldl  -L/usr/local/lib -lgfortran 
-L/usr/local/xerces/PRO/lib -lxerces-c -lpthread \
   -o .bin/Darwin_macosx10.4-i386-gcc4.0.1/hdgeant



Richard Jones wrote:
> Beni, Mark, and all,
>
> It is not unexpected that the transition from g77 to gfortran might 
> cause errors in cernlib to surface.  I have already found and fixed 
> one in fluka routine bimsel.F.  You should make sure that your working 
> directory contains the file HDGeant/gelhad/bimsel.F and that you are 
> linking to a gelhad library that contains this file. and that it is 
> getting linked in ahead of the default copy in libgeant321.  I am 
> using my own Makefile (called Makefile.orig in the project directory) 
> so I am not sure what the default BMS make system is doing.
>
> If you determine that this error is not just a mistake you made in the 
> built or geometry, can you create a page on the wiki containing ALL of 
> the information that I need to reproduce the error, including a log 
> from the failed run, and the starting random numbers, the output from 
> "gfortran -v" and "gcc -v" on the system where the error occurs?  From 
> that I will be able to reproduce the error and produce a fix.  Knowing 
> the internals of geant3, I think I can do this fairly quickly.
>
> Richard Jones
>
> Beni Zihlmann wrote:
>> Hi Mark,
>> I used your control.in file runing hdgeant in debug mode but using 
>> the latest
>> repository code. I do not see the geometry errors, however, I also 
>> get a segmentation
>> fault as indicated below. It seems the segmentation fault happens in 
>> a geant routine.
>> maybe the data it gets is corrupted according to the geant manual:*
>> **CALL GMICAP * GMICAP 
>> <http://www.kph.uni-mainz.de/computing/docu/geant/Geant-HTML/node352.html#GMICAP> 
>> calls the MICAP routines to handle the low-energy
>> interaction of neutrons. It writes the eventual secondaries to the 
>> GEANT stack. GMICAP 
>> <http://www.kph.uni-mainz.de/computing/docu/geant/Geant-HTML/node352.html#GMICAP> 
>>
>> is called from GFMFIN 
>> <http://www.kph.uni-mainz.de/computing/docu/geant/Geant-HTML/node352.html#GFMFIN>. 
>>
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread -1209014576 (LWP 4261)]
>> 0x0831aaaf in gmicap_ ()
>> (gdb) bt
>> #0  0x0831aaaf in gmicap_ ()
>> #1  0x0831942a in gfmfin_ ()
>> #2  0x08061036 in guhadr_ () at guhadr.F:131
>> #3  0x0871f919 in jumpt0_ ()
>> #4  0x000000a3 in ?? ()
>> #5  0x426c9445 in ?? ()
>> #6  0xbf824558 in ?? ()
>> #7  0x083d3e22 in gtneut_ ()
>> #8  0x0838fd95 in gtrack_ ()
>> #9  0x0831850f in gutrak_ ()
>> #10 0x0871f919 in jumpt0_ ()
>> #11 0x60000000 in ?? ()
>> #12 0x3f87a2a8 in ?? ()
>> #13 0xbf824878 in ?? ()
>> #14 0x08311f18 in gtreve_ ()
>> #15 0x0831851f in gutrev_ ()
>> #16 0x0871f919 in jumpt0_ ()
>> #17 0x0b0f8ec8 in Maxpoints ()
>> #18 0x0b0f8ca8 in gcbank_ ()
>> #19 0x087a3e14 in load.1574 ()
>> #20 0x082801f1 in gtrig_ ()
>> #21 0x082800a8 in grun_ ()
>> #22 0x08205e20 in hdgeant_ () at hdgeant_f.F:29
>> #23 0x0805385f in main () at hdgeant.cc:7
>>
>>
>> #2  0x08061036 in guhadr_ () at guhadr.F:131
>> 131             CALL GFMFIN
>> Current language:  auto; currently fortran
>> (gdb) list
>> 126           IF (IHADR.LT.3) THEN
>> 127             CALL GHEISH
>> 128           ELSE IF (IHADR.EQ.3) THEN
>> 129             CALL FLUFIN
>> 130           ELSE
>> 131             CALL GFMFIN
>> 132           ENDIF
>> 133           END
>>
>>
>> Mark M. Ito wrote:
>>> Experts,
>>>
>>> Using version from release-2008-10-21, control.in attached. 
>>> BMS_OSNAME = Linux_Fedora9-i686-gcc4.3.0
>>>
>>> **** GTCKOV: error from GLISUR =          1
>>> GGPERP - geometry check error for shape #12!
>>> **** GTCKOV: error from GLISUR =          1
>>> GGPERP - geometry check error for shape #12!
>>> **** GTCKOV: error from GLISUR =          1
>>> GGPERP - geometry check error for shape #12!
>>> **** GTCKOV: error from GLISUR =          1
>>> GGPERP - geometry check error for shape #12!
>>> **** GTCKOV: error from GLISUR =          1
>>> GGPERP - geometry check error for shape #12!
>>> **** GTCKOV: error from GLISUR =          1
>>> **** GTRIGI: IEVENT=   4000 IDEVT=   4000 Random Seeds = 
>>> 1574106590   226018363
>>>        4000  events simulated
>>> Segmentation fault
>>>
>>> The reported error may or may not have something to do with the seg 
>>> fault. It appeared many times well before the crash on several events.
>>>
>>>  -- Mark
>>>
>>
>
>

-- 

------------------------------------------------------------------------
 David Lawrence Ph.D.
 Staff Scientist                 Office: (757)269-5567   [[[  [   [ [       
 Jefferson Lab                   Pager:  (757)584-5567   [  [ [ [ [ [   
 http://www.jlab.org/~davidl     davidl@jlab.org         [[[  [[ [[ [[[
------------------------------------------------------------------------

Follow-Ups:
- Re: errors/seg-fault in hdgeant
  - From: Richard Jones <richard.t.jones@uconn.edu>

References:
- errors/seg-fault in hdgeant
  - From: "Mark M. Ito" <marki@jlab.org>
- Re: errors/seg-fault in hdgeant
  - From: Beni Zihlmann <zihlmann@jlab.org>
- Re: errors/seg-fault in hdgeant
  - From: Richard Jones <richard.t.jones@uconn.edu>

Prev by Date: Re: errors/seg-fault in hdgeant
Next by Date: Re: errors/seg-fault in hdgeant
Prev by thread: Re: errors/seg-fault in hdgeant
Next by thread: Re: errors/seg-fault in hdgeant
Index(es):
- Date
- Thread