I'm trying to do the recover assignment, but when I try to run it I get the error:

Fatal error: glibc detected an invalid stdio handle Aborted

I have no idea what this means or where to start to diagnose it. I tried Googling more about it but it didn't give me very good results. Can anyone help me here? Here's my code:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
    // Make sure user enters correct number of arguments
    if (argc != 2)
        fprintf(stderr, "Usage: ./recover image\n");
        return 1;

    FILE *inptr = fopen(argv[1], "r");

    // Make sure file pointer is not null
    if (inptr == NULL)
        fprintf(stderr, "Could not open %s\n", argv[1]);
        return 2;

    // Malloc memory for the buffer
    int *buffer = malloc(512);

    // Keep track of jpegs found
    int jpegCount = 0;

    // Make array for new file name
    char filename[8];

    // Declare img file pointer
    FILE *img;

    while (fread(buffer, 1, 512, inptr) == 512)
        if (buffer[0] == 0xff &&
            buffer[1] == 0xd8 &&
            buffer[2] == 0xff &&
            (buffer[3] & 0xf0) == 0xe0)
            // Close image if any previous images were found
            if (jpegCount > 0)

            // Create jpep filename and open the file for writing
            sprintf(filename, "%03i.jpg", jpegCount);
            img = fopen(filename, "w");

            // Make sure img doesn't return a null pointer
            if (img == NULL)
                fprintf(stderr, "Unable to create image file %s", filename);
                return 3;
        // If no images have been found, go to start of loop
        if (jpegCount == 0)

        fwrite(buffer, 1, 512, img);
    return 0;
  • Just by looking at it I can see code paths where you fclose a FILE* without ever having initialized it. Also in your loop you check if img==NULL and if it is NULL, you fclose it. That is a guaranteed segfault. – hddh Sep 20 '19 at 23:41

You need to isolate which line of code is causing this error. You could do this by running it in debug50 or by strategically placing some printf statements to find which lines are executing and what is the first line that isn't being processed. Sometimes, debug will mask an error. When you can't reproduce it in debug, but can reproduce it when normally executing, it's time to use the printf technique.

Once you find which line is failing, it should be obvious what the specific problem is that causes this error. However, you'll have to start thinking about what the underlying problem is and solve that!

I could tell you what's happening, but you'll benefit more from doing it yourself. The process will help develop and refine your debugging skills, one of the most important things you can do!

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)


Well, it looks like several people didn't like my answer here. Let me say this. This is a teaching forum, and therefore different from most of Stack Exchange. It's vastly more important for new programmers to learn how to identify which lines of code causes a seg fault than to simply resolve the problem.

Coding errors like Seg faults and other failures will occur constantly over a programmer's career. If they can't locate exactly which lines of code are causing them, then the programmer is seriously handicapped because they haven't developed that skill. THAT'S why I responded as I did!

That's why my philosophy is to teach this skill first! Once someone is able to identify a line of code that causes a problem, only then is it appropriate to move on to why a problem is happening.

There's one more difference. Identifying an offending line of code is a skill that absolutely must be developed through practice and repetition. It's an intrinsic skill that must be cultivated. Once a line of code is identified as being the source of a bug, then it's usually a matter of an incorrect usage of something or some other tech issue. Most often, this is the kind of error that can simply be explained, rather than asking the person to try to discover the problem. Frequently, it's something they've done that's incorrect, but they've never been shown what is wrong. Once the issue is described, it's usually remembered. Over time, with different issues, the programmer will learn to recognize different classes and types of problems and how to resolve them.

For example, a very common problem is this:


If this were in someone's code, it would surely throw a seg fault. But most people don't know why until it's explained to them. If someone says "I can't find the seg fault, can you help?" then they clearly need practice to locate which code would be causing a seg fault. OTOH, if they said, "I'm getting a seg fault from this call to isdigit and I don't know why!" then it's clear that they identified the code that is causing the problem and it's only necessary to expose them to the cause of the seg fault once. They'll never forget it!. (Incidentally, this could be caused by two different issues. ;-) )

The point of all this is that identifying the offending code is a must-learn skill, while resolving the issues, once identified, is more about seeing the resolution once and remembering it.

Of course, the next phase is learning to deal with deeply buried logic bugs, but that's an entirely different skill. ;-)

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .