string assignment crash

[aryan1]

Hi All,

I have the following class declaration from which other classes are derived:

	class A
	{
	public:
		A();
		virtual ~A(){}
                void function1(const char* fileName1,
						       const char* fileName2,
						       string _folderPath1,
						       string _folderPath2 = "");
	protected:
		string s1;
		string s2;
	};

where

string _folderPath2

argument in member function1() has a default value.

In the body of A::function1(const char* fileName1,
const char* fileName2,
string _folderPath1,
string _folderPath2),

  s1 = _folderPath1; //this line does not crash
  if(_folderPath2 != "")
  {
     s2 = _folderPath2; //this line crashes
  }

In the code fragment above, as you can see, both s1 and s2 are protected members whose values are used by the derived classes. However, the line which assigns _folderPath1 to s1 does not crash whereas the one which assigns _folderPath2 to s2 crashes.

To me, this seems to be a problem concerning s2 itself. But, I don 't know why.

If you think that further information is needed to isolate the problem, please let me know (I can not list all my source code here since it is long)

Any help will be appreciated.

Thanks.

[Paul McKenzie]

(I can not list all my source code here since it is long)

Which is probably why your program crashes. It is the code you're not showing us that is causing the problem.

The code you're showing has no problems with it. Crashes are runtime issues, where the program is in a certain state due to bad data the program is using plus bad programming. This means that we would need to see the program and what data you're using when running the program.

You have probably corrupted memory in some way, and without all of the code, we can't tell you where.

Regards,

Paul McKenzie

[Lindley]

If you have access to it, run your program through valgrind. That should help you identify where you're trashing that string.

[kempofighter]

There are so many problems that could cause the program to crash at a seemingly benign line of source code that they are too many too list. Perhaps the object in question was deleted and you are invoking a function with a dangling pointer to a deleted object? That would be one of many problems that might result in the software crashing at a line of code that seems reasonable. As Paul has pointed out, we need to see a program that demonstrates the problem. The class code itself doesn't appear to be the problem. It must be something with the code that manages those objects. I don't really see how you could mess up a string such that an assignment would fail since those string objects manage themselves and can only be updated through their interface. however the strings use heap memory so if it is a dangling pointer problem with the object instance it would make perfect sense for the code to crash during the string assignment. But again, that is just one of many other run-time problems that could exist.

The process of creating a small program that uses the class in question might help you solve the problem before posting. First it would prove to you that there is nothing wrong with the class itself or you might find a problem with the class itself. If the former is true, then you would start looking at the code that uses the class so that you could try and update your example to simulate what the real application is doing with the object instances. Just make a test project and build that class along with some simple main function that builds some objects and calls functions on them and see what happens.

[aryan1]

I totally understand that you can not tell anything specific without seeing the source code itself.

However, I will follow the guidelines you all provided to isolate and resolve the problem.

By the way, I got the exactly same code to run on two other machines, but not the one where the problem occurs.

Might the problem be stemming from the OS installation ? Is it possible ? Or May "undefined behaviour" or some kind of memory leak still cause the problem ?

The machine where the problem occurs has a much better system configuration (memory, CPU, etc) than the others where I got the same code to run successfully ...

There are so many problems that could cause the program to crash at a seemingly benign line of source code that they are too many too list. Perhaps the object in question was deleted and you are invoking a function with a dangling pointer to a deleted object? That would be one of many problems that might result in the software crashing at a line of code that seems reasonable. As Paul has pointed out, we need to see a program that demonstrates the problem. The class code itself doesn't appear to be the problem. It must be something with the code that manages those objects. I don't really see how you could mess up a string such that an assignment would fail since those string objects manage themselves and can only be updated through their interface. however the strings use heap memory so if it is a dangling pointer problem with the object instance it would make perfect sense for the code to crash during the string assignment. But again, that is just one of many other run-time problems that could exist.

The process of creating a small program that uses the class in question might help you solve the problem before posting. First it would prove to you that there is nothing wrong with the class itself or you might find a problem with the class itself. If the former is true, then you would start looking at the code that uses the class so that you could try and update your example to simulate what the real application is doing with the object instances. Just make a test project and build that class along with some simple main function that builds some objects and calls functions on them and see what happens.

[Paul McKenzie]

By the way, I got the exactly same code to run on two other machines, but not the one where the problem occurs.

Doesn't really mean anything. A program that has bugs can seem to "work" on one system, and crash on another.

Might the problem be stemming from the OS installation ? Is it possible ? Or May "undefined behaviour" or some kind of memory leak still cause the problem ?

The issue is with your code -- never blame the OS or some other "outside force", unless you have documented proof that it is something with the compiler.

Since you don't show any code, no one can help you any further except to tell you to "debug more thoroughly".

The process of creating a small program that uses the class in question might help you solve the problem before posting.

Did you do this? I can easily make your class do all sorts of wrong things, For example, what exactly do you do with those "filename" pointers? What if NULL is passed to your constructor for these pointers? At the very least, show us something that uses the class.

Regards,

Paul McKenzie

[kempofighter]

I totally understand that you can not tell anything specific without seeing the source code itself.

However, I will follow the guidelines you all provided to isolate and resolve the problem.

By the way, I got the exactly same code to run on two other machines, but not the one where the problem occurs.

Might the problem be stemming from the OS installation ? Is it possible ? Or May "undefined behaviour" or some kind of memory leak still cause the problem ?

The machine where the problem occurs has a much better system configuration (memory, CPU, etc) than the others where I got the same code to run successfully ...

I'm betting on undefined behavior. I've seen some strange things in my life where a program with serious defects "appeared" to be working for many months and then one day for no evident reason it began to crash even on the same system that it had always executed on. In one instance, there was a spot where an uninitialized pointer was used to call functions and how it worked for months is beyond me. I was baffled by that one. In other instances I have seen where a pointer to a deleted object can be used to continue making function calls for some short time after the object is deleted. these kinds of problems are very difficult to find. Sometimes you have a race condition where it appears to work with one setup but not on another or it works for a while until something that seems unrelated is changed in the program and then you wonder why something else starts crashing. Welcome to C++ programming. Nothing surprises me any longer.

[aryan1]

Doesn't really mean anything. A program that has bugs can seem to "work" on one system, and crash on another.
The issue is with your code -- never blame the OS or some other "outside force", unless you have documented proof that it is something with the compiler.

Since you don't show any code, no one can help you any further except to tell you to "debug more thoroughly".
Did you do this? I can easily make your class do all sorts of wrong things, For example, what exactly do you do with those "filename" pointers? What if NULL is passed to your constructor for these pointers? At the very least, show us something that uses the class.

Regards,

Paul McKenzie

My intention was not to blame the OS or underlying hardware.

The class which caused problems has been used by other processes for a while without any "observable" problems; at least, they appeared to be producing expected results.

Since I am relatively new in C++ programming, all your suggestions as an expert are taken into consideration seriously by me...

By the way, since our last communication, I tried to eliminate some possible sources of the problem.

The machine where the crash took place had a RAID volume with 2 disks on it. I suspected that one of the disks might have some bad sectors on it due to abnormal behaviour.

I deleted the RAID volume, removed the suspected disk from the system and reinstalled the OS on the seemingly healthy one.

I am not sure if this was the real cause of the problem. However, now, the program does not crash.

[Khiem]

Hi All,

I have the following class declaration from which other classes are derived:

	class A
	{
	public:
		A();
		virtual ~A(){}
                void function1(const char* fileName1,
						       const char* fileName2,
						       string _folderPath1,
						       string _folderPath2 = "");
	protected:
		string s1;
		string s2;
	};

where

string _folderPath2

argument in member function1() has a default value.

In the body of A::function1(const char* fileName1,
const char* fileName2,
string _folderPath1,
string _folderPath2),

  s1 = _folderPath1; //this line does not crash
  if(_folderPath2 != "")
  {
     s2 = _folderPath2; //this line crashes
  }

I find using (const) string too in place of const chars would make your coded functions healthy

[Paul McKenzie]

The machine where the crash took place had a RAID volume with 2 disks on it. I suspected that one of the disks might have some bad sectors on it due to abnormal behaviour.

I deleted the RAID volume, removed the suspected disk from the system and reinstalled the OS on the seemingly healthy one.

I am not sure if this was the real cause of the problem. However, now, the program does not crash.

You still haven't given us any indication of how you are using those classes, what you're doing with those pointers I mentioned, etc.

All bets are that the problem is still with the code. Replacing hardware, installing programs, whatever, is not an explanation of why the program no longer crashes. It would have been better if you did nothing and instead, hired someone on your end to find the real problem -- it is always better that a bug can be consistently duplicated, rather than covering it up. Right now, any C++ programmer will tell you that all you did was move the "bug" to another place in the code when you change environments, hardware, etc. The crash can occur again at any time.

What you described is called "undefined behaviour" in the C++ world. If your code does something illegal, anything can happen. The code can work all the time, fail right away, work on a thousand machines and fail on one machine, etc. Have you heard of the situation where a program works correctly at the shop, and then crashes at the customer site? Why does that happen? Why is it that a lot of programs have "bug fix lists"? How could that be when the program works flawlessly on the programmer's machine?

When you write a C++ program, anything wrong that can happen does not have to show itself right away. C++ is not like other computer languages in this regard. If you go beyond the boundaries of an array, for example, your program isn't guaranteed to crash. As kempofighter pointed out, a program can have internal bugs, and seem to run flawlessly. The bug can appear again when code is added, removed, when the program is run on another machine, different hardware, different environment, etc.

So right now, all of what you did hasn't addressed the problem. Until you find out what the problem really was, you still have a hidden bug in the program. Unless the bug shows up again, you should use third-party tools to discover if you have invalid pointer accesses, memory overwrites, etc. If the bug shows up again, then it is the best opportunity once again to fix the bug. C++ programmers are happy if they can consistently get a bug to happen -- what is troubling is a bug that was never properly diagnosed, and all of a sudden, doesn't appear anymore.

Regards,

Paul McKenzie