Re: run crash

From: Alberto Fasso' (fasso@SLAC.Stanford.EDU)
Date: Thu Nov 23 2006 - 02:18:33 CET

  • Next message: Norman Furlong: "Simple Question"

    It is always difficult to help when user routines are involved, especially
    complex ones like this. However, I have noticed a couple of things which
    COULD (note: not necessarily will) generate trouble. Correcting them COULD
    eliminate the the error: in any case it is worth to try.

    - Several user variables are declared REAL*4, rather than the default DOUBLE
      PRECISION. Is that really necessary? Some of them (X1, X2) are used in
      expressions where they appear squared: FR(2) = PGR*(X2*X2-X1*X1)*(Z3-Z2)
      It is easy to lose precision in such cases.
      In other cases, variables are in double precision, but are not initialized
      with the D (e.g. array COSZEN). Several constants (1., 540.) are also written
      without the D.

    - The lack of double precision is especially dangerous in subroutine
      UNIDIR:
          PHI = 2.0*PIPIPI*FLRNDM( DUMMY )
          Z = 2.0*FLRNDM( DUMMY ) - 1.0
          T = SQRT( 1.0-Z*Z )
          X= T*COS(PHI)
          Y = T*SIN(PHI)
      Since X, Y and Z here above appear from the context to be direction cosines,
      there is a large chance that they lead to bad normalization, a likely
      candidate for the crash. I suggest to set instead:
          PHI = 2.D0*PIPIPI*FLRNDM( DUMMY )
          Z = 2.D0*FLRNDM( DUMMY ) - 1.D0
          T = SQRT( 1.D0-Z*Z )
          X= T*COS(PHI)
          Y = T*SIN(PHI)
      or better:
          PHI = TWOTWO*PIPIPI*FLRNDM( DUMMY )
          Z = TWOTWO*FLRNDM( DUMMY ) - ONEONE
          T = SQRT( ONEONE-Z*Z )
          X= T*COS(PHI)
          Y = T*SIN(PHI)

    I suggest to correct at least the above in UNIDIR, and see if the problem
    disappears. There are also other minor points, for instance PGR, initialized
    as 3.14159, while PIPIPI is correctly used elsewhere. But I bet that the crash
    is due to bad cosine normalization

    Alberto

    On Tue, 21 Nov 2006, Fabio Bellini wrote:

    > Hi
    >
    > I get a reproducible crash while running my fluka executable.
    > I have my own source routine but the crash doesn't seem (to me) to depend
    > on it.
    > The version of fluka is fluka2006.3
    >
    > you can find below the gdb debbuger report. Source code, input file and
    > auxiliary files, .out and .err are in the bug_report.tar.gz file
    > attached.
    >
    > to compile:
    > lfluka -m fluka -F flukahp -L $CERNLIB -l mathlib -l packlib -L $FLUPRO/ -o Q_exe *.f
    >
    > external source:
    > setenv FLUDAT $path/ext
    >
    > to run:
    > rfluka -M1 -N0 -e Q_exe cuore_ACBORPWD_D001
    >
    >
    > the program crashes at event 753523.
    >
    > any help is welcome.
    > thanks in advance
    >
    > fabio
    >
    > *********************** gdb debbuger
    > report***********************************
    > gdb ../Q_exe core.1074
    > GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
    > Copyright 2003 Free Software Foundation, Inc.
    > GDB is free software, covered by the GNU General Public License, and you
    > are
    > welcome to change it and/or distribute copies of it under certain
    > conditions.
    > Type "show copying" to see the conditions.
    > There is absolutely no warranty for GDB. Type "show warranty" for
    > details.
    > This GDB was configured as "i386-redhat-linux-gnu"...
    > Core was generated by
    > `/home/cuore/bellini/workdir/cuore_fluka_2006/Q_exe'.
    > Program terminated with signal 6, Aborted.
    > Reading symbols from /usr/lib/libg2c.so.0...done.
    > Loaded symbols for /usr/lib/libg2c.so.0
    > Reading symbols from /lib/tls/libm.so.6...done.
    > Loaded symbols for /lib/tls/libm.so.6
    > Reading symbols from /lib/libgcc_s.so.1...done.
    > Loaded symbols for /lib/libgcc_s.so.1
    > Reading symbols from /lib/tls/libc.so.6...done.
    > Loaded symbols for /lib/tls/libc.so.6
    > Reading symbols from /lib/ld-linux.so.2...done.
    > Loaded symbols for /lib/ld-linux.so.2
    > #0 0xffffe002 in ?? ()
    >
    >
    > (gdb) bt
    > #0 0xffffe002 in ?? ()
    > #1 0x42028c55 in abort () from /lib/tls/libc.so.6
    > #2 0x40030cc1 in sig_die () from /usr/lib/libg2c.so.0
    > #3 0x40030507 in s_rnge () from /usr/lib/libg2c.so.0
    > #4 0x0804a170 in source_ (nomore=0x0) at source-Q.f:647
    > #5 0x080db8c0 in feeder_ (kendcn=0x90d5364) at feeder.f:176
    > #6 0x0804f47a in flukam_ (iflgeo=0x84a0528) at flukam.f:3101
    > #7 0x08049312 in MAIN__ () at fluka.f:278
    > #8 0x084a0436 in main ()
    > #9 0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
    >
    >
    > (gdb) frame 4
    > #4 0x0804a170 in source_ (nomore=0x0) at source-Q.f:647
    > 647 RETURN
    > Current language: auto; currently fortran
    >
    >
    >
    >
    > (gdb) list
    > 642 * Do not change these cards:
    > 643 CALL GEOHSM ( NHSPNT (NPFLKA), 1, -11, MLATTC )
    > 644 NLATTC (NPFLKA) = MLATTC
    > 645 CMPATH (NPFLKA) = ZERZER
    > 646 CALL SOEVSV
    > 647 RETURN
    > 648 *=== End of subroutine Source
    > =========================================*
    > 649 END
    > 650
    > 651 SUBROUTINE UNIDIR( X,Y,Z )

    -- 
    Alberto FassÚ
    SLAC-RP, MS 48, 2575 Sand Hill Road, Menlo Park CA 94025
    Phone: (1 650) 926 4762   Fax: (1 650) 926 3569
    fasso@slac.stanford.edu
    

  • Next message: Norman Furlong: "Simple Question"

    This archive was generated by hypermail 2.1.6 : Thu Nov 23 2006 - 09:44:54 CET