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

Hi Amnon,

I can reproduce it, it's caused by creating a second TF1 with the same name. I'm not saying it's your fault :-) I am just stating what the code says - and it's doing different things depending on the TF1 constructor you call (function vs. expression). See
<https://savannah.cern.ch/bugs/?69073>

Thanks for your report!

Cheers, Axel.

Amnon Harel wrote on 06/22/2010 09:48 AM:
>
>
> Hi Rene,
>
> 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+
> root [1] fails* f1 = new fails
> fails::fails
> root [2] fails* f2 = new fails
> fails::fails
> root [3] delete f1
> fails::~fails: 169449448
>
> *** Break *** segmentation violation
>
> cheers,
> Amnon
>
>
> -----Original Message-----
> From: Rene Brun
> Sent: Tue 22-Jun-10 1:15 AM
> To: Amnon Harel
> Cc: John Paulo Idarraga Munoz; roottalk_at_lxroot01.cern.ch
> Subject: Re: [ROOT] CINT/ROOT crash when TF1s that use user C++ code are
> used from a class
>
> Hi Amnon,
>
> Please send the shortest possible valid C++ code reproducing your problem
>
> Rene Brun
>
> 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/%7Eaharel/test_h1.h>
>> > http://www-d0.fnal.gov/~aharel/test_h1.c
>> <http://www-d0.fnal.gov/%7Eaharel/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 ?? ()
>> > ===========================================================
>> >
>> >
>> >
>> >
>>
>>
>>