Fatal error glibc detected an invalid stdio handle

I have been searching all over the internet to try and understand why I am getting this error, but I have only ever seen this appear in other programming languages I am unfamiliar with or with code I have never used before.

I am working on a quicksort program for a school assignment, and everything was going well until I decided to consolidate the median bubble sort algorithm into a helper function.

int* QS::MedianSort(int left, int middle, int right) {
    cout << "starting MedianSort...n";////////////
    int temp;
    static int sort [] = { left, middle, right };
    do {
            if (sort[0] <= sort[1] && sort[1] <= sort[2]) {
                break;
            }
            else if (sort[1] < sort[0]) {
                temp = sort[1];
                sort[1] = sort[0];
                sort[0] = temp;
            }
            else if (sort[2] < sort[1]) {
                temp = sort[2];
                sort[2] = sort[1];
                sort[1] = temp;
            }

    } while(true);

    cout << "...returning sort from Median Sortn";//////////
    return sort;
}

An example of its implementation in my partitioning algorithm:

        int *temp;
        int tempInt;

        temp = MedianSort(*(array + left), *(array + pivotIndex), *(array + right));
        *(array + left) = *(temp + 0);
        *(array + pivotIndex) = *(temp + 1);
        *(array + right) = *(temp + 2);

        tempInt = *(array + pivotIndex); 
        *(array + pivotIndex) = *(array + left);
        *(array + left) = tempInt;

array is a pointer to an array that I am quicksorting, left is the smallest index being passed into the partition function, and right is the largest.

When I compile the code, it goes without a problem, but as soon as I run the executable, I get this error in the console:

Fatal error: glibc detected an invalid stdio handle
Aborted

I don’t understand why, because it finishes with the 3rd input file out of 5, but doesn’t even start the 4th file. (I know this because I have cout statements at the beginning almost every function to show me how far it is getting.)

Also, main.cpp has been successfully going through all the files up to this point.

EDIT:
I am compiling with -g -std=c++11

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.

[Edit]

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:

isdigit(argv[1])

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.

Recover: Fatal error: glibc detected an invalid stdio handle

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:

1 Answer 1

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. 😉

Источник

nix-channel segfault: Fatal error: glibc detected an invalid stdio handle #2733

I can provide more info, and a core dump if needed, just ask here or in #nixos.

The text was updated successfully, but these errors were encountered:

For me this looks to be like a curl issue. I have a coredump as well, and I can enable debug symbols if necessary. I’m hexa- on #nixos.

I can reproduce when running as root in a systemd service with nix 2.2.2 on NixOS 19.03.172866.4649b6ef4b5 (Koi).
Works fine in a terminal though.

The command is: $/bin/nix-channel —update nixos-unstable

This happened to me when installing nix on CircleCI (doesn’t happen deterministically, previous installs succeeded):

Apparently the currently known workaround is to retry 🙁

Encountered the same segfault and dump as @mweinelt posted, in my case while invoking a nix-shell , which lead to things being downloaded.

I was able to reproduce this multiple times at the same step in a CI (while having multiple substituters present btw), now trying to reproduce with a Nix version having debug symbols enabled to get a more detailled coredump.

However, as CI is flaky due to other reasons too, and nix pretty slow due to -Og , this might take a while (or never finish at all).

It’s notable that this occurs very frequently (like 50% of the time?) just by running the install script on an azure pipelines ubuntu machine if that helps with anyone trying to reproduce it.

So, we managed to get somewhat better setup to reproduce, and were able to drill it down a bit:

• The bug is present in Nix 2.2.2 already, not just master
• Setting —options substituters «» caused the bug to disappear
• Disabling http2 caused the bug to disappear —options http2 false (requires

Источник

Fatal error: glibc detected an invalid stdio handle #57

Happening with the clang branch on ubuntu 16.10
Running the tests generates:
«Fatal error: glibc detected an invalid stdio handlen»
while they used to work

Description of the problem

./waf —cwd=/home/teto/dce —run test-runner —command-template=»gdb -ex ‘run —suite=dce-process-manager —verbose —tempdir=/tmp/tmp7xpcdjr5 ‘ —args %s «

One _should_ be using ‘#include ‘ to get LIBC_SO and then dlopen that, it’s the only supported solution,
I’ll propose a patch to do that.

The text was updated successfully, but these errors were encountered:

So I went on #glibc to ask how to deal with it but clearly DCE should not tamper with the vtable as it was the goal of the hardening in the first place. So we have to find another way.
So I had a look at https://github.com/direct-code-execution/ns-3-dce/blob/master/model/dce-stdio.cc#L196
and apparently overriding the virtual table just helps setting «errno».
If I take «my_close» as an example, it calls dce_close which sets possibly sets «current->err = EBADF;»
my_close then checks if there was an error and sets «errno = Current ()->err;». Is there a case where this could not be atomic ?
My current idea would be to have dce_close do «errno = current->err = EBADF;» ?

it looks like not related to clang support itself, i removed the project label.

We need to have our own vtable to handle our private syscalls (my_read etc).
I’m going to investigate this.

Dear Hajime,
I’m trying to install NS-3 DCE on Ubuntu 18.04 LTS but we have the same issue.

Please, can you provide some instructions how to overcome this issue?
Thank you!

Источник

Ruby » Ruby master

Сохранённые запросы

Bug #12666

Fatal error: glibc detected an invalid stdio handle

Описание

During build of Ruby for Fedora on PPC64, there is reported following error:

and this is the analysis of one of glibc maintainers:

Please also note that:

To workaround this error, I am going to apply following patch to Fedora:

i.e. I am going to disable the custom code for detecting glibc on various platfors and rely just on ldd. My question is what should be the proper fix? Shouldn’t be the ldd way the default behavior for Linux?

This issue was originally reported at:

Файлы

Обновлено shyouhei (Shyouhei Urabe) больше 6 лет назад

For Fedora the patch seems OK. But I doubt if it could break on other systems like mswin. The fix proposed by the glibc maintainers seems much moderate to me.

Обновлено naruse (Yui NARUSE) больше 6 лет назад

Shyouhei Urabe wrote:

For Fedora the patch seems OK. But I doubt if it could break on other systems like mswin. The fix proposed by the glibc maintainers seems much moderate to me.

Use ldd instead of hard coded list sounds reasonable while ldd exists.

At least OS X doesn’t have ldd(1). (it has otool -L )

Обновлено vo.x (Vit Ondruch) больше 6 лет назад

Actually, in the RHBZ, there are two comments from two glibc maintainers and both suggest to load glibc without specifying path, e.g.:

But this should apply probably also to x86_64-linux.

What I still don’t understand, why there is currently so complex logic how to determine the path, when it could be so easy?

Обновлено vo.x (Vit Ondruch) около 6 лет назад

Ping . any chance to get this fixed? PPC was recently added into primary Fedora builder, so this is troublesome :/ Also, it will make issues to Fedora PPC users as soon as Fedora 25 is release, which should be next Tuesday if I am not mistaken .

Обновлено kernigh (George Koehler) около 6 лет назад

For both BSD and Linux, I want to suggest

Works for me on OpenBSD:

It’s bad to guess the path (like «/usr/lib») or the version number (like «6» in «libc.so.6»). It will break when someone has libc with different path or version number.

I’m attaching patch.

Обновлено naruse (Yui NARUSE) около 6 лет назад

George Koehler wrote:

For both BSD and Linux, I want to suggest

It breaks FreeBSD.

Why you guys breaks other platforms without checking.

Обновлено shyouhei (Shyouhei Urabe) около 6 лет назад

• Параметр Статус изменился с Open на Assigned
• Параметр Назначена изменился на tenderlovemaking (Aaron Patterson)

Обновлено shyouhei (Shyouhei Urabe) почти 3 года назад

• Параметр Статус изменился с Assigned на Feedback

Sorry for a late reply, but I think we have touched this area since you reported. Does this still happen?

Обновлено vo.x (Vit Ondruch) почти 3 года назад

Well, we don’t have PPC64 just PPC64LE on Fedora. I have run 5 builds and all passed just fine. Nevertheless, this is what glibc maintainers said about the issue 1:

(In reply to Florian Weimer from comment #17)

libio vtable verification fails because there are two copies of libc.so.6 in
the process:

0x00003fffb79413a8 — 0x00003fffb7941f78 is __libc_IO_vtables in
/lib64/power8/libc.so.6
0x00003fffb74213c0 — 0x00003fffb7421f90 is __libc_IO_vtables in
/lib64/libc.so.6

IO.pipe refers to a vtable from a the first copy, but the fprintf called via
libffi comes from the second copy.

The root cause is the Fiddle module loading libc.so.6 with an absolute path:

#0 __dlopen (file=0x20728280 «/lib64/libc.so.6», mode=257) at dlopen.c:75
#1 0x00003fffb748782c in rb_fiddle_handle_initialize (argc=,
argv=, self=544821280) at handle.c:179

This is an application defect.

If you’re using a path it’s expected you know what you’re loading.

One should be using ‘#include ‘ to get LIBC_SO and then dlopen that, it’s the only supported solution, particularly consider distributions >that might have /usr/lib64, or multi-arched lib dirs. You could be loading libc.so.6 from an incompatible ABI.

Loding by SONAME is the only safe option.

IOW, I don’t think there should be the path magic.

Источник

Installing nix: Fatal error: glibc detected an invalid stdio handle #2805

I have nuked /nix and want to reinstall, but I am hitting this:

Installation is obviously only partial.

This is a Debian unstable system, with libc6-2.28-5 .

The text was updated successfully, but these errors were encountered:

Installing 2.2.1 via

I believe I encountered the same issue, and that the 2.2.1 fix above also works.

I was running the install in a docker container using centos:latest.

Update: the 2.2.1 fix above does not work for me; the installation completes, but sourcing the profile script does not yield working nix-* commands. It seems to work as-is using a Debian base

I’ve run into the same problem just now on Debian Buster. Interestingly this method of installation does not work:

but this one does:

though both should install the same version of nix.

I get this error non-deterministically. I am installing the exact same version of Nix into a brand-new Vagrant machine, and it fails with this error some percentage of the time.

The version I’m installing is 2.2.2. I’m not using either of the curl or bashisms, but transferring the file to the server and running it directly. (Well, I’m doing it via ansible, but same thing.)

Further info: The VM is Centos 7, and i’m disabling sandboxing since user namespacing isn’t enabled by default there.

Last bit of info: I ran the installer 100 times in a row, and I hit this problem 4 times (4%).

They all look the same as OP’s report, except for a bit of extra info at the end. Maybe it’s nix-channel that is the source of the error?

If the problem really is with nix-channel, then this is effectively solved in 2.3 via b9567aa, which makes nix-channel —update errors non-fatal.

Yeah, I think this is solved in 2.3. I reran the installer another 100 times and got zero failures.

Источник

Fatal error: glibc detected an invalid stdio handle