Bug 84222
| Summary: | kernel-2.4.20-2.47.1 + testsuite from gdb-5.3post-0.20021129.11 = bad juju | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Tim Powers <timp> |
| Component: | gdb | Assignee: | Elena Zannoni <ezannoni> |
| Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | ezannoni, roland, sopwith |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-21 18:51:46 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 79578 | ||
|
Description
Tim Powers
2003-02-13 17:21:52 UTC
please "kill -8 PID" the runaway process and look at the backtrace in
"gdb -c core.PID", does that help?
("ulimit -c 1000000" as well, default coredump size might be 0)
It's going to take a while to do this on the machine I saw the problem on (there's a lot happening on that machine right now), but I'm trying. Just starting the rebuild of the package is taking a very long time. If you want to reproduce this just try rebuilding the gdb-5.3post-0.20021129.11 package on a machine which is running 2.4.20-2.47.1. do this on perf53 to reproduce the failure (as root, in the /root directory): # /tmp/attach2.1414 & [1] 14152 # gdb (gdb) attach 14152 (gdb) s should_exit=1 Program received signal SIGSTOP, Stopped (signal). sometimes a 'c' has to be done, and the bogus SIGSTOP message is displayed then. This is clearly a SIGCONT/SIGSTOP or ptrace bogosity. I did already create a gdb bug for this. 84220. I disabled the tests in the gdb-5.3post-0.20021129.12 build, so this shouldn't affect you guys any more. It is gdb's fault that it doesn't clean after itself if something goes wrong during the test. The reason that this didn't happen with older kernels (pre NPTL) is that now there is an extra SIGSTOP after attaching to a process, and gdb doesn't handle that properly. This screws up the whole test sequence. So I am going to close this. OK? *** This bug has been marked as a duplicate of 84220 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |