Bug 10985
Summary: | smp, pthreads and stdio | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | simra |
Component: | kernel | Assignee: | Michael K. Johnson <johnsonm> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.2 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-05-02 18:20:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
simra
2000-04-22 13:42:05 UTC
Note: I have since reimplemented the program using open(2) and read(2) and the program does not abort- therefore the problem is with fgets in libc. Also, I have seen this problem with the gnu extension 'getline'. I'm posting some addition comments from Ulrich Drepper re my bug report to the libc people. A second individual was unable to reproduce the bug with libc-2.1.2 and his own custom-built 2.2.14 kernel. I'm beginning to wonder if it's a problem with the RH prebuilt SMP kernel or a HW problem. If it's a HW problem it's not specific to a single machine- I can reproduce the bug on 10 identical machines in our lab. Date: 30 Apr 2000 12:18:50 -0700 Subject: Re: libc/1706: libpthread, multiprocessor linux and fgets/getline Robert Sim <simra.ca> writes: > >Description: > > Compile the program supplied below as per the comment line and execute on a > multi-processor machine. It will eventually abort on the abort() instruction > because fgets failed to read the expected bytes into the buffer (in spite of > returning a success). The program executes fine on a single-processor > machine, and also works fine if I replace fopen and fgets with the equivalent > open(2) and read(2) calls. I have also observed this behaviour using the gnu > getline extension. I cannot reproduce this. The setup is almost identical. The only notable difference is that I'm using a 2.3.99pre6 kernel. I have the process running for more than an hour and everything works fine. RESOLVED: by upgrading the kernel to 2.2.14-6.1.1 it disturbs me that redhat is doing its own kernel patches- I can't report a bug like this to the linux-kernel people because I'm not using a standard 2.2.14 kernel but some specially patched version of 2.2.14. And yes there are folks at Red Hat who deal with both RH and standard tree bugs. We pretty much have to ship a non default tree |