[Halld-offline] jana xerces ?? installation problem
Matthew Shepherd
mashephe at indiana.edu
Wed Aug 27 13:36:13 EDT 2014
David,
Thanks - I'll take a look at the setup. That may be the problem.
I agree that such a check can't go into JANA as some applications
don't need it.
You are certainly correct that more rigorous checking is needed in code.
However it seems something like this:
#include "JANA/jana_config.h"
if( HAVE_XERCES == 0 ){
cerr << "You moron -- you didn't compile JANA with XERCESC!" << endl;
exit( 1 );
}
inserted into appropriate main routines... or perhaps a constructor
like DApplication, might help a bit?
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
On Aug 27, 2014, at 12:15 PM, David Lawrence <davidl at jlab.org> wrote:
>
> 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
>
More information about the Halld-offline
mailing list