Unable to determine the type, Missing Dictionary error

Hello,
I’m not sure if this is an SFrame error or a Root error, but I am all out of ideas as to how to fix it. I hope someone can help me.
I am trying to connect a branch named jet_truth_code of type std::vector.
Many thanks for any help,
Geoff
I am able to compile fine, and this is the error message when running locally:
""""
( DEBUG ) TRCAnalysis : Connected branch “jet_constit_index” in tree “mini”
(VERBOSE) TRCAnalysis : src/SCycleBaseNTuple.cxx:266 (virtual TTree* SCycleBaseNTuple::GetInputTree(const char*) const): Found input tree with name mini at 0xe66e000
(VERBOSE) TRCAnalysis : /afs/desy.de/user/g/gherbert/xxl/ChargedHiggsAnalysis/SFrame/core/include/SCycleBaseNTuple.icc:292 (bool SCycleBaseNTuple::ConnectVariable(const char*, const char*, T*&) [with T = std::vector<unsigned char, std::allocator >]): Type ID: St6vectorIhSaIhEE
(VERBOSE) TRCAnalysis : /afs/desy.de/user/g/gherbert/xxl/ChargedHiggsAnalysis/SFrame/core/include/SCycleBaseNTuple.icc:301 (bool SCycleBaseNTuple::ConnectVariable(const char*, const char*, T*&) [with T = std::vector<unsigned char, std::allocator >]): The supplied variable is an object pointer
( ERROR ) TTree::SetBranc… : Unable to determine the type given for the address for “jet_truth_code”. This is probably due to a missing dictionary, the original data class for this branch is vector.
( DEBUG ) TRCAnalysis : Connected branch “jet_truth_code” in tree “mini”
( DEBUG ) TRCAnalysis : End of BeginInputFile()
( ERROR ) TUnixSystem::Di… : segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:

#0 0x0000003abe89a075 in waitpid () from /lib64/libc.so.6
#1 0x0000003abe83c741 in do_system () from /lib64/libc.so.6
#2 0x00002af64dbdae86 in TUnixSystem::StackTrace() ()
from /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/5.34.14-x86_64-slc5-gcc4.3/lib/libCore.so
#3 0x00002af64dbda75c in TUnixSystem::DispatchSignals(ESignals) ()
from /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/5.34.14-x86_64-slc5-gcc4.3/lib/libCore.so
#4
#5 0x00002af64d680ad9 in SCycleBaseNTuple::GetEvent (this=0xe0f9c60, entry=5)
at src/SCycleBaseNTuple.cxx:833
#6 0x00002af64d67b086 in SCycleBaseExec::Process (this=0xe0f9810, entry=5)
at src/SCycleBaseExec.cxx:222
#7 0x00002af6520f1420 in TTreePlayer::Process(TSelector*, char const*, long long, long long) ()
from /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/5.34.14-x86_64-slc5-gcc4.3/lib/libTreePlayer.so
#8 0x00002af64d692ffd in SCycleController::ExecuteNextCycle (
this=0x7fff61d037c0) at src/SCycleController.cxx:592
#9 0x00002af64d691159 in SCycleController::ExecuteAllCycles (
this=0x7fff61d037c0) at src/SCycleController.cxx:346
#10 0x0000000000402164 in main (argc=2, argv=0x7fff61d03ad8)
at app/sframe_main.cxx:56

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
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.

#5 0x00002af64d680ad9 in SCycleBaseNTuple::GetEvent (this=0xe0f9c60, entry=5)
at src/SCycleBaseNTuple.cxx:833
#6 0x00002af64d67b086 in SCycleBaseExec::Process (this=0xe0f9810, entry=5)
at src/SCycleBaseExec.cxx:222
#7 0x00002af6520f1420 in TTreePlayer::Process(TSelector*, char const*, long long, long long) ()
from /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/5.34.14-x86_64-slc5-gcc4.3/lib/libTreePlayer.so
#8 0x00002af64d692ffd in SCycleController::ExecuteNextCycle (
this=0x7fff61d037c0) at src/SCycleController.cxx:592
#9 0x00002af64d691159 in SCycleController::ExecuteAllCycles (
this=0x7fff61d037c0) at src/SCycleController.cxx:346
#10 0x0000000000402164 in main (argc=2, argv=0x7fff61d03ad8)
at app/sframe_main.cxx:56

“”"

Hi - This turned out to be an sframe issue,
I have now managed to solve the problem.
I had been ignoring a warning about my m_jet variables being loaded after m_cluster variables when instantiated here? - I’m afraid I no longer get this warning so can not quote exactly what it said. After correctly ordering all of the initialisations of the variable classes I am using as well as their namespaces in the header (I’m not sure exactly what actually fixed the problem), The code ran through fine.
Cheers,
Geoff