Errors: Running
This problem has made it into
RootTalk
on more than one occasion! It
can happen if you have not loaded iostream.h, see
First Steps: Typing in C++.
Doing:-<![CDATA[
{
#include <iostream.h>
gROOT->Reset();
...etc...
}
]]>
doesn't work as the Reset() clears the stack and looses the
the definitions in the header.
Doing:-<![CDATA[
{
gROOT -> Reset();
#include <iostream.h>
...etc...
}
]]>
isn't much better. It works the first time but gives the error:-<![CDATA[
Warning: File "iostream.h" already loaded
]]>
after that even though the definitions get wiped. Far better to put:-
<![CDATA[
{
G__loadfile("iostream.h");
}
]]>
in rootlogon.C.
Check the following:-
- You have misspelt the member function name (if CINT doesn't understand
the class name you get the No symbol Class in current scope message).
- CINT cannot find a member function that matches, in type and number
or arguments, those you have supplied. Remember that member functions can be
overloaded
i.e. there can be several member functions with the same name but with
different argument lists. Supplied arguments don't have to be an exact
match, for example an integer arg can be converted into a floating point,
but there are limits. So check the documentaion, or the code, to see what
argument lists are permitted.
- If calling user classes that:-
- The ClassDef and ClassImp macros were correctly inserted in the
header and implementation files.
- The dictionary was correctly generated using rootcint with
a LinkDef.h file specifies loading of the class globals.
This can be produced if the libraries listed on the link line are
not in the right order. The linker may be smart enough to find all
the symbols it needs but ROOT may not. ROOT, when building class definition data
during execution, loads dictionary data in strict reverse order
to the way the libraries appear on the load line. That way lower level class
information is available to the system when building class definitions
that depend on them. Getting the order wrong
may mean that the system fails to find a class definition and prints an
error.
With shared libraries, sections of the executable are not loaded until required.
Normally any potential unresolved symbol is identified at load time but
in exceptional cases, for example virtual destructors to abstract classes,
errors can occur during execution. To resolve see
Unresolved Global Symbols in Shared Libraries.
A failure in malloc while trying to allocate memory strongly suggest a
memory leak. Here are a few
common mistakes that can lead to leaks:-
A common source of memory leaks is deleting only the first element
of an array allocated on the heap. The incorrect code looks like:
Type* ptr = new Type [nelements];
...
delete ptr;
When instead the second of those lines should be:
delete [] ptr;
Using a local i.e.
stack
pointer when creating a
heap
object can lead to trouble. Consider this code snippet:-
{
...
MyClass* myObj = new MyClass(...);
...
}
At the end of the code block the local pointer myObj goes
out of scope and is deleted. Unless the object it pointed
to has already been deleted or has been pointed to by
another pointer that survives, the memory allocated to
the object is lost.
This usually means that you need to regenerate some dictionary file.
To remake all these files in a test release:-
cd $SRT_PRIVATE_CONTEXT/
\rm `find tmp -name "*Cint.*"`
gmake all
If really necessary all the dictionaries in a Base Release can be
regenerate in a similar way.
Go Back to the
The Errors Top Page
Contact:
Nick West (n.west1@physics.oxford.ac.uk>)