Orbit > OTG > Debug Notes

Steps to debugging OTG on Sandbox without collection server support

1. install libstdc++6 library in the nodes, which is compatiable with the setting in internal4.

   apt-get update
   apt-get -o APT::Force-LoopBreak=true install libstdc++6
   

2. If there is no /usr/local/lib/oml2 directory in the node, copy all the files under internal4:/usr/local/lib/oml2/ to the /usr/local/lib/oml2 of the grid nodes.
3. copy "otg-oml-sample.xml" into sender and set LD_LIBRARY_PATH

   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./:/usr/local/lib:/usr/local/lib/oml2
   

4. OML_CONFIG,OML_NAME can be set by export OML_CONFIG="./otg-oml-sample.xml" and export OML_NAME="Node-1" or in otg command line

   ./otg --dsthostname=internal2 --protocol=udp --oml-name "foo" --oml-config "../etc/otg-oml-sample.xml"
   

5. Similarly, copy and set "otr-oml-sample.xml" in receiving node

   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./:/usr/local/lib:/usr/local/lib/oml2
   export OML_CONFIG="./otr-oml-sample.xml"
   export OML_NAME="Node-2"
   

Handling "non-virtual destructor" warning message with Gcc 4.0

By default, if destructor is not specified, its non-virtual, but for every class derived from a virutal base class, the destructor have to be virtual.

In particular, here's when you need to make your destructor virtual:

• if someone will derive from your class,
• and if someone will say new Derived, where Derived is derived from your class,
• and if someone will say delete p, where the actual object's type is Derived but the pointer p's type is your class.

Confused? Here's a simplified rule of thumb that usually protects you and usually doesn't cost you anything: make your destructor virtual if your class has any virtual functions. Rationale:

• that usually protects you because most base classes have at least one virtual function.
• that usually doesn't cost you anything because there is no added per-object space-cost for the second or subsequent virtual in your class. In other words, you've already paid all the per-object space-cost that you'll ever pay once you add the first virtual function, so the virtual destructor doesn't add any additional per-object space cost. (Everything in this bullet is theoretically compiler-specific, but in practice it will be valid on almost all compilers.)

Note: if your base class has a virtual destructor, then your destructor is automatically virtual. You might need an explicit destructor for other reasons, but there's no need to redeclare a destructor simply to make sure it is virtual. No matter whether you declare it with the virtual keyword, declare it without the virtual keyword, or don't declare it at all, it's still virtual.

Fix is easy: Just add virtual destructor in base class:

public:
virtual ~Foo(){}

Using the external "C" Linkage Specification

calling C functions (LIBMAC) in C++ code (OTG),Solution is :

extern "C" {
#include <libmac/libmac.h>
}

To handle overloaded function names the HP C++ compiler generates new, unique names for all functions declared in a C++ program. To do so, the compiler uses a function-name encoding scheme that is implementation dependent. A linkage directive tells the compiler to inhibit this default encoding of a function name for a particular function.

If you want to call a C function from a C++ program, you must tell the compiler not to use its usual encoding scheme when you declare the C function. In other words, you must tell the compiler not to generate a new name for the function. If you don't turn off the usual encoding scheme, the function name declared in your C++ program won't match the function name in your C module defining the function. If the names don't match, the linker cannot resolve them. To avoid these linkage problems, use a linkage directive when you declare the C function in the C++ program.

Make OTG Software without working client_wrapper libraries

First, get a source package of otg in the node. then prepare additional files. Use w-get to fetch .h .cpp and .a files. As those lib files (.a) cannot be used for some reason, we need manually build them in the node.

  cd otg/src/cpp
  make otg;make otr; make otf
  cp ../../build/include/* ./
  cp ../../build/src/* ./

Get new OML client libraries

scp zhibinwu@external1:tmp/oml_libraries/* /usr/local/lib/oml2

Get oml header files

mkdir oml
scp zhibinwu@external1:tmp/oml/* ./

After this, see

node1-1:~/otg/src/cpp/oml# ls
Metric.h  MetricAggregator.h  OmlContext.h  OmlFilter.h  OmlQueueItem.h  oml.h  oml_def.h  oml_tx.h

Change Makefile
adding new include

         CFLAGS  = -g -Wall -I$(INC_DIR)  -I. -Iauto -I/usr/local/include/scew -Ioml/

adding new sourcecode files

OTG_SRCS = ....
    ...orbit_winlab_otg.cpp
...
...

remove the -l$(OT?_OML_LIB) in each target see:
change from

$(CC) -o $@ $(OTG_OBJS) $(LDFLAGS) $(LIBS) -l$(OTG_OML_LIB)

to

$(CC) -o $@ $(OTG_OBJS) $(LDFLAGS) $(LIBS)

At last,

make clean
make

Another way to use nodehandler

cd tmp
svn co http://svn.orbit-lab.org/svn/orbit/nodeHandler/trunk nodehandler
cd ~/tmp/nodehandler/src/ruby
ruby handler/nodeHandler.rb ~/rate_loop_exp

And the nodehandler will use the otg definition files (otg.rb) in this tmp/nodehandler/src/repository directory