Bug 821660
| Summary: | [abrt] autofs-5.0.6-16.fc17: clnt_dg_control: Process /usr/sbin/automount was killed by signal 11 (SIGSEGV) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Karel Volný <kvolny> | ||||||||||
| Component: | autofs | Assignee: | Ian Kent <ikent> | ||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 17 | CC: | ikent, law | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | abrt_hash:0e4c07f1264f1ebd0de031c3f4f28d6c6aa723eb | ||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-05-23 03:10:11 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: |
|
||||||||||||
|
Description
Karel Volný
2012-05-15 09:54:44 UTC
Created attachment 584617 [details]
File: backtrace
Created attachment 584618 [details]
File: maps
Created attachment 584619 [details]
File: var_log_messages
Mmmm ... there does appear to be an assumption in create_client() that when one of the calls to rpc_do_create_client() gets a zero return it implies the RPC client is non-null which might not be the case. As a quick check we could try a change to account for that, if your willing that is. I was unable to duplicate this on F16, but was able to on and F17 beta install. Try this build: https://koji.fedoraproject.org/koji/buildinfo?buildID=319139 The problem appears to be a combination of a passed stack variable being non-null and getaddrinfo(3) not returning a lookup failure on a name that obviously has no valid translation. Created attachment 584895 [details]
Patch - fix initialization in rpc create_client()
(In reply to comment #5) > Try this build: > https://koji.fedoraproject.org/koji/buildinfo?buildID=319139 ok, installed how do I test that the problem is gone? (In reply to comment #7) > (In reply to comment #5) > > Try this build: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=319139 > > ok, installed > > how do I test that the problem is gone? That's a good question and I don't have a good answer. The problem is I don't actually know what the root cause is but I believe it is with getaddrinfo(3), either the way it works for the call setup I use has changed or its behaviour has become broken in some way. But this same call setup has been working fine for quite a long time now. On an F17 beta install it works fine for me and I can't get it to fail other than feeding it an obviously bogus name. But for another person who reported this it appears to fail every time and the change here just prevents the SEGV when getaddrinfo(3) incorrectly fails (ie. returns success for a name lookup but returns no name records). I could detect this type of failure and attempt to use a different RPC client create function but I think that will have side effects for other autofs functionality. So I'm not sure yet what to do. Bottom line is all you for me to test is to use it for a while wait until the problem re-occurs. I'm not sure how we can get more information about the failure yet either so I'll think about that in the mean time. Ian I think I've resolved this in another bug, see bug 821847. If you agree I'll mark this a duplicate of that bug and finish the update using that bug instead of this one. (In reply to comment #9) > I think I've resolved this in another bug, see bug 821847. > > If you agree I'll mark this a duplicate of that bug and > finish the update using that bug instead of this one. np, as long as abrt is able to redirect (as for me, looks like I'm going to completely forget that this one exists before it crashes again ... :-)) (In reply to comment #10) > (In reply to comment #9) > > I think I've resolved this in another bug, see bug 821847. > > > > If you agree I'll mark this a duplicate of that bug and > > finish the update using that bug instead of this one. > > np, as long as abrt is able to redirect I guess we'll find out then, ;) *** This bug has been marked as a duplicate of bug 821847 *** |