Back Midas Rome Roody Rootana
  Root Display GUI, Page 6 of 7  Not logged in ELOG logo
ID Dateup Author Topic Subject
  116   06 Jun 2006 Konstantin OlchanskiInfoRoody still using CVS
To prevent confusion- according to Joe Chuma and Konstantin Olchanski, we are
still using CVS for Roody development. K.O.
  117   06 Jun 2006 Konstantin OlchanskiBug Fixminor fixes

Konstantin Olchanski wrote:
Minor fixes that escaped quality assurance by previous commiters:
2) have "make clean" remove obsolete stuff from src (src/roody, src/rootsys.h, etc)
3) fix completely nonfunctional enforcement of setting ROOTSYS to the compiled-in value: execv() should have been execvp() (my bug), actually do call setenv("ROOTSYS","blah...") (OS_UNIX was not defined in the Makefile, bug by previous committer).


Restored fixes (2) and (3) that were removed by a careless previous committer.

(Note this assumes windows has "setenv()", which I believe it does have, please test compilation on Windows ASAP and let me know).

K.O.
  118   06 Jun 2006 Konstantin OlchanskiBug Fixminor fixes
> Minor fixes that escaped quality assurance by previous commiters:
> 2) have "make clean" remove obsolete stuff from src (src/roody, src/rootsys.h,
etc)
> 3) fix completely nonfunctional enforcement of setting ROOTSYS to the
compiled-in value: execv() should have been execvp() (my bug), actually do call
setenv("ROOTSYS","blah...") (OS_UNIX was not defined in the Makefile, bug by
previous committer).


(previous message was completely garbled by the Elog "ELCode" whatever it is)


Restored fixes (2) and (3) that were removed by a careless previous committer.

(Note this assumes windows has "setenv()", which I believe it does have, please
test compilation on Windows ASAP and let me know).

K.O.
  119   07 Jun 2006 Joe ChumaBug Fixroody online fixes
Roody has been modified so the resetting of individual histograms should now work. This involved a check for "//" at beginning of path to histogram and remove if it is there.

Also, the properties of the refresh button have been changed. It is enabled when there is a socket connection, and if the refresh rate = 0, button says "refresh now", but if the refresh rate > 0, button toggles refresh on/off (with appropriate labeling).
  120   22 Jun 2006 Joe ChumaBug Fixroody refresh button fix (again)
The refresh button was in the wrong state the first time the user set the refresh rate for online histograms.
  121   21 Aug 2006 Konstantin OlchanskiBug FixBetter zoom & rebin controls, show TDirectory contents
I commited a series of changed to Roody:
- cleanup unused files
- show contents of TDirectory objects (this used to work before, why was it
removed? It was a 1 line fix!)
- rework and simplify controls for zooming and rebinning of TCanvas contents
K.O.
  122   27 Aug 2006 Konstantin OlchanskiInfoNew version coming up...
FYI, I am presently working in an updated version of roody.

The user interface, GUI and user-visible functionality I am leaving alone. The under-the-hood handling of 
histogram data I am reworking using our latest understanding of the workings of ROOT (object ownership, 
etc) and C++ (hey, with STL std::map, C++ is as easy as perl!).

The updated version may also fix some of the existing problems- crashes caused by confused object 
ownership rules, long startup times (current code has to look at every existing histogram before starting- 
slow if many histograms in an online folder) and inability to display TGraph objects (that is what started 
me working on the code).

While at it, we will move the Roody code repository from CVS to SVN.

K.O.
  123   04 Sep 2006 Konstantin OlchanskiInforoody CVS converted to SVN
The ROODY source code repository has been converted from CVS to SVN.

The new command to "get" the sources is:
svn checkout svn://ladd00.triumf.ca/roody/trunk roody

At this time, I do not know how to "convert" a local CVS checkout tree into an SVN checout tree other than 
by brute force (new svn checout, copy modified files from the cvs checout, erase the old cvs checkout 
tree).

For the latest ROODY insructions, please visit http://daq-plone.triumf.ca/SR/ROODY/

K.O.
  124   04 Sep 2006 Konstantin OlchanskiInfoadded "make docs"
I commited the missing images, fixed the doxygen config file and added the "make docs" target. Now 
"make docs" will generate the documentation and place it into the directory "html". K.O.
  125   26 Sep 2006 Konstantin OlchanskiInfoNew version coming up...
> FYI, I am presently working in an updated version of roody.

The new version of Roody has been commited.

It has been tested only on Linux (SL4.3) and while we are shaking out the new bugs,
all are welcome to try it and report any problems. It should not eat your data.

If the new version does not work for you at all, the old version was preserved as
an SVN branch, accessible using this SVN command:
svn checkout svn://ladd00.triumf.ca/roody/branches/roody-v1 roody-v1

K.O.
  128   26 Sep 2006 Konstantin OlchanskiInfoNew version coming up...
> > FYI, I am presently working in an updated version of roody.
> 
> The new version of Roody has been commited.
> 
> It has been tested only on Linux (SL4.3) and while we are shaking out the new bugs,
> all are welcome to try it and report any problems. It should not eat your data.
> 
> If the new version does not work for you at all, the old version was preserved as
> an SVN branch, accessible using this SVN command:
> svn checkout svn://ladd00.triumf.ca/roody/branches/roody-v1 roody-v1

(the email notification for this message did not work at first, trying again)

K.O.
  129   04 Dec 2006 Konstantin OlchanskiBug FixAdd menu for SetOptStat
I commited the implementation for a new menu item: "OptStat". It allows setting
gStyle->SetOptStat in a user-friendly manner. K.O.
  130   16 Nov 2007 John M O'DonnellBug Fixuint32_t or UInt_t
I just downloaded and compiled the latest tarball.

line 98 of DataSourceTNetFolder.h complained about unit32_t.  While I could have
added an include to make this work, I instead changed it to use the ROOT type
UInt_t.

Perhaps this change should be included in the distribution
Attachment 1: DataSourceTNetFolder.h
//
// DataSourceTNetFolder.h
//
// $Id$
//

#include "DataSourceBase.h"

#include "TSocket.h"
#include "TFolder.h"

class DataSourceTNetFolder: public DataSourceBase
{
 private:
  TSocket *fSocket;

 public:
  DataSourceTNetFolder(TSocket* socket) // ctor
    {
      fName = socket->GetName();
      fName += ":";
      char buf[256];
      sprintf(buf, "%d", socket->GetPort());
      fName += buf;
      fSocket = socket;
    }

  ~DataSourceTNetFolder() // dtor
    {
      fSocket = NULL;
    }

  void Close()
    {
      fSocket->Close();
    }

  void Reopen()
    {
      std::string host = fSocket->GetName();
      int         port = fSocket->GetPort();
      fSocket->Close();
      delete fSocket;
      fSocket = new TSocket(host.c_str(), port);
    }

  static TObjArray* ListRemoteObjects(TSocket* sock, const char* foldername)
    {
      size_t p = 0;
      
      {
	std::string str = "GetPointer ";
	str += foldername;
	if (!sock->Send(str.c_str()))
	  return NULL;
	
	TMessage *m = NULL;
	if (!sock->Recv(m))
	  return NULL;
	
	if (!m)
	  return NULL;
	
	*m >> p;
	delete m;
	m = NULL;
      }

      if (!sock->Send("GetListOfFolders"))
	return NULL;

      TMessage m(kMESS_ANY);
      m.Reset();
      m << p;

      if (!sock->Send(m))
	return NULL;

      TMessage *mr = 0;
      if (!sock->Recv(mr))
	return NULL;

      TObjArray *list = NULL;

      if (mr)
	{
	  list = (TObjArray *) mr->ReadObjectAny(mr->GetClass());
	}
      
      delete mr;
      return list;
    }

  static TObject* ReadRemoteObject(TSocket* sock, const char* foldername, const char* objname)
    {
      printf("ReadRemoteObject %s from folder %s\n", objname, foldername);

      UInt_t p = 0;
      
      {
	std::string str = "GetPointer ";
	str += foldername;
	if (!sock->Send(str.c_str()))
	  return NULL;
	
	TMessage *m = NULL;
	if (!sock->Recv(m))
	  return NULL;
	
	if (!m)
	  return NULL;
	
	*m >> p;
	delete m;
	m = NULL;
      }

      printf("Folder %s pointer %d\n", foldername, (int)p);

      {
	std::string str = "FindObject ";
	str += objname;
	if (!sock->Send(str.c_str()))
	  return NULL;

	TMessage m(kMESS_ANY);
	m.Reset();
	m << p;
	if (!sock->Send(m))
	  return NULL;

	TMessage *mr = 0;

	if (!sock->Recv(mr))
	  return NULL;

	TObject *obj = NULL;

	if (mr)
	  {
	    bool adddir = TH1::AddDirectoryStatus();
	    TH1::AddDirectory(false);

	    obj = (TObject*)mr->ReadObjectAny(0);

	    TH1::AddDirectory(adddir);
	  }
	
	delete mr;
	return obj;
      }
    }

  static void ExecuteRemoteCommand(TSocket* socket, const char *line)
    {
      if (!socket->IsValid())
	return;
      
      // The line is executed by the CINT of the server
      socket->Send("Execute");
      socket->Send(line);
    }

  void EnumerateTFolder(ObjectList* list, TFolder* f, ObjectPath path)
  {
    TIterator   *iterator = f->GetListOfFolders()->MakeIterator();
    while (1)
      {
	TNamed *obj = (TNamed*)iterator->Next();
	if (obj == NULL)
	  break;

	const char* classname = obj->ClassName();
	const char* name      = obj->GetName();

	if (strcmp(classname,"TFolder") == 0)
	  {
	    TFolder* f = (TFolder*)obj;
	    ObjectPath p = path;
	    p.push_back(name);
	    EnumerateTFolder(list, f, p);
	  }
	//else if (strcmp(classname,"TDirectory") == 0)
	//  {
	//    TDirectory* d = (TDirectory*)obj;
	//    ObjectPath p = path;
	//    p.push_back(name);
	//    EnumerateTDirectory(list, d, p);
	//  }
	else
	  {
	    ObjectPath p = path;
	    std::string s;
	    s += name;
	    //s += "(";
	    //s += classname;
	    //s += ")";
	    p.push_back(s);
	    list->push_back(p);
	  }
      }
  }

  TFolder* ReadFolder(const char* foldername, ObjectPath path, const char* name)
    {
      TObject* obj = ReadRemoteObject(fSocket, foldername, name);
      if (!obj)
	return NULL;

      if (obj->InheritsFrom(TFolder::Class()))
	return (TFolder*)obj;

      ObjectPath p = path;
      p.push_back(name);

      return NULL;
    }

  void Enumerate(ObjectList* list, const char* foldername, ObjectPath path)
  {
    TCollection *contents = ListRemoteObjects(fSocket, foldername);
    if (!contents)
      return;
    TIterator   *iterator = contents->MakeIterator();
    while (1)
      {
	TNamed *obj = (TNamed*)iterator->Next();
	if (obj == NULL)
	  break;

	const char* classname = obj->ClassName();
	const char* name      = obj->GetName();

	if (strcmp(classname,"TObjString") == 0)
	  {
	    TObject* xobj = ReadRemoteObject(fSocket, foldername, name);
	    if (!xobj)
	      continue;
	    
	    if (xobj->InheritsFrom(TFolder::Class()))
	      {
		TFolder *fff = (TFolder*)xobj;
		ObjectPath p = path;
		p.push_back(name);
		EnumerateTFolder(list, fff, p);
		continue;
	      }
	  }

	ObjectPath p = path;
	std::string s;
	s += name;
	//s += "(";
	//s += classname;
	//s += ")";
	p.push_back(s);
	list->push_back(p);
      }
  }

  ObjectList GetList()
  {
    ObjectList list;
    ObjectPath path;
    path.push_back(fName);
    char *topfolder = "histos";
    path.push_back(topfolder);
    Enumerate(&list, topfolder, path);
    return list;
  }

  TObject* GetObject(const ObjectPath& path)
    {
      //gDirectory->pwd();
      //gDirectory->ls();
      
      const char *name = path.back().c_str();
      printf("Get object %s from %s\n", name, fName.c_str());

      const char *foldername = path[path.size()-2].c_str();

      TObject* obj = ReadRemoteObject(fSocket, foldername, name);

      return obj;
    }

  void ResetAll()
  {
    printf("ResetAll %s\n", fName.c_str());

    ExecuteRemoteCommand(fSocket, "gAnalyzer->ResetAllHistos()");
  }

  void ResetObject(const ObjectPath& path)
  {
    printf("ResetObject %s\n", path.toString().c_str());

    std::string name = path.back();

    std::string s;
... 17 more lines ...
  131   16 Nov 2007 Konstantin OlchanskiBug Fixuint32_t or UInt_t
> I just downloaded and compiled the latest tarball.
> 
> line 98 of DataSourceTNetFolder.h complained about unit32_t.  While I could have
> added an include to make this work, I instead changed it to use the ROOT type
> UInt_t.

Uint_t is technically incorrect. The data returned from the socket connection is a
32-bit pointer to an object in the remote process (how do they come up with
communication protocols like this?!?). The type "Uint_t" is not defined to be of any
particular size and is not necessarily big enough to hold a 32-bit unsigned integer.

According to the "C99" standard, the correct C data type for 32-bit unsigned
integers is uint32_t, defined in "#include <stdint.h>", e.g. see
http://www.oreillynet.com/pub/a/network/2003/10/07/michael_barr.html

I have now added the missing "#include <stdint.h>" statement to
DataSourceTNetFolder.h, commited as revision 230.

I am puzzled why the code compiled without this include statement, possibly on my
SL4.3 machine with ROOT v5.16.00, some ROOT or system header file included it for
me. I am curious what system you use where this code failed to compile?

K.O.
  132   19 Nov 2007 John M O'DonnellBug Fixuint32_t or UInt_t
I'm using Redhat workstation with:
  gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
  ROOT version 5.16/00

it is unlikely that UInt_t will ever be too small.  If it is too small, then ROOT will
break!  It is clearly intended to be 32 bits long.  From Rtypes.h:

#ifdef R__INT16
typedef long           Int_t;       //Signed integer 4 bytes
typedef unsigned long  UInt_t;      //Unsigned integer 4 bytes
#else
typedef int            Int_t;       //Signed integer 4 bytes (int)
typedef unsigned int   UInt_t;      //Unsigned integer 4 bytes (unsigned int)
#endif

Of course, stdint.h is defined in a standard.  However ROOT doesn't really try to follow
the standard (CINT compiles a language similar to C++, but not exactly C++), and indeed
the file stdint.h is not explicitly included in any of $ROOTSYS/include/*.h.

John.

> > I just downloaded and compiled the latest tarball.
> > 
> > line 98 of DataSourceTNetFolder.h complained about unit32_t.  While I could have
> > added an include to make this work, I instead changed it to use the ROOT type
> > UInt_t.
> 
> Uint_t is technically incorrect. The data returned from the socket connection is a
> 32-bit pointer to an object in the remote process (how do they come up with
> communication protocols like this?!?). The type "Uint_t" is not defined to be of any
> particular size and is not necessarily big enough to hold a 32-bit unsigned integer.
> 
> According to the "C99" standard, the correct C data type for 32-bit unsigned
> integers is uint32_t, defined in "#include <stdint.h>", e.g. see
> http://www.oreillynet.com/pub/a/network/2003/10/07/michael_barr.html
> 
> I have now added the missing "#include <stdint.h>" statement to
> DataSourceTNetFolder.h, commited as revision 230.
> 
> I am puzzled why the code compiled without this include statement, possibly on my
> SL4.3 machine with ROOT v5.16.00, some ROOT or system header file included it for
> me. I am curious what system you use where this code failed to compile?
> 
> K.O.
  133   18 Feb 2008 Jimmy NgaiBug ReportRoody kills MIDAS Analyzer
Hi All,

I'm running Roody with MIDAS 2.0.0 and ROOT 5.14e on Scientific Linux 4.4. 
When Roody is monitoring the online histograms on Localhost, there are two 
possibilities that Roody will kill the MIDAS Analyzer: 
1) quiting Roody
2) unzoom a histogram when auto-refresh is on

Any ideas?

Best Regards,
Jimmy
  134   02 Mar 2008 Exaos LeeBug ReportROODY kills analyzer too!!
I compiled roody svn231 with ROOT 5.18.00 and gcc 4.1 on Debain Linux 4.0 (AMD64).
I tested the roody with the "examples/experiment" in MIDAS svn4124 and
encountered the following error:
Error in <TFile::TFile>: file /last.root does not exist

 *** Break *** segmentation violation

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 1090525536 (LWP 17985)]
 0x00000000004114e6 in root_server_thread (arg=<value optimized out>) at src/mana.c:5333
 Current language:  auto; currently c++
 (gdb) next
 [midas.c:2416:bm_validate_client_index,ERROR] Invalid client index 1 in buffer 'SYSMSG'. Client name '', pid 0 should be 17973
 0x00002b800b8a5460 in sighandler () from /opt/ROOT/Versions/Current/lib/libCore.so.5.18
 (gdb) next
 Single stepping until exit from function _Z10sighandleri, 
 which has no line number information.
 Cannot remove breakpoints because program is no longer writable.
 It might be running in another process.
 Further execution is probably impossible.
 0x00002b800b8a546e in sighandler () from /opt/ROOT/Versions/Current/lib/libCore.so.5.18
 ptrace: &#23052;&#8451;&#28225;&#38317;&#65348;&#37340;&#26473;&#28058;&#9660;.
 (gdb) next
 Single stepping until exit from function _Z10sighandleri, 
 which has no line number information.
 Cannot remove breakpoints because program is no longer writable.
 It might be running in another process.
 Further execution is probably impossible.
 0x00002b800b8a546e in sighandler () from /opt/ROOT/Versions/Current/lib/libCore.so.5.18
 ptrace: &#23052;&#8451;&#28225;&#38317;&#65348;&#37340;&#26473;&#28058;&#9660;.
 (gdb) next
 Single stepping until exit from function _Z10sighandleri, 
 which has no line number information.
 Cannot remove breakpoints because program is no longer writable.
 It might be running in another process.
 Further execution is probably impossible.
 0x00002b800b8a546e in sighandler () from /opt/ROOT/Versions/Current/lib/libCore.so.5.18

The system information is as the following:
$ uname -a
Linux daq-heg 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v 
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release 
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

$ root-config --config
linuxx8664gcc --prefix=/opt/ROOT/Versions/5.18.00-gcc 
--datadir=/opt/ROOT/Versions/5.18.00-gcc/share 
--docdir=/opt/ROOT/Versions/5.18.00-gcc/doc 
--incdir=/opt/ROOT/Versions/5.18.00-gcc/include 
--libdir=/opt/ROOT/Versions/5.18.00-gcc/lib 
--etcdir=/opt/ROOT/Versions/5.18.00-gcc/etc 
--elispdir=/opt/ROOT/Versions/5.18.00-gcc/share/emacs/site-lisp --enable-cern 
--with-cern-libdir=/usr/lib --enable-fftw3 --enable-gdml --enable-mathcore 
--enable-mathmore --enable-opengl --enable-python --enable-qt --enable-roofit 
--enable-ruby --enable-shared --enable-soversion --enable-ssl --enable-xml 
--enable-xft --enable-xrootd --enable-g4root 
--with-g4-incdir=/opt/GEANT4/Versions/9.0.p01/include 
--with-g4-libdir=/opt/GEANT4/Versions/9.0.p01/lib/Linux-g++

Any idea to fix this problem?
  135   03 Mar 2008 Randolf PohlBug ReportROODY kills analyzer too!!
Hi,

I had the very same problem last summer during our beam time. Don't know the revision, but it was the tarball I downloaded around mid-July.
Symptom: The MIDAS (online) analyzer crashed as soon as roody was started. Started, i.e. before any user interaction became even possible. And the crash happened always. 100.0%.

My workaround was: Use roody rev. 220.
No crashes, beam time saved.

I attach 2 outputs I saved at that time.

Oh, yes: I still have the sources and such. Last modified date is July 9 and earlier (see attachment 3). I can send them around if you want to find the revision and bracket the offending commits. (I wish you were using "git". Ever read about git-bisect?)

Cheers,

Randolf

PS: Konstantin, I had promised you to try and pin down the problem after the run. Obviously I forgot, sorry. Please tell me if I can be of any help now.
Attachment 1: crash-analyzer.txt
Lamb_be>./bin/analyzer -e lamb07
Connect to experiment lamb07...OK
Loading previous online histos from /data/lamb/2007/data/last.root
Root server listening on port 9090...
Running analyzer online. Stop with "!"

 *** Break *** segmentation violation
Using host libthread_db library "/lib64/libthread_db.so.1".
Attaching to program: /proc/2785/exe, process 2785
[Thread debugging using libthread_db enabled]
[New Thread 46971434529216 (LWP 2785)]
[New Thread 1090525504 (LWP 2789)]
[New Thread 1082132800 (LWP 2786)]
0x00002ab8635f5302 in __select_nocancel () from /lib64/libc.so.6
Thread 3 (Thread 1082132800 (LWP 2786)):
#0  0x00002ab85ecde0ab in __accept_nocancel () from /lib64/libpthread.so.0
#1  0x00002ab85f82d510 in TUnixSystem::AcceptConnection ()
   from /usr/local/root/lib/root/libCore.so.5.14
#2  0x00002ab85f822592 in TServerSocket::Accept ()
   from /usr/local/root/lib/root/libCore.so.5.14
#3  0x000000000041a9ff in root_socket_server (arg=<value optimized out>)
    at src/mana.c:5454
#4  0x00002ab862df728a in TThread::Function ()
   from /usr/local/root/lib/root/libThread.so.5.14
#5  0x00002ab85ecd709e in start_thread () from /lib64/libpthread.so.0
#6  0x00002ab8635fb4cd in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 2 (Thread 1090525504 (LWP 2789)):
#0  0x00002ab8635cce1f in waitpid () from /lib64/libc.so.6
#1  0x00002ab863575491 in do_system () from /lib64/libc.so.6
#2  0x00002ab863575817 in system () from /lib64/libc.so.6
#3  0x00002ab85f831851 in TUnixSystem::StackTrace ()
   from /usr/local/root/lib/root/libCore.so.5.14
#4  0x00002ab85f830a4a in TUnixSystem::DispatchSignals ()
   from /usr/local/root/lib/root/libCore.so.5.14
#5  <signal handler called>
#6  0x000000000041b339 in root_server_thread (arg=<value optimized out>)
    at src/mana.c:5333
#7  0x00002ab862df728a in TThread::Function ()
   from /usr/local/root/lib/root/libThread.so.5.14
#8  0x00002ab85ecd709e in start_thread () from /lib64/libpthread.so.0
#9  0x00002ab8635fb4cd in clone () from /lib64/libc.so.6
#10 0x0000000000000000 in ?? ()

Thread 1 (Thread 46971434529216 (LWP 2785)):
#0  0x00002ab8635f5302 in __select_nocancel () from /lib64/libc.so.6
#1  0x00000000004449e7 in ss_suspend (millisec=1000, msg=0)
    at src/system.c:3285
#2  0x000000000043acf3 in cm_yield (millisec=1000) at src/midas.c:3607
#3  0x000000000041afea in loop_online () at src/mana.c:3785
#4  0x000000000041dfba in main (argc=<value optimized out>, 
    argv=<value optimized out>) at src/mana.c:5756
#0  0x00002ab8635f5302 in __select_nocancel () from /lib64/libc.so.6
[midas.c:1592:] cm_disconnect_experiment not called at end of program
Lamb_be>
Attachment 2: crash-roody.txt
Lamb_be>roody -h localhost
main.cxx: Re-executing 'roody' with compiled-in ROOTSYS='/usr/local/root'
SetOptStat("nemri") got 1001111
Unable to open file "default.xml": No such file or directory
ReadRemoteObject trig_start from folder histos
Folder histos pointer 0
ReadRemoteObject trig_pattern from folder histos
ReadRemoteObject trig_tdc from folder histos
SysError in <TUnixSystem::UnixSend>: send (Broken pipe)
ReadRemoteObject trig_adc from folder histos
ReadRemoteObject trig_detector from folder histos
ReadRemoteObject trig_fadc from folder histos
ReadRemoteObject trig_cool from folder histos
ReadRemoteObject trig_display from folder histos
ReadRemoteObject lambdameter from folder histos
Attachment 3: roody-tarball-dir.txt
Lamb_be>l include/
total 68
-rw-r--r-- 1 root root  815 Sep 27  2006 CanvasLimits.h
-rw-r--r-- 1 root root 1453 Sep 27  2006 DataSourceBase.h
-rw-r--r-- 1 root root  833 Jul  9  2007 DataSourceNetDirectory.h
-rw-r--r-- 1 root root  683 Oct  7  2006 DataSourceTDirectory.h
-rw-r--r-- 1 root root 6016 Jul  8  2007 DataSourceTNetFolder.h
-rw-r--r-- 1 root root 1091 Jul  9  2007 MTGListTree.h
-rw-r--r-- 1 root root 7068 Jul  9  2007 Roody.h
-rw-r--r-- 1 root root 1112 Sep 27  2006 RoodyXML.h
-rw-r--r-- 1 root root 1883 Dec  5  2006 TAxisLimitsDialog.h
-rw-r--r-- 1 root root 1664 Sep 27  2006 TGTextDialog.h
-rw-r--r-- 1 root root 2519 Sep 27  2006 TPeakFindPanel.h
-rw-r--r-- 1 root root 4599 Sep 27  2006 mxml.h
-rw-r--r-- 1 root root   41 Jul 30  2007 rootsys.h
-rw-r--r-- 1 root root  558 Sep 27  2006 strlcpy.h
Lamb_be>l src/*.c*
-rw-r--r-- 1 root root    18 Aug 21  2006 src/.cvsignore
-rw-r--r-- 1 root root  4064 Jul  9  2007 src/DataSourceTDirectory.cxx
-rw-r--r-- 1 root root  5222 Jul  9  2007 src/MTGListTree.cxx
-rw-r--r-- 1 root root 75044 Jul  9  2007 src/Roody.cxx
-rw-r--r-- 1 root root  3587 Sep 27  2006 src/RoodyXML.cxx
-rw-r--r-- 1 root root  6798 Dec  5  2006 src/TAxisLimitsDialog.cxx
-rw-r--r-- 1 root root  4949 Sep 27  2006 src/TGTextDialog.cxx
-rw-r--r-- 1 root root 22120 Jul 25  2007 src/TPeakFindPanel.cxx
-rw-r--r-- 1 root root 22097 Sep 27  2006 src/TPeakFindPanel.cxx~
-rw-r--r-- 1 root root  3552 Jul  9  2007 src/main.cxx
-rw-r--r-- 1 root root 62288 Sep 27  2006 src/mxml.c
-rw-r--r-- 1 root root  2120 Sep 27  2006 src/strlcpy.c

  137   04 Mar 2008 Exaos LeeBug ReportRevision 221 works! But not remotely.
I recompiled the roody of revision 221 and found this revision works. But when I run roody remotely, it still keeps killing the analyzer 100%. Frown

Hope somebody can fix it.
  138   07 Mar 2008 Randolf PohlBug ReportRevision 221 works! But not remotely.
Hi,


Exaos Lee wrote:
I recompiled the roody of revision 221 and found this revision works. But when I run roody remotely, it still keeps killing the analyzer 100%. Frown


We used 220 (not 221) successfully, but only locally.
Now that you say it I think I recall I could not get roody to run remotely. Don't remember the exact reasons, though.
What I did then was to "ssh -X" from the remote machine into the backend and start roody there (Actually a button with a beautiful picture enabled the users to do so).

Just an idea: Are all necessary ports open on the receiving machine? Maybe the analyzer is just collateral damage, in reality roody commits suicide because the firewall is nasty to him?

I don't have my machines set up at the moment. One of the machines stayed in a box at PSI. So I can't really help you, I am sorry. I think it's time for the specialists now. Anybody there???!?! Smile

Good luck,

Randolf
ELOG V3.1.4-2e1708b5