I'm getting this in my program, C++
Program received signal SIGSEGV, Segmentation Fault.
0xb7d62153 in __strtol_l_internal () from /lib/libc.so.6
I got that by using GDB. CC compiled it fine along with G++
sockf = openSocket(domainname, portc);
if(sockf > 0){
log("ZONTRECK","COMPLETED SOCKET!");
int newsockfd;
newsockfd = openListen(sockf,portc);
log("ZONTRECK","Starting console!");
It's an internal function within libc, related to strtol() -- if I had to hazard a guess, I'd say you're trying to read in a number, and something is blowing up.
Use the backtrace command in gdb to see how the program got to that point from your code - that will help find what parameter is being passed that's causing the problem (probably a NULL or otherwise invalid pointer).
Maby you are trying here to read memory corrupted by some code ran before this. If this is the case than the best way is to debug it by Valgrind.
I had to edit a file i didn't post on this site. Its my file that contains openSocket,openListen.
The atoi function requires const char, not char.
I was passing a char to it instead of a const char.
I fixed this issue by changing the char in int main() to const char.
Related
i have problems with valgrind,
i created this class:
class shop {
private:
vector<vector<string> > products_;
public:
shop(string ProductFile);
FindMinPrice(string product);
}
//method in the cpp file
vector<string> shop::FindMinPrice(string product){
string ProductName=(string)products_[0][0];
}
i didn't write the entire code but its work fine with the GCC compiler.
when i run valgrind check it shows:
invalid read of size 8
and in eclipse it send me to the ProductName line.
what is wrong with the design ? and how so that the GCC compile and run but VALGRIND collapse?
thank you.
It appears that your products_ vector of vectors is empty, meaning that the access of element products_[0][0] is undefined behavior.
The unfortunate thing about undefined behavior is that your program may appear to work, and may even complete without any visible problems.
Using c-style cast in c++ is not a good practise.
Your shop method doesnt return any value.
I'm getting weird seg fault that seems to be coming from somewhere not in my program...not explicitly anyway. I'm calling "strcmp" on two array's... Both arrays are stored in the same type of structs. I'm getting at one with dot notation and one through dereferencing with "->":
int name = strcmp(one.name, two->name);
It compiles fine but when I run it I get the seg fault. I've tried tracking it down with GDB but when I put breakpoints in just before where I think it should occur, it seg faults anyway. I'm getting:
Program received signal SIGSEGV, Segmentation fault.
__strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:40
40 ../sysdeps/i386/i686/multiarch/../strcmp.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../strcmp.S
FML. Suggestions? Thanks!
My suggestion: Compile it with -g and run it through valgrind.
There is a function to load files:
int loadfile(char *fn)
{
printf( "\n my path: '%s' \n", fn );
FILE *f = fopen( fn, "r");
printf( "got\n" );
...
return 1;
}
The first file is in main() newfile( argv[1] );, works. The second is get by flex parsing/reading the first file, what I belive isn't related to the problem.
The console:
path: 'file1.hot'
got
path: 'file2.hot'
Segmentation fault: 11
The printf was able to print the char *fn, but fopen get a segmentation fault.
The next situation was, I tried explicit to put the file inside the loadfile doing fopen( "file2.hot", "r"); and works.
I'm compiling with g++, there is a different approaching when using c++ to use char * or fopen?
EDIT
Sorry, there's no newfile( argv[1] );. Correct: loadfile( argv[1] );.
General remark: When using C++, please prefer std::fstream to the C-style fopen/fread/etc.; also prefer std::string to char*. The latter alone will cure many memory headaches. If you, for some reason, have to stick to the C-style functions, be sure to check the return values (as mentioned in the other answers here already) - fopen for example returns a NULL pointer when it fails.
More specific to your question: Try to run your program under gdb (e.g. gdb <your-program>), to see where the Segmentation fault occurs exactly; that way you will also be able to see more details (e.g. variable contents etc.). Alternatively, if working under linux, use analysis tools such as valgrind to detect any kind of memory access problems.
you should always check return values from functions that have a return value. In this case make sure when you fopen the file that the return handle is not NULL and also make sure if you open the file, to fclose it.
Learn to use the GDB debugger (assuming you are on Linux), or the valgrind utility.
Perhaps putting your file path inside a std::string is worthwhile, and, as nyarlathotep mentioned, use a std::fstream.
It could happen that your fn is not null terminated....
Compile with g++ -Wall -g
As Anders K answered, always check the result of fopen against NULL. Pierre Vittet's Talpo extension to GCC (coded in MELT) is able to check automatically that you do check that.
I am having a repeating seg fault while using SystemC. During initialization I set a value to 0. During operation of a testbench I am setting this value to 1 in a module (proc). This is a sc_signal variable that is attached to a port of another module imem. The input port is of type sc_in.
In theory, this assignment should cause the input port to also be assigned 1, and when I try to access it using the .read() function it should return a 1 and assign it to another internal sc_signal within imem.
However, I am instead getting a seg fault.
According to gdb, this is occurring during the sc_start(10,SC_NS) call I make, which makes sense since that is when values should be updated. It traces it specifically to trying to execute the return of the .read(). Here is a quick snippet of the stack return (-O0 and -g3 using g++ and gdb6.6, 64-bit system):
#0 0x00000000004c79a6 in sc_core::sc_in<bool>::read (this=0x881a38) at <redacted>/systemC/install_x64/include/sysc/communication/sc_signal_ports.h:515
#1 0x00000000004e4b60 in imem::reg_write (this=0x881910) at ../src/abstract_proc/mems/imem.cpp:33
#2 0x000000000050578e in sc_core::sc_simcontext::crunch(bool) ()
#3 0x00000000005042b4 in sc_core::sc_simcontext::simulate(sc_core::sc_time const&) ()
#4 0x00000000004c65b0 in sc_core::sc_start (duration=10, time_unit=sc_core::SC_NS)
The port declaration:
SC_MODULE (imem) {
...
sc_in<bool> en_wr;
The function declaration (occurs in SC_CTOR(imem)):
SC_METHOD(reg_write);
sensitive << clk.pos();
The function in where it dies:
void imem::reg_write() {
data_wr_d.write(data_wr.read());
wr_addr_d.write(addr_wr.read());
cout << "imem::reg_write()" << std::endl;
en_wr_d.write(en_wr.read());
cout << "imem::reg_write() done" << std::endl;
}
imem::reg_write() gets printed into the console just before the seg fault occurs.
The declaration and binding of imem's port:
imem_i = new imem("imem");
imem_i->en_wr(imem_wr_en);
The declaration of the driving signal:
sc_signal<bool> imem_wr_en;
Any ideas? Thoughts? Things I should try?
EDIT: Something odd that occurs is sometimes adding or removing lines of code causes the seg fault to go away. One particular instance involved adding a debug cout statement fixed things, but after adding a << std::endl to the end of it the seg fault returned. This implied to some that I have a race condition, but in theory SystemC should be handling all the concurrent threads.
Sounds like memory problem. If you over run buffers somewhere, anything can happen - even stuff like you explained : program crashing at random location.
I really hope you got good unit tests. Try using valgrind to detect memory problems.
Could you please tell if you have got solution to your problem. Actually we are hitting similar issue, seg fault, while reading a boolean sc_signal. And problem goes away after adding prints in code.
I have experienced a strange behavior when using _itoa_s and _ultoa_s if I try to get a char array from an DWORD. The function returns zero(success) and my application continues, but I'm getting an exception window with error code 0xc0000417 (STATUS_INVALID_CRUNTIME_PARAMETER).
ULONG pid = ProcessHandleToId(hProcess);
int size = getIntSize(pid);
char *pidStr = new char[size+1];
_ultoa_s(pid, pidStr, size+1, 10);
//do sth with pidStr...
delete[] (pidStr);`
ProcessHandleToId returns the PID (DWORD) for a given ProcessHandle.
getIntSize returns the number of numbers to the corresponding int/char array (5555 => 4).
Yes, the safe CRT functions will abort your program with status code 0xc0000417 when they detect a problem. However, they will do this immediately, the function will not return.
Which means that you are looking at the wrong source code for this problem. It isn't the _ultoa_s() call that's bombing your program. It's another function call, somewhere else in your code. I can't help you find it of course. But the debugger should give you a good idea, look at the call stack when it breaks.
I just compiled your code and it runs fine. The int to string conversion is correct. I assume you bump into security issues due to missing permission when trying to access process handles you don't own.