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

From: John Idarraga <idarraga_at_cern.ch>
Date: Mon, 21 Jun 2010 22:01:58 -0400


Hello Amnon,

There are two things here:

  1. If you run with gdb you realize that the segmentation violation is taking place in the line

delete p_f;

inside the 'fails' destructor. But as you point out in your message, this is not happening when you use the 'works' class. On the other hand, when you do

root [5] fails ff
fails::fails
root [6] fails ff
fails::fails
fails::~fails: 152287832

the second time, it first calls the constructor of the second instance of 'fails' and then CINT calls the destructor of the first instance of the same class. But an instance of 'fails' is holding in its layout a pointer to a C type function (myfunction). My guess is the following: When CINT tries to destruct the first instance of 'fails' it needs to deal with that pointer to the C-type function that is pointing to the same address in memory than the second instance. I don't have a debug version of the ROOT lib in my laptop, so I can't 100% confirm that, but I think the address is the same and you are trying to erase something that is being used by another instance. Check the following code

root [1] fails * ff = new fails(0)
fails::fails 0
root [2] fails * fe = new fails(1)
fails::fails 1
root [3] delete ff;
fails::~fails: 156654176 0

same problem ... (i slightly modified the 'fails' class to take an integer in it's constructor). Both instances are having a hold on a common address. I think that's the problem. Conversely, in your 'works' class, this is not a problem since you don't use pointers to functions.

2) Why are you trying to create two instances of a class with the same name, in the same scope, anyway ? The compiler wouldn't aloud you to do this. I wouldn't do anything in CINT that I wouldn't be able to do in compiled code.

regards,

John Idarraga

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 - 04:02:58 CEST

This archive was generated by hypermail 2.2.0 : Tue Jun 22 2010 - 05:50:01 CEST