[Halld-offline] jana xerces ?? installation problem

Wed Aug 27 12:15:32 EDT 2014

Hi Matt,

	After you build JANA be sure to source the setenv.csh script generated by the scons
system to ensure you are using that version when you go to build sim-recon. It should be
in a directory named something like "Darwin_macosx10.9-x86_64-llvm5.1”. You can check
that the version of JANA you’re using has XERCES support in a couple of ways. The easiest
is to do this:

> grep HAVE_XERCES $JANA_HOME/include/JANA/jana_config.h
#define HAVE_XERCES   1

If you’re getting that message then it means “HAVE_XERCES” is being set to 0.

You also need to make sure the "jana-config” tool that is first in your PATH is for the JANA version
you want. This should get set by sourcing the setenv.csh file as noted above. You can run
this with the “—cflags” option and should be able to see the xerces include directory in the output.
For example:

>jana-config --cflags
-I/Users/davidl/12GeV/builds/jana_latest/Darwin_macosx10.9-x86_64-llvm5.1/include -I/usr/local/mysql/include -g -Os -arch x86_64 -fno-common -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL -I/usr/local/xerces/PRO/include -I/usr/local/xerces/PRO/include/xercesc -pthread -stdlib=libc++ -m64 -I/usr/local/root/root_v5.34.14.Darwin_macosx10.9-x86_64-llvm5.0/include/root -I/usr/local/cMsg/PRO/Darwin-x86_64/include -I/Users/davidl/HallD/builds/ccdb_1.01/include

Regarding this being a fatal error prior to crashing:
>From the JANA point of view, it does not know if the implementation being used should consider
this a fatal error or not so the best it can do is inform the user that there is likely a problem and
how it might be solved. These types of things are always a trade off in trying to make sure one
part of the code doesn’t make assumptions on how other parts of the code should work. It is
equally frustrating to have a program die due to some missing feature when the job you’re running
does not require that feature. 

I believe the correct way to handle these types of situations is to have the code that actually 
requires the feature properly check return codes or catch exceptions and exit if a fatal
condition is encountered. In your particular case, there is a call to DGeometry::GetFDCWires()
being made in the hdv_mainframe constructor whose return value is ignored. It also does
not verify that the fdcwires container actually has anything before trying to index it later on
in the DrawDetectorsXY routine causing the crash. There are likely a lot of places throughout
our code like this where good coding habits need to be exercised more rigorously.

In short, I agree with you that it should be a fatal error that is caught prior to a crash. 
That exit doesn’t really belong in JANA though at the point where there error message is
emitted.

Let me know if the above suggestions don’t fix things for you. Jon can contact me directly
too if needed. My availability this week is pretty limited so I may not be quick to respond.
I’ll be back at the lab next week though.

Regards,
-David

On Aug 27, 2014, at 11:31 AM, Matthew Shepherd <mashephe at indiana.edu> wrote:

> 
> Hi,
> 
> I'm trying to help Jon Zarling get setup with an install of the
> software framework so he can work on pi0 calibration for 
> the FCAL.  I'm trying to set his up identical to mine, which
> you think might be easy, but....
> 
> When we try to run hdview2 I see something suspicious:
> 
> JANA >>Opening source "pi0_001_smeared.hddm" of type: HDDM
> JANA ERROR>>
> JANA ERROR>>This JANA library was compiled without XERCESC support. To enable
> JANA ERROR>>XERCESC, install it on your system and set your XERCESCROOT enviro.
> JANA ERROR>>variable to point to it. Then, recompile and install JANA.
> JANA ERROR>>
> 
> and then a crash (scroll to the bottom for more of my message):
> 
> JANA >>175951 entries found (Created Magnetic field map of type DMagneticFieldMapFineMesh.
> ----------- New Event 1 -------------
> 
> 
> 
> ===========================================================
> There was a crash.
> This is the entire stack trace of all threads:
> ===========================================================
> 
> Thread 2 (Thread 0x7ffbc0590700 (LWP 29385)):
> #0  0x0000003d9980b43c in pthread_cond_wait
> 
> GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x0000000000b8546c in jana::JApplication::EventBufferThread (this=0x1bc1a10) at src/JANA/JApplication.cc:569
> #2  0x0000000000b8520d in LaunchEventBufferThread (arg=0x1bc1a10) at src/JANA/JApplication.cc:532
> #3  0x0000003d99807851 in start_thread () from /lib64/libpthread.so.0
> #4  0x0000003d98ce811d in clone () from /lib64/libc.so.6
> 
> Thread 1 (Thread 0x7ffbc0ca07e0 (LWP 29378)):
> #0  0x0000003d98cabfdd in waitpid () from /lib64/libc.so.6
> #1  0x0000003d98c3e899 in do_system () from /lib64/libc.so.6
> #2  0x0000003d98c3ebd0 in system () from /lib64/libc.so.6
> #3  0x00007ffbc5a574c8 in TUnixSystem::StackTrace() () from /share/apps/local/root_v5.34.09/lib/libCore.so
> #4  0x00007ffbc5a55fc3 in TUnixSystem::DispatchSignals(ESignals) () from /share/apps/local/root_v5.34.09/lib/libCore.so
> #5  <signal handler called>
> #6  hdv_mainframe::DrawDetectorsXY (this=0x20e6d90) at programs/Analysis/hdview2/hdv_mainframe.cc:1310
> #7  0x00000000006226e6 in hdv_mainframe::DoMyRedraw (this=0x20e6d90) at programs/Analysis/hdview2/hdv_mainframe.cc:1140
> #8  0x00000000005cf28d in MyProcessor::evnt (this=0x20cf0b0, eventLoop=<value optimized out>, eventnumber=1) at programs/Analysis/hdview2/MyProcessor.cc:188
> #9  0x0000000000bc0520 in jana::JEventLoop::OneEvent (this=0x20cf290) at src/JANA/JEventLoop.cc:588
> #10 0x00000000006353e7 in main (narg=1, argv=<value optimized out>) at programs/Analysis/hdview2/hdview2.cc:64
> ===========================================================
> 
> 
> The lines below might hint at the cause of the crash.
> If they do not help you then please submit a bug report at
> http://root.cern.ch/bugs. Please post the ENTIRE stack trace
> from above as an attachment in addition to anything else
> that might help us fixing this issue.
> ===========================================================
> #6  hdv_mainframe::DrawDetectorsXY (this=0x20e6d90) at programs/Analysis/hdview2/hdv_mainframe.cc:1310
> #7  0x00000000006226e6 in hdv_mainframe::DoMyRedraw (this=0x20e6d90) at programs/Analysis/hdview2/hdv_mainframe.cc:1140
> #8  0x00000000005cf28d in MyProcessor::evnt (this=0x20cf0b0, eventLoop=<value optimized out>, eventnumber=1) at programs/Analysis/hdview2/MyProcessor.cc:188
> #9  0x0000000000bc0520 in jana::JEventLoop::OneEvent (this=0x20cf290) at src/JANA/JEventLoop.cc:588
> #10 0x00000000006353e7 in main (narg=1, argv=<value optimized out>) at programs/Analysis/hdview2/hdview2.cc:64
> ===========================================================
> 
> 
> I assume that the error is related to the crash but it
> would be nice to abort with a message instead of
> crashing and burning if that is case.
> 
> I have verified that XERCESCROOT is set
> and have done:
> 
> scons -c ; scons install
> 
> in both jana and sim-recon but I still always get that
> error about the lack of XERCESC support and
> then get a crash.  I can't figure out why jana 
> keeps recompiling without support (or sim-recon
> keeps taking stale jana libraries).
> 
> Any advice for how to fix this?
> 
> Matt
> 
> ---------------------------------------------------------------------
> Matthew Shepherd, Associate Professor
> Department of Physics, Indiana University, Swain West 265
> 727 East Third Street, Bloomington, IN 47405
> 
> Office Phone:  +1 812 856 5808
> 
> 
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline