TSTring, memory problem

ROOT
1

Dear ROOT (and C++) experts,

I have a crashing program, it crahses seemingly at random places. This usually means that something with the memory is not in order and I got suspicious about my use of the string (not the TString, just string).

I have for example the lines:

string Label_sys[fnSysDirs];
for (Int_t i = 0; i < 2; ++i) {

if (i == 0) { Label_sys[i] = "TRIGGER UP"; };
if (i == 1) { Label_sys[i] = "TRIGGER DN"; };

};

I suspect the next: the definition of Label_sys[fnSysDirs] does not allocate more memory than the default constructer string(). Then, in the for-loop, I assign the (temporary!) stack-entities to Label_sys[0] and Label_sys[1] which can result in the crash because I might now be over-writing the allocated space (I’m not sure here).

My question: Is that assumption right and does using TString solve this (I might use realloc if needed?).

Cheers,

Ytsen.

PS. I ofcourse tried to change this line in to:

TString Label_sys[fnSysDirs];

but then my program crashes at another spot. I would like to know if the above is a mistake, then I will make the effort of changing this in the whole of my program. I hesitate to change my program as long as I am not sure of a mistake since the program runs fine with different input (different histograms from the same file which are otherwise as well acceptable).

2

Hi,

string literals are not part of the stack; your code should work just fine. You should try to run your program with valgrind, which will report several kinds of memory corruption and where they occurs. See valgrind.org.

Cheers, Axel.

3

I do not understand, what you are talking about temporaries and stack objects here, let me show small example:

//sketch

class String {
private:
   char *mem_;
public:
   String():mem_(0){}
   ~String(){delete []mem;}
   
   String &operator = (const String &rhs)
   {
    ///bla-bla-bla
     return *this;
   }
   String &operator = (const char *src)
   {
      //allocate memory
      //copy  data, pointed by src

      return *this;
   }
};


int main()
{
    String arr[10];//1,2
    for(int i = 0; i < 10; ++i) {
       arr[i] = "a";//3
    }

}
  1. Appropriate for this array amount of memory will be allocated on a stack
  2. Ctors will be called for array’s elements.
  3. String::operator=(const char *) will be called.

This is not a place where you have a problem. IMHO - you’d better stop guessing and give us small example of code, which can reproduce the problem.

4

That’s the problem, I can’t pin-point the problem. With a different input it runs fine but I don’t think the input can be the problem (just another histogram, histograms are all fine as I checked by hand). Must be a memory thing somewhere.

Thanks for your time guys, I’ll have a look at valgrind.org,

cheers,

Ytsen.

5

[quote]That’s the problem, I can’t pin-point the problem.
Ytsen.[/quote]

Yes, if you can find such part of code, you can fix your problem yourself :slight_smile:

BTW valgrind is not the best idea. You’d better use method of bisections :slight_smile:
Select input, which can reproduce your problem, comment parts of code - etc. - such errors are very easy to find.

6

Hi,

[quote=“tpochep”]BTW valgrind is not the best idea. You’d better use method of bisections :slight_smile:
Select input, which can reproduce your problem, comment parts of code - etc. - such errors are very easy to find.[/quote]
I completely disagree. Valgrind takes out the randomness of uninitialized values, which you’ll still have with bisection. These problems often suffer from the lack of reproducability; often there is no “input which can reproduce” a problem. And contrary to bisection there’s no need to recompile code with valgrind.

Axel.

7

Okay, I accidentally found the problem, and it was a stupid STUPID [size = SizeOfScreen * 100 and blinking angrily] VERY STUPID [/end size] thing.

Sorry for wasting your time guys!

8

[quote]I completely disagree. Valgrind takes out the randomness of uninitialized values, which you’ll still have with bisection. These problems often suffer from the lack of reproducability; often there is no “input which can reproduce” a problem. And contrary to bisection there’s no need to recompile code with valgrind.
Axel.[/quote]

He said, he has an input with which he can reproduce. I guess, he has a big main function. He can comment most part of it and uncomment more and more - it’s like a quick sort :slight_smile: you’ll simply and fast will find an error :slight_smile:

With valgrind you have to:

download.
compile+install.
RTF - because valgrind is useless if you do not know what this several hundred lines of diagnostic messages mean.