I am building Stack Class using Linked List manually. I want to return Segmentation fault when the top() function is called on an empty Stack. How can I do that? Or some other error that I can return.
Segmentation faults are triggered by hardware and handled by the OS. You do not trigger them manually.
You can throw an exception: http://www.cplusplus.com/doc/tutorial/exceptions/ or you can decide on some value which indicates an error and return that.
If you have a pointer to the first element that is null or dangling (i.e. pointing to uninitialized/freed memory) when the list is empty, you can also dereference it as if there was a value. This will sometimes cause a segmentation fault and sometimes return bogus data. In this case it is up to the user not to call top on an empty list. Generally code does not guarantee to segfault in certain cases. Rather it sometimes happens when the hardware manages to catch a bad memory access.
If you post your code it will be easier to say how you can report the error in your concrete case.
How can I do that?
You could raise(SIGSEGV). Alternatively abort() the execution.
You could also force read from invalid memory address, for example from the null pointer with like: *(volatile int*)0;.
Or some other error that I can return.
You should definitely not cause a segmentation fault condition intentionally in your program. Instead use an exception.
I have been having a peculiar problem. I have developed a C++ program on a Linux cluster at work. I have tried to use it home on an Ubuntu 14.04 machine, but the program, which is composed of 6 files: main.hpp,main.cpp (dependent on) sarsa.hpp,sarsa.cpp (class Sarsa) (dependent on) wec.hpp,wec.cpp, does compile, but when I run it it either returns segmenation fault or does not enter one fundamental function of the class Sarsa.
The main code calls the constructor and setter functions without problems:
Sarsa run;
run.setVectorSize(memory,3,tilings,1000);
etc.
However, it cannot run the public function episode , since learningRate, which should contain a large integer, returns 0 for all episodes (iterations).
learningRate[episode]=run.episode(numSteps,graph);}
I tried to debug the code with gdb, which has returned:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000408f4a in main () at main.cpp:152
152 learningRate[episode]=run.episode(numSteps,graph);}
I also tried valgrind, which returned:
==10321== Uninitialised value was created by a stack allocation
==10321== at 0x408CAD: main (main.cpp:112)
But no memory leakage issues.
I was wondering if there was a setting to try to debug the external file sarsa.cpp, since I think that class is likely to be the culpript
In the file, I use C++v11 language (I would be expecting errors at compile-time,though), so I even compiled with g++ -std=c++0x, but there were no improvements.
Unluckily, because of the size of the code, I cannot post it here. I would really appreciate any help with this problem. Am I missing anything obvious? Could you help me at least with the debugging?
Thank you in advance for the help.
Correction:
main.cpp:
Definition of the global array:
`#define numEpisodes 10
int learningRate[numEpisodes];`
Towards the end of the main function:
for (int episode; episode<numEpisodes; episode++) {
if (episode==(numEpisodes-1)) { // Save the simulation data only at the
graph=true;} // last episode
learningRate[episode]=run.episode(numSteps,graph);}
As the code you just added to the question reveals, the problem arises because you did not initialize the episode variable. The behavior of any code that uses its value before you assign one is undefined, so it is entirely reasonable that the program behaves differently in one environment than in another.
A segmentation fault indicates an invalid memory access. Usually this means that somewhere, you're reading or writing past the end of an array, or through an invalid pointer, or through an object that has already been freed. You don't necessarily get the segmentation fault at the point where the bug occurs; for instance, you could write past the end of an array onto heap metadata, which causes a crash later on when you try to allocate or release an unrelated object. So it's perfectly reasonable for a program to appear to work on one system but crash on another.
In this case, I'd start by looking at learningRate[episode]. What is the value of episode? Is it within the bounds of learningRate?
I was wondering if there was a setting to try to debug the external file sarsa.cpp, since I think that class is likely to be the culpript
It's possible to set breakpoints in functions other than main.cpp.
break location
Set a breakpoint at the given location, which can specify a function name, a line number, or an address of an instruction.
At least, I think that's your question. You'll also need to know how to step into functions.
More importantly, you need to learn what your tools are trying to tell you. A segfault is the operating system's reaction to an attempt to dereference memory that doesn't belong to you. One common reason for that is trying to dereference NULL. Another would be trying to dereference a pointer that was never initialized. The Valgrind error message suggests that you may have an unitialized pointer.
Without the code, I can't tell you why the pointer isn't initialized when you run the program on your home system, but is (apparently) initialized when you run it at work. I suspect that you don't have the necessary data on your home system, but you'll need to investigate and figure that out. The fundamental question to keep asking yourself is "what is different between my home computer an dmy work computer?"
I have my code ready to run with PROOF.
Whenever I run code standalone I works fine, when I activate PROOF, my code crash with a Segmentation Fault.
With GDB I'm able to know exactly where it crashes: when I try to follow a pointer to a object. This makes me think that this pointer (that I'm absolutely sure it was valid before) is invalid and I have no idea why so.
Are there other options? can I track that pointer so I know where it was released?
Use valgrind memcheck tool with --leak-check=summary --track-origins=yes.
This shows invalid memory access (Segmentation Fault) and where they had been freed.
I am running a program in multi threaded environment it fails at some point. when i tried it with gdb than it is shoing the following error.
program received signal SIGSEGV, segmentation fault.
[switching to thread 0x7fff677b700 (LWP 2777)] 0x00007ffff7aa42b9 in
process_incomplete_rows (resultset=0x507950) at c/mgmt.c:479 479
c/mgmt.c: No such file or directory.
mgmt.c file is there and this code is working fine for some options but 2 or three options its giving this error. What could be the cause of this error. Its error in comiplation or in coe? or its error while accessing some data?
A segmentation fault is a runtime error that is usually due to referencing an invalid pointer. Usually that invalid pointer has never been initialized, but sometimes it is reusing an old pointer or writing past the end of an allocated memory chunk (such as past the end of a string).
It probably means that your node variable is either NULL or corrupted. Run your program in the debugger, stepping through it from some point prior to the crash up until it and see where you've messed it up. Or use one of the automated tools like Purify or Insure++ to track it down for you.
I'm getting a segfault with the following line of code:
char* addr = (char*)std::malloc(bytes);
When running GDB I see that bytes has a value of 851984. As far as I know that shouldn't be a big deal. I can't seen anything wrong with it for the life of me. Anybody have some suggestions?
The actual segfault error is:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff674dd75 in malloc_consolidate (av=0x7ffff6a87720) at malloc.c:4254
There is (most likely) an issue somewhere earlier in your code which is corrupting heap structures, causing malloc to fail on allocation. You should try using a memory error detection tool like valgrind to debug this issue.