Hi all
I installed Geant3 on my Ubuntu (12.04).
I typed
and it created gbat.exe and some output (.o) files …and then I typed
, and it created gint.exe
and then I wrote:
[code] ***************************************************
-
* -
G E A N T 3 . 2 1 * -
* -
C E R N * -
* -
15/3/94 Geneva CH * -
*
MZSTOR. ZEBRA table base TAB(0) in /MZCC/ at adr 766804743 2DB48307 HEX
MZSTOR. Initialize Store 0 in /GCBANK/
with Store/Table at absolute adrs 34513325 766804743
HEX 20EA1AD 2DB48307
HEX D45A1BEA 0
relative adrs -732292118 0
with 1 Str. in 2 Links in 5300 Low words in99999970 words.
This store has a fence of 16 words.
MZLOGL. Set Log Level 0 for store 0
MZSTOR. Initialize Store 1 in /PAWC/
with Store/Table at absolute adrs 134513313 234512904
HEX 80482A1 DFA6208
HEX DA4FFCDE E045DF01
relative adrs -632292130 -532291839
with 1 Str. in 1 Links in 5001 Low words in99999990 words.
This store has a fence of 5 words.
MZLINK. Initialize Link Area /HCBOOK/ for Store 1 NL/NS= 49 4
MZDIV. Initialize Division KUIP Div in Store 1
NW/NWMAX= 5000*******, MODE/KIND= 1 1
Division 3 initialized.
MZLINK. Initialize Link Area /KCLINK/ for Store 1 NL/NS= 20 7
MZLINK. Initialize Link Area /KCVADD/ for Store 1 NL/NS= 16 16
-
* -
W E L C O M E to P A W * -
* -
Version 2.14/04 12 January 2004 * -
*
Workstation type (?=HELP) =1 :
[/code]
but when I type “1”, it goes out! and writes:
[code]MZDIV. Initialize Division HIGZ in Store 1
NW/NWMAX= 10000*******, MODE/KIND= 0 3
Division 20 initialized.
MZLINK. Initialize Link Area /HILINK/ for Store 1 NL/NS= 42 2
MZLINK. Initialize Link Area /SICLIN/ for Store 1 NL/NS= 9 0
Version 1.29/04 of HIGZ started
CSALLO: heap below bss?!
See the file /usr/share/doc/libpawlib2-dev/README.Debian for more information.
If it does not help to solve this problem, please file a bug report against
the libpawlib2-dev package, including the source code of your executable.
[/code]
and I read that (README.Debian), it’s for my system:
[ul]3) On 32-bit architectures, please read this note carefully if you link against
pawlib dynamically so that the COMIS interpreter works correctly in your
application. This is especially applicable if your application dies with this
error message:
CSALLO: heap below bss?!
If you link statically, this note does not concern you. The default output of
the “cernlib” script includes the -static compiler flag, so a program linked
via a command like one of these:
gfortran myprogram.F -o myprogram `cernlib pawlib`
gcc file1.o file2.o file3.o -o myprogram `cernlib pawlib`
is statically linked to pawlib.
If you have doubts, run ldd on your executable; a statically linked program
should NOT have the output of ldd include a line similar to this:
libpawlib.so.2 => /usr/lib/libpawlib.so.2 (0x0f7eb000)
Executive summary
a) If your executable’s main source code file is written in FORTRAN, it should
#include <comis/mdpool.inc>
immediately after the " PROGRAM programname" line.
b) If your executable’s main source code file is written in C or C++, it should
#include <comis/mdpool.h>
at the top of the source code.
It is only necessary for one file of your source code to include mdpool.inc or
mdpool.h, and may in fact cause linking problems if more than one file does so.
Do not include mdpool.inc or mdpool.h in a header file unless that file is
itself only #included by one source file.
Technical details
The authors of COMIS (the PAW interpreter) used two memory allocation areas;
one is the integer array IQ (size: 50006 integers) in the COMMON block MDPOOL,
and the other is dynamically allocated by malloc() in the CSALLO function. The
difference between the malloc()ed pointer address and the address of the common
block is returned to FORTRAN code, so it can access the new memory by using the
appropriate array subscript in MDPOOL/IQ.
The idea is similar to that expressed in the following C code:
#include <stdlib.h>
typedef struct { int iq[50006]; } mdpool_def;
mdpool_def mdpool;
int main()
{
unsigned long iqpntr = (unsigned long)mdpool.iq;
unsigned long lpntr = (unsigned long)malloc(sizeof(int));
int index = (lpntr - iqpntr) / sizeof(int);
mdpool.iq[index] = 5;
return mdpool.iq[index];
}
The problem is that the FORTRAN code in pawlib expects the address difference
(the variable “index” in the above example) to be positive. This is fine when
an executable is statically linked to pawlib, since then the malloc()ed space
in the heap is always at a larger address than MDPOOL in the binary’s bss
segment. But on some (most?) architectures, shared libraries, including MDPOOL
in libpawlib.so, are mapped into memory beyond the program stack, yielding a
negative address offset.
After a lot of trying, I concluded that tracking down all the places in the
FORTRAN code that expected a positive pointer offset from MDPOOL would be very
difficult and error-prone, so the solution is to attack the problem from the
other end. That is, declare MDPOOL/IQ in the dynamically linked executable.
Then MDPOOL will always be present in these executables’ bss segments, whose
address is always less than that of space allocated on the heap. This is
accomplished by #include’ing <comis/mdpool.inc> or <comis/mdpool.h> in the
source code for the executable. See, e.g., the file
/usr/share/doc/libpawlib2-dev/examples/pamain.c .
– Kevin McCarty kmccarty@debian.org, Mon, 29 Nov 2004[/ul]
But I wrote:
it brought some addresses:
/home/username/cern/pro/2006b/include/comis/mdpool.inc
/usr/include/comis/mdpool.inc
and:
it exists!!! 
What do you suggest to do?
thank you
regards
tooba
