Dear all,

I have written a simple program using FFMPEG libraries in C, to zero out some packets in a video, and then try to extract its frames.
The program complies without an error in gcc, and gives me an executable file.
When I use the executable file with a video as output, I get no frame.
(While it worked correctly before zeroing packets)
So, it seems the program crashes somewhere.
Is there any capability in gcc, or any other linux IDE, that I can use to find where in my code the executable file crashes?

Take a look at http://www.kdevelop.org/index.html?f...rated_Debugger

Thank you very much.
So, I have installed KDevelop on my Linux(it is Ubuntu)
Now, I have a code compiled by GCC, and it has given me an executable file.
The input for the executable file is a video file, and the output is the frames of video saved in separate files.
I want to see exactly which functions are called during the run of my executable code.Since the functions in my code should refer to the ones inside the FFMPEG's source code, and I want to see exactly where.
Do you know how can I do it in KDEvelop, or is there some tutorial to teach me doing that?

Thanks again,and sorry since the questions may look a little bit dumb.

The 'classic' (ie, ignoring the debugger) way of attacking this kind of problem is to write something to I/O. This may be a 'diagnostic print statement' (assuming you've somewhere to send it...maybe to a printer or to a window on the monitor) or to write to a log file.

it is of course your choice about how much information to write; you may just want to write 'entering routine blah' or you may find 'entering routine blah, data = blur' more helpful.

Usually then the last succesful write is the first one that you want to start pulling to pieces.

Thanks,
I'm not sure whether I got it right or not, but you mean I modify the functions' bodies so that the write something in a log file when they are called?

If that is the case, it should be really hard, cuz there are tons of functions in the source code, and even lots of .c files, so it is really difficult to change all those files, when you have no idea that it goes to which file, and calls which function among those many choices.


If my understanding is wrong, I appreciate you correcting me.

Well, I had more in mind that you would modify the calling program than the function being called; after all, this will probably more useful if your calling program calls the function from several places.

If there are too many places, you would have to make some intelligent guesses about where the problem might be and scatter a few 'prints' around; if you've got it wrong, you'd have to start again scattering new 'prints' around the place, bearing in mind your new knowledge.

Another thought is that the 'prints' may be activated with ifdefs depending on some debugging status; as this can make a mess of the code, you may want to take appropriate measures for removing them once debugging is complete (is this a realistic provision?).

ddd is an excellent
frontend to gdb