I have been trying to trace the source of a segfault in a cython program that I inherited. I have implemented gdb under python3 by executing gdb python3 then run my_file.py and got this:
Program received signal SIGSEGV, Segmentation fault.
__pyx_f_7sklearn_5utils_25graph_shortest_path_leftmost_sibling (__pyx_v_node=<optimised out>)
at /home/my_name/.pyxbld/temp.linux-x86_64-3.4/pyrex/sklearn/utils/graph_shortest_path_strat.c:3195
3195 __pyx_t_1 = (__pyx_v_temp->left_sibling != 0);
Thanks #Veedrac
The call appears as follows:
landmark_points=[random.randint(0,kng.shape[0]) for r in range(self.number_landmark_points)]
self.dist_matrix_=graph_shortest_path_strat(kng,landmark_points,method=self.path_method,directed=False).
Basically instead of calculating the distances between every single point in a graph I want to calculate the distance between all points and a limited number of points defined in an array. where landmark_points is an array of integers kng is a graph of nearest neighbors
kng = kneighbors_graph(self.nbrs_, self.n_neighbors,mode='distance')
the graph_shortest_path is a .pyx code. And I am using version is 0.15.1
#Veedrac thanks for your help. I actually traced the error to the fact that I was using random.randint, when I should have been generating unique random integers with random.sample.
Related
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 have to create static 3D array 200x200x200, but when I try to compile this code
int main()
{
int arr[200][200][200];
return 0;
}
program crashes. Debugger displays this error:
Program received signal SIGSEGV, Segmentation fault.
Does anyone have idea how to solve this?
You are running out of space: 200*200*200*4(32 bit system int) are ~32MB. You cannot allocate that much space in the stack. Answer 1 and Answer 2
Find another solution that involves computing less numbers, for example using temporal results to find other results, or saving values to file and loading them when needed
I have a program written in C++ that uses a lot the "system" function to run things like i would run in Shell (using Ubuntu 12.04 32 bits).
The things done in the "system" function generate several files that will be processed. In a second part of the program i process those files.
When the program ends, it doesn't delete those files that was generated by the "system" functions.
When i run the program for the first time it runs fine, when i run in a second time it gives me Segmentation fault (core dumped) in a given loop of the second part. It does less iterations each time i try to run. For example : First run = ran fine. Second run = Segmentation fault(core dumped) in iteration 200. Third run = Segmentation fault(core dumped) in iteration 199. And goes on...
I resolved the problem deleting all files it had generated by "system" function in the end of each "run" of the program.
My question is...any one has any clue about why was it happening?
EDIT*
Below is a few pseudocode to exemplify.....unfortunately i cant put the entire code, its like 600 lines.
int main(void){
// Part 1 of the program.....severam "system" producing files
system("bash produceSeveralFiles.sh");
// Part 2 of the program......process files produced in part 1
processFiles();
// My Solution that i dont know why solves it
system("rm AllFiles");
return 0;
}
EDIT*
Way i checked that it goes until the loop...
for(int i = 0; i < 300 ; i++){
printf("\n%d",i);
...//a few code here
printf("\n%d",i);
}
Second run i see "i" goes until 200....third run i see "i" goes until 199....and go on...thats the way i checked where it was giving the Segmentation Core (dumped).
EDIT*
O well im ashamed now, just checked the old Script that was generating the files before the program and it gives the same problem....if i do the generation in a separated file and then only runs the "processFiles()" in the program, it gives the same error. The old Script has an "rm files" command in the end that wasnt concerned about. (thx to user #beta....just checked the old script cause your commentary)
Well....but anyway the question continue, but now i know its not only with the "system" function.
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.
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.