views:

227

answers:

6

hi all,

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

A: 

Segfault comes when you are trying to access memrory which you are not allowed to access. So please check that out in the code.

Ashish
Why the downvote?It is correct. Not sure it's relevant but given the little info we've got he might be right.
the_drow
+1  A: 

The code itself looks just fine. I can suggest some ways to go ahead with debugging -

  1. Try removing the display() call. Does the problem still occur? (I'd assume it does).
  2. 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.
  3. 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.

Hexagon
hi hexagon,Thank you very much for the reply...i will try with these suggestions from you. I did not notice the comment section. For the next post on i will use it. Thanks.Is there a way to check for valididty of PGM files ? I will google for it any way. If you know about it, please don't mind sharing.One more thing, i had used imwrite function of Matlab to create these PGM files. I would trust the output of Matlab any time because many of my algorithms are poved correct using matlab.I think it shoud provide valid PGM file as output.
sravan
@sravan, I tend to agree with you - I would have trusted Matlab too. But as the PGM format is not very strict, there may be some incompatibility between the two. And no, I'm not away of a good way to check the validity of PGM files. You may want to step through the CImg code and see exactly how it fails - it may give you a hint as to what is wrong with the PGM file.
Hexagon
hi hexagon,Yesterday, i had downloaded few pgm files over Internet and tried the same program with these new images. Bingo!! It worked. Just to satisfy myself i had opened a JPG image using GIMP on linux and converted to PGM file. Even the newly created pgm file to worked with CImg. Hence, i came to conclusion that only the PGM images created using imwrite in Matlab was creating some problem for me. I don't whether the mistake imwrite of Matlab is generating the wrong PGM files or is it with CImg.As i have to proceed with my work i am using the pgm files which were downloaded. thanks hexagon
sravan
A: 

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:

  1. Are you compiling with the same compiler as was used to compile the CImg library?
  2. Are you using the same compiler flags?
  3. 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.

Michael Anderson
In general these suggestions are sound. But specifically for the CImg library, it looks like it just lives in one large (very large...) header file. So separate compilation shouldn't be an issue - there is nothing to link to.
Hexagon
Indeed, scratch these ideas for CImg itself. But after looking at the CImg docs it forwards the reading/writing of certain formats to other libraries which could have these issues. However these libraries are predominantly C libs and thus less susceptible to this kind of issue.
Michael Anderson
A: 

hi all,

Thank you very much for the suggestions and hints. All these are fine. Let me take one by one of these suggestions.

  1. I am using #include instead of #include "iostream". That was a typing error by me. pardon me.

The question of GMan was as followed:

Is there any difference between the two images? Is one significantly larger, for example?

Ans: Yes the new image was larger than that of old image.But, i don't think that should be a problem, for CImg is generic library.

The question of ux9i was as followed:

Also, you aren't checking argc so see if argv[1] is even defined. Unsure if that's it, kind of guessing. Did you try running this under a debugger like gdb?

Ans: i did not check for argc, because it is simple program, but i made sure that i gave the arguments correctly.I agree that it is a mistake, but can be forgiven. I had pasted the output from "gdb" as well in my question itself. I did not try backtrace, i will and let you know.

The question of tehMick was as followed:

Are you talking about a subsequent run of exactly the same program with only a different argument? Also, what version of CImg are you using?

Ans: Yes, it is subsequent run of the same program with different argument.I use CImg-1.3.1

The question of Alok was as followed:

is ddnl.pgm a PGM image file or something else? From ux9i's link, it tries to determine the image type from the file's extension.

Ans:I am sure that ddnl.pgm is a PGM file. I had created it myself in Matlab. I used imwrite function of Matlab to create it.

Thank you all for your inputs and hints

sravan
When you feel the answers so far haven't addressed your question, please update your original question (it has an _edit_ link beneath it). You've now added another answer that's not an answer.
MSalters
thank you MSalters. I will use the link.
sravan
A: 

hi Hexagon,

These were your questions:

  1. Try removing the display() call. Does the problem still occur? (I'd assume it does).
  2. 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.
  3. 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.

The answers for the questions are as follows respectively:

Answers:

  1. I had tried removing the Display call. Yes, the problem still occurred.
  2. In my question itself i had put the "gdb" output. It shows that strlen() was called by library function from lib/libc.so.6. What can i do about the libraries?
  3. I don't know whether the provided PGM file is valid or not. Is there any other way to check for its validity.
sravan
This should be a comment on Hexagon's answer. That way you don't have to repeat the questions.
Mike D.
@sravan, Please take a look at my edited answer - I added additional observations based on the stack trace you provided.Also, please avoid adding answers just to provide extra information - this is what comments are for.
Hexagon
A: 

hi all,

Since most of you were asking for Backtrace of gdb, i thought i would like to post it differently. Here it is:

  1. 0x0076a3a3 in strlen () from /lib/libc.so.6

  2. 0x0804d127 in cimg_library::cimg::strcmp (s1=0x0, s2=0x80c0c9f "pnm") at CImg.h:4972

  3. 0x080c03a7 in cimg_library::CImg::load (this=0xbffff324, filename=0x80c119d "ddnl.pgm") at CImg.h:29673

  4. 0x08049a93 in cimg_library::CImg::assign () at CImg.h:10603 CImg () at CImg.h:10342

  5. main () at temp.cpp:9

Thank you all.

sravan