Re: CINT/ROOT crash when TF1s that use user C++ code are used from a class

Oh, right, is this part of the TF1 constructor

// Store formula in linked list .....
TF1 *f1old = (TF1*)gROOT->GetListOfFunctions()->FindObject(name); if (f1old) delete f1old;
SetName(name);
gROOT->GetListOfFunctions()->Add(this);

so the old TF1 method had already been deleted when the second instance is created. I saw it happening when setting a break point at 'TF1::~TF1' but I didn't understand why. Thanks Lorenzo, this explains properly the problem.

John Idarraga

On Tue, 2010-06-22 at 11:19 +0200, Lorenzo Moneta wrote:
> Hi,
>
>
> There is a problem when creating two TF1 instances with the same
> name. The old instance of TF1 is deleted when a new one is created.
> See for example this old post
> http://root.cern.ch/phpBB3//viewtopic.php?t=10065
>
>
> For the functions created as a TFormula, this is not a problem,
> because in the TFormula constructor the old instance is removed from
> the global list of functions.
> I should do the same thing also in theTF1 constructor for the cases C,
> D and E.
>
>
> Cheers, Lorenzo
> On Jun 22, 2010, at 8:55 AM, Amnon Harel wrote:
>
> > Hi John,
> >
> > Thanks for looking into this.
> >
> > Yes, the use of the same name was just a simplified reproduction.
> > The problem is that I have several instances of the real class
> > (which uses several such TF1s). So your example is also better than
> > mine since it's closer to the real problem.
> >
> > If this is a real limitation of TF1s created with methods "C", "D",
> > and "E",
> > that there may not be more than one TF1 using a particular
> > user-supplied
> > C++ function, can the developers please confirm (and document) it?
> >
> > cheers,
> > Amnon
> >
> >
> > -----Original Message-----
> > From: John Paulo Idarraga Munoz
> > Sent: Mon 21-Jun-10 8:22 PM
> > To: Amnon Harel
> > Cc: roottalk_at_lxroot01.cern.ch
> > Subject: Re: [ROOT] CINT/ROOT crash when TF1s that use user C++ code
> > are used from a class
> >
> > About the second point in my last email, the problem is not that you
> > are
> > trying to create to instances with the same name. CINT is being
> > nice
> > with you and it lets you do things that a compiler wouldn't aloud.
> > But
> > that was just a general comment. Even if you use different names
> > for
> > the instances of the class 'fails', the code crashes (when trying to
> > quit CINT an all constructors are called). I am quite positive that
> > the
> > problem has to do with the pointer to the C-type class. You just
> > can't
> > have two instances of that class. Understandable but still
> > annoying ...
> > mmm ... any solution for this apart from writing one function per
> > class ?
> >
> > cheers,
> >
> > John
> >
> > On Tue, 2010-06-22 at 02:31 +0200, Amnon Harel wrote:
> > > Dear ROOT experts,
> > >
> > > I'm trying to work a complicated TF1 into a class that I
> > > use from the CINT prompt (compiled, of course). There are several
> > > odd failures, mostly of the memory corruption variety, whenever
> > > I implement the TF1 with my own C++ code.
> > >
> > > I managed to isolate one of the corruption in the following simple
> > > test case. The two classes "works" and "fails" are short, and
> > > identical
> > > except for the type of TF1 they create (by text or with a
> > function).
> > >
> > > The classes are available in:
> > >
> > > http://www-d0.fnal.gov/~aharel/test_h1.h
> > > http://www-d0.fnal.gov/~aharel/test_h1.c
> > >
> > > The test case is below.
> > >
> > > BTW: in TF1 documentation these are methods "B" and "C".
> > > I started by trying method "E" and run into the same issues.
> > >
> > > Any ideas?
> > >
> > > thanks,
> > > Amnon
> > >
> > > harelLinux:~/cms/macros> root -n
> > > ROOT 5.26/00b (tags/v5-26-00b_at_32327, Feb 11 2010, 14:21:13 on
> > linux)
> > > root [0] .L test_h1.c+
> > > Info in <TUnixSystem::ACLiC>: creating shared
> > > library /mnt/data/cms/macros/./test_h1_c.so
> > > root [1] works ww
> > > works::works
> > > root [2] works ww
> > > works::works
> > > works::~works: 152292680
> > > root [3] works ww
> > > works::works
> > > works::~works: 152275080
> > > root [4] works ww
> > > works::works
> > > works::~works: 152292680
> > > root [5] fails ff
> > > fails::fails
> > > root [6] fails ff
> > > fails::fails
> > > fails::~fails: 152287832
> > >
> > > *** Break *** segmentation violation
> > >
> > >
> > >
> > > ===========================================================
> > > There was a crash (#7 0xb724a04d in SigHandler ()
> > > from /mnt/data/downloads/root/lib/libCore.so).
> > > This is the entire stack trace of all threads:
> > > ===========================================================
> > > #0 0xb77c4422 in __kernel_vsyscall ()
> > > #1 0xb65f62a3 in waitpid () from /lib/tls/i686/cmov/libc.so.6
> > > #2 0xb659057b in ?? () from /lib/tls/i686/cmov/libc.so.6
> > > #3 0xb66c84fd in system ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > > #4 0xb724308d in TUnixSystem::Exec ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #5 0xb724929d in TUnixSystem::StackTrace ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #6 0xb7249f4d in TUnixSystem::DispatchSignals ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #7 0xb724a04d in SigHandler ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #8 0xb7240202 in sighandler ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #9 <signal handler called>
> > > #10 0x0913ba54 in ?? ()
> > > #11 0xb4e580e3 in G__test_h1_c_ACLiC_dict_2439_0_4 ()
> > > from /mnt/data/cms/macros/./test_h1_c.so
> > > #12 0xb6a5cc86 in Cint::G__ExceptionWrapper ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #13 0xb6b11fac in G__execute_call ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #14 0xb6b139d6 in G__call_cppfunc ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #15 0xb6af0d09 in G__interpret_func ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #16 0xb6adbf42 in G__getfunction ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #17 0xb6bbebc0 in G__class_2nd_decl ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #18 0xb6bd786b in G__letvariable ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #19 0xb6aa28ea in G__define_var ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #20 0xb6b40177 in G__exec_statement ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #21 0xb6a977aa in G__exec_tempfile_core ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #22 0xb6a97ab9 in G__exec_tempfile_fp ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #23 0xb6b4fddd in G__process_cmd ()
> > > from /mnt/data/downloads/root/lib/libCint.so
> > > #24 0xb7232ae4 in TCint::ProcessLine ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #25 0xb714e177 in TApplication::ProcessLine ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #26 0xb681c2de in TRint::HandleTermInput ()
> > > from /mnt/data/downloads/root/lib/libRint.so
> > > #27 0xb681bd95 in TTermInputHandler::Notify ()
> > > from /mnt/data/downloads/root/lib/libRint.so
> > > #28 0xb681ee24 in TTermInputHandler::ReadNotify ()
> > > from /mnt/data/downloads/root/lib/libRint.so
> > > #29 0xb7246f09 in TUnixSystem::CheckDescriptors ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #30 0xb7247566 in TUnixSystem::DispatchOneEvent ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #31 0xb71b5df1 in TSystem::InnerLoop ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #32 0xb71b8d5b in TSystem::Run ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #33 0xb714b957 in TApplication::Run ()
> > > from /mnt/data/downloads/root/lib/libCore.so
> > > #34 0xb681e8e0 in TRint::Run ()
> > > from /mnt/data/downloads/root/lib/libRint.so
> > > #35 0x08048ec5 in main ()
> > > ===========================================================
> > >
> > >
> > > 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.
> > > ===========================================================
> > > #10 0x0913ba54 in ?? ()
> > > ===========================================================
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
Received on Tue Jun 22 2010 - 14:29:02 CEST