I will below describe the error that I get when calling the function sscanf.
Some of my code:
#include <cstdio>
(..)
int device_num = 0;
int frameTime = sscanf(currentStringVector[2].c_str(), "%d", &device_num);
It is part of a module of OmNet++, so I compile it using OmNet++ .
I get the following error message in GDB:
"Program received signal SIGSEGV, Segmentation fault.
__rawmemchr_sse2 () at ../sysdeps/x86_64/multiarch/../rawmemchr.S:31
31 ../sysdeps/x86_64/multiarch/../rawmemchr.S: Filen eller katalogen finns inte.
in ../sysdeps/x86_64/multiarch/../rawmemchr.S"
The problem started to incur when I called sscanf.
I am running the program in Ubuntu on a 64-bits system.
How do I resolve the above problem?
Thanks!
With OMNeT++, you can use a debugger like gdb when running your program from the command line. The IDE also lets you debug your code.
My guess is that currentStringVector[2].c_str() is not valid. Maybe the vector is smaller than that.
Related
Hi I am doing this simple program
#include <iostream>
#include <string>
using namespace std;
int main (){
string hi("Hi how are you");
for(int i = 0;i<4;i++)
cout<<hi<<endl;
return 0;
}
When I compiled it and run it, there were no issues, but when I try to debug it, every time the IDE program (Code::Block 16.01) steps in or out of string hi("hi how are you") it gives me a Segmentation Fault.
I know SF is when the program tries to access a space of memory that it is not supposed to access, and I know string class is a C-Sytle string that allocates memory dynamically, and deletes them automatically when the program is finished, hence there should be no issue in memory management, so this code shouldn't be a problem.
BUT in this code I don't understand why do I get a SF when I debug it. When I tried debugging it for the first time and stepped out of hi, there were no errors, but when I tried watching hi, it gave me a SF, and when I try to debug it again, and I steped into string hi I get S.F.
Screenshot of the error FYI
When I was search information about this issue I found entry in Code::Blocks forum, but it is quite old.
However, there is possibility of bug in GDB for MiniGW. If you want to be sure, you should look for this issue and its fix.
I know that this isn't full answer, but you should go to this posts and read they, there is some solution:
Code::Blocks forum's posts:
1. Watching std::string in debugger causes segfault?!?
2. Still having seg fault while watching a string....
I have read a few articles about signal handling in Python, and for some reason am not getting the desired output.
This is my C++ code. It is meant to simulate a segmentation fault.
The purpose of the Python code is to run the C++ program as a subprocess and to catch run time errors, if any.
int main()
{
int*a;
a=NULL;
cout<<*a<<endl;
return 0;
}
The python code is as follows:
from subprocess import *
import signal
def handler(signum,frame):
print "Error Occured",signum
raise IOError("Segmentation Fault Occured.")
#The C++ code is already compiled
a = Popen(["./a.out"])
try:
signal.signal(signal.SIGSEGV,handler)
except IOError as e:
print e
When the C++ code is run on the terminal directly, (not using the Python code) this is the output:
Segmentation fault (core dumped)
When the same is run using the Python code, no output is observed.
What is going wrong in my approach?
Thanking you in advance.
PS: I tried this as an alternative and it worked. However, it cannot be used for my application since I cannot use wait() method.
a.wait()
if a.returncode == -11:
print "Segmentation fault, core dumped"
Okay the issue was solved. Instead of using
signal.signal(signal.SIGSEGV,handler)
I used the following:
signal.signal(signal.SIGCHLD,handler)
I'm trying to execute a very simple program that runs "ls" command
Im working under Mac OS 10.7, with XCode and C++
This is the code:
#include <iostream>
using namespace std;
int main(void)
{
cout << "Hello world" << endl;
execl("/bin/ls","ls",NULL);
return 0;
}
It crashes after following output
Hello world
No memory available to program now: unsafe to call malloc
I tried to google it but no luck, any ideas on what I might be doing wrong?
This is just "my opinion"
From man page:
The exec family of functions replaces the current process image with a
new process image.
It could be that it tries to replace the debugger process and so it crashes (the app is run from Xcode..). If you execute the app from command line it works...
Seems to work fine:
http://ideone.com/8AoZ3
But seems like on your platform some sort of weird recursion is taking place. Can you change your call to:
execl("/bin/ls","/bin/ls",0);
I know this may not be exactly what you want to do, but the following SO question is using execv to execute echo:
how-to-create-a-process-on-mac-os-using-fork-and-exec
I do some image processing work in C++. For this i use CImg.h library which i feel is good for my work.
Here is small piece of code written by me which just reads an image and displays it.
#include "../CImg.h"
#include "iostream"
using namespace std;
using namespace cimg_library;
int main(int argc,char**argv)
{
CImg<unsigned char> img(argv[1]);
img.display();
return 0;
}
When i give lena.pgm as input this code it displays the image. Where as if i give some other image, for example ddnl.pgm which i present in the same directory i get "Segmentation Fault".
When i ran the code using gdb i get the output as follows:
Program received signal SIGSEGV, Segmentation fault.
0x009823a3 in strlen () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.9-2.i686 libX11-1.1.4-5.fc10.i386 libXau-1.0.4-1.fc10.i386 libXdmcp-1.0.2-6.fc10.i386 libgcc-4.3.2-7.i386 libstdc++-4.3.2-7.i386 libxcb-1.1.91-5.fc10.i386
Can some one please tell me what the problem is? and how to solve it.
Thank you all
Segfault comes when you are trying to access memrory which you are not allowed to access.
So please check that out in the code.
The code itself looks just fine. I can suggest some ways to go ahead with debugging -
Try removing the display() call. Does the problem still occur? (I'd assume it does).
Try finding out where in the CImg code is the strlen() that causes the segmentation fault (by using a debugger). This may give additional hints.
If it is in the PGM file processing, maybe the provided PGM file is invalid in some way, and the library doesn't do error detection - try opening it in some other viewer, and saving it again (as PGM). If the new one works, comparing the two may reveal something.
Once you have more information, more can be said.
EDIT -
Looking at the extra information you provided, and consulting the code itself, it appears that CImg is failing when trying to check what kind of file you are opening.
The relevant line of code is -
if (!cimg::strcmp(ftype,"pnm")) load_pnm(filename);
This is the first time 'ftype' is used, which brings me to the conclusion that it has an invalid value.
'ftype' is being given a value just a few lines above -
const char *const ftype = cimg::file_type(0,filename);
The file_type() function itself tries to guess what file to open based on its header, probably because opening it based on the extension - failed. There is only one sane way for it to return an invalid value, which would later cause strcmp() to fail - when it fails to identify the file as anything it is familiar with, it returns NULL (0, actually).
So, I reiterate my suggestion that you try to verify that this is indeed a valid file. I can't point you at any tools that are capable of opening/saving PGM files, but I'm guessing a simple Google search would help. Try to open the file and re-save it as PGM.
Another "fun to track down" cause of segmentation faults is compilier mismatches between libraries - this is especially prevalent when using C++ libraries.
Things to check are:
Are you compiling with the same compiler as was used to compile the CImg library?
Are you using the same compiler flags?
Were there any defines that were set when compiling the library that you're not setting now?
Each of these has bitten me in subtle ways before.
I am working on a migration project, here we are migrating large set of C++ libraries from Mainframe to Solaris. We have complted migration sucessfully, but while running the application, some places it crashes with 'signal SEGV (no mapping at the fault address)'.
Since the application supports on windows also, we checked with purify on windows. There are no memory leaks in the application and it works fine on windows.
Can any one suggests, what could be the other reasons which may create this type of errors. Any tools for tracing this type of errors?
It's not necessarily a memory leak. It could be that a piece of memory is referenced after it is free'ed.
My friend once came to me with a piece of code that runs fine on Windows but gives segv on Linux. It turned out that sometimes the memory is still valid after you free'ed it on Windows (probably for a short period of time) but immediately triggered segv on Linux.
The line below looks wrong to me
m_BindMap[sLabel] = b; // crashes at this line at when map size
I assume you are trying to add a number to the end of the string. Try this instead
stringstream ss;
ss << ":BIND" << ns;
string sLabel = ss.str();
Are you using g++? If so, recompile with the "-g" flag. Run the program in gdb. When it crashes type "bt" (for backtrace) and that should tell you where your problem is.
I am using CC compiler on solaris and dbx debugger. I know the call stack where it is crashing. But it is abromal crash.
map<string,CDBBindParam,less<string> >m_BindMap;
CNumString ns(CNumStringTraits(0,2,'0'));
ns = m_BindMap.size();
string sLabel = ":BIND"+ns;
CDBBindParam b(sLabel,val);
**m_BindMap[sLabel] = b;** // crashes at this line at when map size is more than 2
return sLabel;