Hi Homer,
We saw similar warnings about the Clear function on Solaris (the only place we've run the
RootApps), but it sounded less dire. Only that Event::Clear was hiding TObject::Clear. It
seemed to have no effect, so we didn't worry about it. The DEC compiler seems more picky.
It may be that we have to name Event's Clear function to something else. Do you want to give
that a whirl?
Richard
Homer Neal wrote:
> Hi Richard,
>
> I tried to create the RootApps but I ran into the following problems which
> are likely strongly related. For Asc2root I get the following crash:
>
> ylws41> ~/asc2root pyth_sugra.asc pyth_sugra.root
> Welcome to asc2root.
> Fatal in <operator delete>: storage area overwritten
> aborting
> Abort process
>
> The same happens for fastmc:
>
> ylws41> ~/fastMC /group/ppg/prj/lcd/lcd_input/pythia/std.output SmallTrackSmear.par out.asc
> Fatal in <operator delete>: storage area overwritten
> aborting
> Abort process
>
> The Event shared library was created successfully and it appears to work.
> I have successfully used it in Root to read Root files of events.
>
> ****************************************************************************
>
> When I build fastmc, the following warning (the first one) is common:
>
> ****************************************************************************
> cxx -O -nostdnew -D__osf__ -D__alpha -I/group/ppg/prj/lcd/root/root/include
> -I../src/ -I/group/ppg/prj/lcd/root/root/include
> -I/group/ppg/prj/lcd/fastmc/RootApps//Event/prod/src/
> -I/group/ppg/prj/lcd/stdhep/ -O -c \
> ../src/TrackFullSmear.cxx -o ../bin/OSF1/TrackFullSmear.o
> cxx: Warning: /group/ppg/prj/lcd/fastmc/RootApps//Event/prod/src/Event.h, line
> 33: "void Event::Clear()" does not match "TObject::Clear" -- virtual function
> override intended?
> void Clear();
> -----^
> cxx: Warning: ../src/TrackFullSmear.cxx, line 84: conversion from pointer to
> smaller integer
> (int)(tk->GetParticle()));
> ----------^
>
> --------------------------------------------------------------------------
>
> The crash is occurring in the root initialization. Instead of the full
> asc2root routine I tried the stripped routine below which gives the same
> error.
> #include <stdio.h>
>
> #include "TROOT.h"
>
> main(int argc,char *argv[]) {
>
> printf("Welcome to rint (ver 1).\n");
>
> TROOT simple("simple","Example of creation of a tree");
>
> return(0);
> }
>
> The link command I use for asc2root is:
> $(exe): $(dirbinfiles)
> if [ -f $(exe) ] ; then rm $(exe) ; fi
> ld -L/usr/lib/cmplrs/cxx \
> -rpath /usr/lib/cmplrs/cxx -expect_unresolved "*" \
> -g0 -O1 -call_shared \
> /usr/lib/cmplrs/cc/crt0.o /usr/lib/cmplrs/cxx/_main.o $+ \
> -o $(exe) $(EVENTLIB) $(LIBS) -lcxxstd -lcxx -lexc -lots -lc
> which produces:
> ld -L/usr/lib/cmplrs/cxx \
> -rpath /usr/lib/cmplrs/cxx -expect_unresolved "*" \
> -g0 -O1 -call_shared \
> /usr/lib/cmplrs/cc/crt0.o /usr/lib/cmplrs/cxx/_main.o ../bin/OSF1/rint_han.o \
> -o ../bin/OSF1/rint_han
> /group/ppg/prj/lcd/fastmc/RootApps//Event/prod/bin/OSF1/libEvent.so
> -L/group/ppg/prj/lcd/root/root/lib -lNew -lBase -lCint -lClib -lCont -lFunc
> -lGraf -lGraf3d -lHist -lHtml -lMatrix -lMeta -lMinuit -lNet -lPostscript
> -lProof -lTree -lUnix -lZip -lm -lcxxstd -lcxx -lexc -lots -lc
>
> For asc2root, theree are no warnings/errors in the compiling or linking
> but it crashes upon execution.
>
> In the debugger, the traceback looks like:
>
> signal IOT/Abort trap at >*[__kill, 0x3ff800e9c28] beq r19,
> 0x3ff800e9c40
> (dbx) where
> > 0 __kill(0x3ff800de590, 0x3ffc0085c98, 0x0, 0x3ff00000000, 0x3ff80174cc8)
> [0x3ff800e9c28]
> 1 (unknown)() [0x3ff8019bca0]
> 2 __tis_raise(0x3ff80174cc8, 0x3ffc0080310, 0x3ff8011391c, 0x6,
> 0x3ff8015e32c) [0x3ff80113918]
> 3 raise(0x3ff8011391c, 0x6, 0x3ff8015e32c, 0x140026bd8, 0x3ff80174cf4)
> [0x3ff8015e328]
> 4 abort(0x3ffbf3f78c0, 0x0, 0x0, 0x0, 0xffffffff00000000) [0x3ff80174cf0]
> 5 Abort__11TUnixSystemXi(0x0, 0x0, 0xffffffff00000000, 0x3ffc0080310,
> 0x3ffbfe2c298) [0x3ffbf3f78bc]
> 6 DefaultErrorHandler__XiUcPCcPCc(0x3ffbfe2c3d8, 0xbb8, 0x3ffffebde08, 0x1,
> 0x11fffe438) [0x3ffbfe2c294]
> 7 ErrorHandler(0x3ff80199004, 0x1f40, 0x3ff800d3f84, 0x10, 0x3ff80135e74)
> [0x3ffbfe2c3d4]
> 8 Fatal__XPCcPCce(0x3ffbf661d88, 0x3ffbf661dd8, 0x0, 0x1, 0x0)
> [0x3ffbfe2c5e0]
> 9 __dl__XPv(0x3ffbfff1f18, 0x3ffbfe0a628, 0x3ffffebde08, 0x1, 0x1)
> [0x3ffbf662748]
> 10 __dla__XPv(0x1, 0x3, 0x3ffbfe2aad0, 0x1, 0x1400011b0) [0x3ffbfff1f14]
> 11 __ct__4TEnvXPCc(0x3ff00000000, 0x200000000, 0x3ffbf3f5398, 0x1400011b0,
> 0x140001390) [0x3ffbfe2aacc]
> 12 InitSystem__5TROOTXv(0x1, 0x140002d00, 0x0, 0x200000000, 0x140001300)
> [0x3ffbfed5604]
> 13 __ct__5TROOTXPCcPCcPPXv_v(0x120002dc0, 0x11fffecc8, 0x11fffecd8,
> 0x11fffeb08, 0x120002db8) [0x3ffbfed2638]
> More (n if no)?
> 14 main(0x3ff80016140, 0x8008460d, 0x14006eae0, 0x3ffc00802a0, 0x3ffffed1adc)
> [0x120003478]
>
> Any suggestions?
>
> Many thanks for any help.
--
Richard Dubois
SLD, Stanford Linear Accelerator Center
[log in to unmask]
http://www.slac.stanford.edu/~richard/
650-926-3824
650-926-2923 (FAX)
