Hi, I have found a bad behavior from passing a bad option to TTree::Draw (actually it’s a TNtuple). I couldn’t reproduce it with a simple in-memory TTree, so I have attached a data file that can be loaded as a TNtuple to show the behavior:
TNtuple tn("CalibData","CalibData","w:a:x:e:t:tt:dt");
tn.ReadFile("arrival-times_trimmed.csv","",',');
tn.Draw("x:t","","foo"); // No Problem
tn.Draw("x:t","","*"); // No Problem
tn.Draw("x:t","","A*"); // Segmentation fault
I believe this shouldn’t result in a seg fault, but instead give some useful error message. It’s very strange that it happens seemingly only for the “A*” option which is normally a reasonable one. It gives the regular behavior of ignoring nonsense options like “foo”.
This is similar to this bug: sft.its.cern.ch/jira/browse/ROOT-4058 but there the consensus seems to be that it was from some data type problems. Here it is clearly the option choice that is making the crash.
I tried on my Mac with the standard ntuple produced by the hsimple example. I get also a seg fault with “A*”
the dump is:
===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
Thread 1 (process 58700):
#0 0x00007fff8a4a16ac in wait4 ()
#1 0x00007fff8b5e6002 in system ()
#2 0x000000010c01bc0f in TUnixSystem::StackTrace ()
#3 0x000000010c019a57 in TUnixSystem::DispatchSignals ()
#4 <signal handler called>
#5 0x000000010f5530aa in TSelectorDraw::TakeEstimate ()
#6 0x000000010f5525c8 in TSelectorDraw::TakeAction ()
#7 0x000000010f553b4e in TSelectorDraw::Terminate ()
#8 0x000000010f575a1b in TTreePlayer::Process ()
#9 0x000000010f56ee4f in TTreePlayer::DrawSelect ()
#10 0x000000010e507e0c in G__G__Tree_126_0_51 ()
#11 0x000000010c804b3f in Cint::G__ExceptionWrapper ()
#12 0x000000010c8b47fa in G__execute_call ()
#13 0x000000010c8b4ddb in G__call_cppfunc ()
#14 0x000000010c8891b3 in G__interpret_func ()
#15 0x000000010c8725e0 in G__getfunction ()
#16 0x000000010c974c20 in G__getstructmem ()
#17 0x000000010c96b48a in G__getvariable ()
#18 0x000000010c867452 in G__getitem ()
#19 0x000000010c867964 in G__getitem ()
#20 0x000000010c866666 in G__getexpr ()
#21 0x000000010c8e69cc in G__exec_statement ()
#22 0x000000010c848de8 in G__exec_tempfile_core ()
#23 0x000000010c8489a6 in G__exec_tempfile_fp ()
#24 0x000000010c8f26da in G__process_cmd ()
#25 0x000000010bfdf5e8 in TCint::ProcessLine ()
#26 0x000000010bf481c5 in TApplication::ProcessLine ()
#27 0x000000010cf30cca in TRint::HandleTermInput ()
#28 0x000000010cf2f367 in TTermInputHandler::Notify ()
#29 0x000000010cf3153d in TTermInputHandler::ReadNotify ()
#30 0x000000010c018f26 in TUnixSystem::CheckDescriptors ()
#31 0x000000010c018771 in TUnixSystem::DispatchOneEvent ()
#32 0x000000010bf9ff0a in TSystem::InnerLoop ()
#33 0x000000010bf9fd3d in TSystem::Run ()
#34 0x000000010bf48b44 in TApplication::Run ()
#35 0x000000010cf30660 in TRint::Run ()
#36 0x000000010bf3ea5f in main ()
===========================================================
Despite the fact the drawing option seems the faulty one, the crash do not occur inside the graphics part.
Do you get the same dump ?