Bug 684980
| Summary: | calling guestfs_kill_subprocess() then guestfs_close() causes a lockup in some applications | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Angus Salkeld <asalkeld> | ||||||||
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 6.1 | CC: | jzheng, leiwang, sdake | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | libguestfs-1.7.17-23.el6 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2011-12-06 10:31:23 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: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 484320 [details]
tentative fix for the problem
The patch has not been tested, but looks like the solution to the problem.
The patch is upstream: http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=6f7c1a9f9d76bdf9f112e12e1508531fb41abfb2 but has not been properly tested. Angus, please test this and also provide some sort of easy(-ish) test that QA can perform to verify that it is fixed in RHEL 6.2. A small snippet of C code which fails before and succeeds after would be ideal. (In reply to comment #4) > Angus, please test this and also provide some sort of easy(-ish) > test that QA can perform to verify that it is fixed in RHEL 6.2. Already attached is a python test case, super easy to run. just edit and replace my iso with what ever iso you have then if it locks up - FAIL, if it exits nicely the PASS. > A small snippet of C code which fails before and succeeds after > would be ideal. I have tested and it seems I missed a "if (pid > 0)". I will attach an extra patch that makes my test case pass. Created attachment 484445 [details]
second patch (both needed) to fix bug.
For triaging purposes. Both patches are upstream since mid-March: 6f7c1a9f9d76bdf9f112e12e1508531fb41abfb2 d1f1f74e5f45fa5b94ebb096fa65fa33ecc23d09 Both patches are included in: https://brewweb.devel.redhat.com/taskinfo?taskID=3544452 Reproduced on libguestfs-1.7.17-19 running the forker test. $ python forker.py qpidd(14137) is running 2011-08-29 11:16:28 notice SASL disabled: No Authentication Performed 2011-08-29 11:16:28 notice Listening on TCP port 49000 2011-08-29 11:16:28 notice Broker running The program hangs here. Verified on libguestfs-1.7.17-26 that the test could exit without hang. $ python forker.py qpidd(14023) is running 2011-08-29 11:06:04 notice SASL disabled: No Authentication Performed 2011-08-29 11:06:04 notice Listening on TCP port 49000 2011-08-29 11:06:04 notice Broker running 2011-08-29 11:06:08 notice Shut down qpidd(14023) exited with 0 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1512.html |
Created attachment 484319 [details] test application Description of problem: libquestfs can call waitpid(0,..) causing it to wait on all child processes (including processes started by the application). Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. exec a process 2. start a guestfs session 3. call kill_subprocesses() 4. call 'del g_obj' Actual results: my test application blocks in a waitpid(0,..) call Expected results: it should not cause my application to block Additional info: I'll attach a test application and patch.