| Summary: | Bug in resolv patch | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Joshua Rogers <honey> | ||||
| Component: | devtools / tool chain | Assignee: | Khem Raj <raj.khem> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | alexandru.c.georgescu, meta.mr.watcher, meta.watcher, raj.khem, rongqing.li, ross.burton | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 2.4 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
|
Description
Joshua Rogers
2015-08-02 02:32:41 UTC
Joshua Rogers: I see you suggest a fix for this patch, to replace __res_vinit() with res_query() , does it merged into ubuntu, or acceptable? Created attachment 2663 [details]
Bug fix
Hi, My fixis to, inside the res_init() function, replace the call to __res_vinit with __res_maybe_init, while setting something that ensures that __res_maybe_init will always init. As it is, res_init() is only called in two places within the eglibc code. Once in a memory leak test, http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/resolv/tst-leaks2.c?annotate=24942#l31 and in the local_hostname_function, http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/resolv/res_data.c?annotate=23297#l311 Other than that, res_init is a dead function, other than at the user-level. The manual says to use res_init(), and not __res_maybe_init()[which I assume wouldn't work at user-level anyways], making it a problem. I also have just now noticed that the mtime is not set unless (resp->options & RES_INIT) is true, so I've added the appropriate code to res_libc.c too. res_init() in res_data.c file is only used if _LIBC is not defined. But I added a fix for that too. Funnily enough, in res_libc.c's res_init() function, it does this: atomicinclock (lock); /* Request all threads to re-initialize their resolver states, resolv.conf might have changed. */ atomicinc (__res_initstamp); atomicincunlock (lock); however that would only do something, if __res_maybe_init was called, and (resp->options & RES_INIT) was true. So really, there's 2 bugs in 1. Anyways, let me know what you think of the patch. If you think it is OK, I'll submit to to Ubuntu/Debian too. Noting however, that eglibc is EOL'd, and Ubuntu has stopped using it in 15.04. It is still being used in 14.04.1 LTS, which is set to EOL April 2019. Likewise, Ubuntu 12.04.5 is set to EOL in April 2017, and it uses it too. Thanks, I've attached my suggestion patch. Do you still see this bug with glibc 2.24 ? eglibc is dead now. I think I am in favor of removing this patch. Update: we still have this in glibc 2.5. Khem, can you look at it again and either upstream or remove it? See Ross' question so far it seems we still need it. It appears the question has been answered. upcoming glibc 2.26 has reworked resolv code a bit and specifically addressed this issue https://sourceware.org/bugzilla/show_bug.cgi?id=984 which was long standing in glibc. We will have glibc 2.26 in 2.4 release. glibc 2.26 rc has landed in master |