[ROOT] Re: Root macro works on 5.16, bombs on 5.18

More info from Linux (Fedora Core 8, Root 5.18):

It is rather difficult to debug this as my terminal does not echo what I 
type when debugging (5.16 or 5.18). It does echo when I start up, load 
the macro file, set a breakpoint in it, and run the macro function. The 
macro opens a GUI window which I use to open a root file, select an 
NTuple, enter "x" as the expression to histogram, and push the 
CreatePlot button.

The macro executes to my breakpoint and I step to
	TNtuple *nt = ntuples[0];
and ".p *nt" prints a full TNtuple (quite long -- appended below).

The next line of the macro is
	printf("C1 expr_x='%s' nt=%08lX\n",expr_x,(long)nt);
and it correctly prints "C1 expr_x='x' nt=0A5256C0". In particular note 
that nt is not NULL, and we agree on the address: 0x0A5256C0=173168320.

The next line of the macro is
	printf("C1 nt->Nvar=%d\n",nt->GetNvar());
The command ".s" prints "!!!Calling compiled function GetNvar()" 
followed by a blank line. Another ".s" command prints:
  *** Break *** segmentation violation
... very long stack trace also appended below

This sure looks like a Cint problem to me -- I don't see how an 
interpreted macro could possibly screw things up like that. Unless, of 
course, nt does not really point to a TNtuple; but in that case how does 
it work in 5.16?

RE: [ROOT] Re: Root macro works on 5.16, bombs on 5.18

Hi Tom,

Can you send us the root file and enough your script/instruction
to reproduce this problem?

Cheers,
Philippe.

PS.  Did you try investigating this with valgrind?

-----Original Message-----
From: owner-roottalk <at> root.cern.ch [mailto:owner-roottalk <at> root.cern.ch] On
Behalf Of Tom Roberts
Sent: Friday, February 29, 2008 11:30 PM
To: 'ROOT Talk'
Subject: [ROOT] Re: Root macro works on 5.16, bombs on 5.18

More info from Linux (Fedora Core 8, Root 5.18):

It is rather difficult to debug this as my terminal does not echo what I 
type when debugging (5.16 or 5.18). It does echo when I start up, load 
the macro file, set a breakpoint in it, and run the macro function. The 
macro opens a GUI window which I use to open a root file, select an 
NTuple, enter "x" as the expression to histogram, and push the 
CreatePlot button.

The macro executes to my breakpoint and I step to
	TNtuple *nt = ntuples[0];
and ".p *nt" prints a full TNtuple (quite long -- appended below).

[ROOT] python ROOT access

Hi ROOTers,
could someone with pyROOT configured properly check the following in python:

(ROOT 5.19/01)

$ python
Python 2.5.2 (r252:60911, Feb 27 2008, 18:32:21)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ROOT
>>> combi  = ROOT.TGeoCombiTrans()
>>> matrix = combi.GetRotationMatrix()
>>> print matrix[0]
1.0
>>> matrix[0]=0.99

 *** Break *** segmentation violation
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Attaching to program: /proc/8053/exe, process 8053
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d428c0 (LWP 8053)]
[New Thread 0xb521db90 (LWP 8069)]
(no debugging symbols found)...done.

0xb7eef410 in __kernel_vsyscall ()
error detected on stdin
The program is running.  Quit anyway (and detach it)? (y or n)
[answered Y; input not from terminal]
Detaching from program: /proc/8053/exe, process 8053

Re: [ROOT] python ROOT access

I see the same result with 5.18 on Mac OS X 10.5.2.

The problem is that PyROOT is letting you violate the method signature  
of GetRotationMatrix():

const Double_t *TGeoCombiTrans::GetRotationMatrix() const;

You should not assign values using the Double_t pointer returned by  
the method, as it is declared const.  Assignment worked anyway for  
TGeoRotation since the method always returns a pointer to an internal  
buffer in the object.  However, TGeoCombiTrans does this:

const Double_t *TGeoCombiTrans::GetRotationMatrix() const
{
// get the rotation array
    if (!fRotation) return kIdentityMatrix;
    return fRotation->GetRotationMatrix();
}

When it takes the first branch, it returns a pre-defined constant  
matrix, which for some reason triggers a segfault when you try to  
modify it.

See the TGeoCombiTrans constructor for the correct way to instantiate  
it with a given offset and rotation.

On Mar 2, 2008, at 2:22 PM, Michal Dwuznik wrote:

> Hi ROOTers,
> could someone with pyROOT configured properly check the following in  

Re: [ROOT] python ROOT access

Thank you,

going around via defining

xyz=TGeoTranslation()
rot=TGeoRotation()

modifying those and creating
combi=TGeoCombiTrans()
combi.SetTranslation(xyz)
combi.SetRotation(rot) works as advertised :)

Regards
Michal

2008/3/2, Stanley Seibert <volsung <at> physics.utexas.edu>:
> I see the same result with 5.18 on Mac OS X 10.5.2.
>
>  The problem is that PyROOT is letting you violate the method signature
>  of GetRotationMatrix():
>
>  const Double_t *TGeoCombiTrans::GetRotationMatrix() const;
>
>  You should not assign values using the Double_t pointer returned by
>  the method, as it is declared const.  Assignment worked anyway for
>  TGeoRotation since the method always returns a pointer to an internal
>  buffer in the object.  However, TGeoCombiTrans does this:
>
>  const Double_t *TGeoCombiTrans::GetRotationMatrix() const
>  {

[ROOT] Re: problem with root 5.18

Hi Antonio,

First off, it seems that your question should really be sent to the ROOT
mailing list or forum, as it is not really Debian specific.   The good
people over at roottalk <at> root.cern.ch and at the ROOT forum are usually
every good at answering questions.  I've Cc'ed this to
roottalk <at> root.cern.ch.

On Fri, 2008-02-29 at 19:08 +0100, Antonio Salvucci wrote:
> Hi list,
> 	I have some problems with ROOT 5.18. I compiled this version using debian 
> rules from Christian Holm Christensen debian repository (I'm using an amd64 
> Debian OS).
> In this version i have the same problem with 5.17 one.
> In fact, I have to load some .root files, and i use this way
> 
>  		TChain *tree = new TChain("CollectionTree","")
>                 tree->Add("path's files ")
>                 tree->MakeClass("name")
> 
> then I compile with .L name.C.

I guess you did something to "name.C" first.   The recommendation is
actually to derive a class from "name" and overload the member functions
you need to do something in. 

> When I run my program, with .Loop() command, my root does anything or returns 
> errors.
> 
> I insert some debug lines in my code as i show

[ROOT] Re: problem with root 5.18

Hi Christian,

		I sent the mail to Debian Science because I think the problem isn't root 
one, but  about my 64Bit Debian Os.
In fact the program name.C run without problem on another 32Bit Debian system 
(my desktop home).
In my opinion there is a problem with libc6 in my distro.

if you write on shell

dpkg -S /lib/libthread_db.so.1

dpkg return the package libc6.

What version of libc6 do you use with root 5.17??
I use this one 2.7-9. 

Cheers, 
Antonio

Il Monday 03 March 2008 08:43:09 Christian Holm Christensen ha scritto:
> Hi Antonio,
>
> First off, it seems that your question should really be sent to the ROOT
> mailing list or forum, as it is not really Debian specific.   The good
> people over at roottalk <at> root.cern.ch and at the ROOT forum are usually
> every good at answering questions.  I've Cc'ed this to
> roottalk <at> root.cern.ch.
>
> On Fri, 2008-02-29 at 19:08 +0100, Antonio Salvucci wrote:

Re: [ROOT] timestamps

Hi Robert,

   I think I've fixed the problem after your analysis. I've left for the 
time being the special !isUTC case only for dosDate. This at least 
sanitizes the 99% of non-dosDate cases.

Also applied the DumpTMStruct() fix for Mac OS X.

Cheers, Fons.

Robert Hatcher wrote:
> As the original author of TTimeStamp let me give this a try:
> (I hope this makes it to "roottalk" as well as directly ... last attempt
> to send to "roottalk" fell into a black hole).
> 
> On Feb 15, 2008, at 4:51 PM, Chiara Zampolli wrote:
> 
>>    I have some (probably trivial) doubts concerning how to retrieve 
>> timestamps from a given local time. My local time is CET, so what I do 
>> to get the timestamp according to GMT is:
> 
> CET = UTC + 1 hour  -- just checking.
> 
>> [pcalishuttle01] /home/shuttle/Chiara > date
>> Fri Feb 15 23:28:16 CET 2008
>> [pcalishuttle01] /home/shuttle/Chiara > date +%s
>> 1203114501
> 
> A check of the man page of "date" says to check strftime(3):
>      %s    is replaced by the number of seconds since the Epoch,

Re: [ROOT] Re: problem with root 5.18

Hi Again,

[This mail is sent to roottalk <at> cern.ch only - no need to bother the good
people over at debian-science]

On Mon, 2008-03-03 at 09:11 +0100, Antonio Salvucci wrote:
> Hi Christian,
> 
> 		I sent the mail to Debian Science because I think the problem isn't root 
> one, but  about my 64Bit Debian Os.
> In fact the program name.C run without problem on another 32Bit Debian system 
> (my desktop home).
> In my opinion there is a problem with libc6 in my distro.

It's very unlikely that there's a problem in glibc - after all, it's a
core library to the system.   Most likely, it's some sort of word-size
problem in either your code, the data you have, or similar.  F.ex. the
std::string probably contains a size_t variable which is 32bit on a
32bit machine, and 64bit on a 64bit machine (natural size of a word in
the architecture).  So when you stream in/out a std::string object, you
may have an inconsistency across platforms, depending on how CINT treats
the data members.  Loading the appropriate dictionary may cure that
problem. 

> if you write on shell
> 
> dpkg -S /lib/libthread_db.so.1
> 
> dpkg return the package libc6.
> 

[ROOT] Contour