<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/glibc.git, branch pasky/fixes-overdue</title>
<subtitle>sourceware.org: git/glibc.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/'/>
<entry>
<title>Fix incorrect backtrace unwinding through thread_start() on x86_64</title>
<updated>2010-11-16T02:47:22+00:00</updated>
<author>
<name>Jan Kratochvil</name>
<email>jan.kratochvil@redhat.com</email>
</author>
<published>2010-11-16T02:47:22+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=fb8fb8464c2b5a44b69e62bcc3211b9c769416da'/>
<id>fb8fb8464c2b5a44b69e62bcc3211b9c769416da</id>
<content type='text'>
Provide CFI for the outermost clone() to ensure proper unwinding stop
of gdb.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Provide CFI for the outermost clone() to ensure proper unwinding stop
of gdb.
</pre>
</div>
</content>
</entry>
<entry>
<title>Allow aux_cache_file open()ing to fail silently even in the chroot mode.</title>
<updated>2010-11-16T02:39:24+00:00</updated>
<author>
<name>Petr Baudis</name>
<email>pasky@suse.cz</email>
</author>
<published>2010-11-16T02:35:47+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=c8e6e9e783bc5018525e881f021333c3daa4b0f6'/>
<id>c8e6e9e783bc5018525e881f021333c3daa4b0f6</id>
<content type='text'>
The aux_cache fix of bug 11149 introduced a new bug - normally,
ldconfig -r never cares if the auxiliary cache is not available and
that is not a fatal problem, however this is not the case in case
of ldconfig -r when executed as non-root. In that case, ldconfig -r
fails hard unless var/cache/ldconfig/ exists within the chroot. This
patch fixes that.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The aux_cache fix of bug 11149 introduced a new bug - normally,
ldconfig -r never cares if the auxiliary cache is not available and
that is not a fatal problem, however this is not the case in case
of ldconfig -r when executed as non-root. In that case, ldconfig -r
fails hard unless var/cache/ldconfig/ exists within the chroot. This
patch fixes that.
</pre>
</div>
</content>
</entry>
<entry>
<title>Make nscd load /etc/host.conf options in aicache</title>
<updated>2010-11-16T01:50:21+00:00</updated>
<author>
<name>Petr Baudis</name>
<email>pasky@ucw.cz</email>
</author>
<published>2010-08-22T14:15:17+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=b321e863ac162595250446a3b107384dc7aecd89'/>
<id>b321e863ac162595250446a3b107384dc7aecd89</id>
<content type='text'>
This patch makes sure _res_hconf is initialized before resolving is being done.

However, this would not be enough since nscd has its own _res_hconf due to
nscd/res_hconf.c; _res_hconf_init() would work on different _res_hconf instance
than the NSS routines. We just need to make sure nscd and glibc share the same
_res_hconf instance - this should not be a problem since users should run
matching versions of glibc and nscd anyway.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch makes sure _res_hconf is initialized before resolving is being done.

However, this would not be enough since nscd has its own _res_hconf due to
nscd/res_hconf.c; _res_hconf_init() would work on different _res_hconf instance
than the NSS routines. We just need to make sure nscd and glibc share the same
_res_hconf instance - this should not be a problem since users should run
matching versions of glibc and nscd anyway.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix multiple nss_compat initgroups() bugs</title>
<updated>2010-11-16T01:50:20+00:00</updated>
<author>
<name>Petr Baudis</name>
<email>pasky@ucw.cz</email>
</author>
<published>2010-08-22T14:37:10+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=b9be604a7bcffd1fa5fc0141c0dfd2ddcbf09451'/>
<id>b9be604a7bcffd1fa5fc0141c0dfd2ddcbf09451</id>
<content type='text'>
Compat initgroups() is completely broken; the code will always set
skip_initgroups_dyn to true, so initgroups() will never be actually
called, but due to the nature of the code, setgrent() won't be called
either - thus, subsequent invocations of initgroups() will not return
the NIS group list anymore.

This is a simple patch that makes sure skip_initgroups_dyn is set only
in case initgroups is not available; it also attempts to handle the
unavailability of other NSS interfaces better.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Compat initgroups() is completely broken; the code will always set
skip_initgroups_dyn to true, so initgroups() will never be actually
called, but due to the nature of the code, setgrent() won't be called
either - thus, subsequent invocations of initgroups() will not return
the NIS group list anymore.

This is a simple patch that makes sure skip_initgroups_dyn is set only
in case initgroups is not available; it also attempts to handle the
unavailability of other NSS interfaces better.
</pre>
</div>
</content>
</entry>
<entry>
<title>Add proper unwind information for x86_64 _fini</title>
<updated>2010-11-16T01:50:19+00:00</updated>
<author>
<name>Michael Matz</name>
<email>matz@suse.de</email>
</author>
<published>2010-08-22T14:53:24+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=31eb5a4c4986367538ccb154dfce0c84276ba151'/>
<id>31eb5a4c4986367538ccb154dfce0c84276ba151</id>
<content type='text'>
It is impossible to reliably unwind the stack above _fini() on x86_64 since no
unwind information is provided for it and it modifies a stack register. This
matters for gdb backtracing - if a process crashes within a destructor, it can
frequently be essential to look at why the program began terminating in the
first place.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is impossible to reliably unwind the stack above _fini() on x86_64 since no
unwind information is provided for it and it modifies a stack register. This
matters for gdb backtracing - if a process crashes within a destructor, it can
frequently be essential to look at why the program began terminating in the
first place.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix jn() precision problems around zero points of j0()</title>
<updated>2010-11-16T01:50:16+00:00</updated>
<author>
<name>Petr Baudis</name>
<email>pasky@ucw.cz</email>
</author>
<published>2010-08-22T14:44:15+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=9fcff7a79b60cd9202fdacafdbd5fb369933c64b'/>
<id>9fcff7a79b60cd9202fdacafdbd5fb369933c64b</id>
<content type='text'>
There appears to be a really nasty bug in jn() from fdlibm, which is
the foundation for most libm implementations (including glibc libm).
The zeroth-order j0() and first-order j1() cylindrical Bessel functions
are used to recursively generate the jn() value, but only the zeroth-order
Bessel function is used to normalize it; however, each of the functions
gets highly imprecise (approaching "bogus") near its zero point, making
the jn() value itself bogus.

But in fact, the zero points of j0() and j1() never coincide, thus j1()
should be used in case it is more precise than j0(). (That is, simply
when its value is further from zero.)

As an example, 2.4048255576957729_8 is the first zero of j0().
The proper value as calculated by Mathematica is 0.19899990535769...
However, jn() returns -inf on 64-bit arch, or 0.185007 on 32-bit arch.
With the proposed patch below, the returned value is 0.199000.

The fix is based on work by Steve Kargl and Tobias Burnus.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There appears to be a really nasty bug in jn() from fdlibm, which is
the foundation for most libm implementations (including glibc libm).
The zeroth-order j0() and first-order j1() cylindrical Bessel functions
are used to recursively generate the jn() value, but only the zeroth-order
Bessel function is used to normalize it; however, each of the functions
gets highly imprecise (approaching "bogus") near its zero point, making
the jn() value itself bogus.

But in fact, the zero points of j0() and j1() never coincide, thus j1()
should be used in case it is more precise than j0(). (That is, simply
when its value is further from zero.)

As an example, 2.4048255576957729_8 is the first zero of j0().
The proper value as calculated by Mathematica is 0.19899990535769...
However, jn() returns -inf on 64-bit arch, or 0.185007 on 32-bit arch.
With the proposed patch below, the returned value is 0.199000.

The fix is based on work by Steve Kargl and Tobias Burnus.
</pre>
</div>
</content>
</entry>
<entry>
<title>nscd/hstcache.c: Propagate TRY_AGAIN properly to the clients.</title>
<updated>2010-11-16T01:38:24+00:00</updated>
<author>
<name>Jan Sembera</name>
<email>jsembera@suse.cz</email>
</author>
<published>2010-08-22T13:43:46+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=75134e46476263ab116be341531cadb1e6ab87d6'/>
<id>75134e46476263ab116be341531cadb1e6ab87d6</id>
<content type='text'>
When nscd host cache gets temporary error from nss, it should return
temporary error instead of permanent error to the application.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When nscd host cache gets temporary error from nss, it should return
temporary error instead of permanent error to the application.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix memory leak in fnmatch</title>
<updated>2010-11-12T08:51:28+00:00</updated>
<author>
<name>Andreas Schwab</name>
<email>schwab@redhat.com</email>
</author>
<published>2010-11-12T08:51:28+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=3540d66b669af54900b2e4bfc0ab82960e84a471'/>
<id>3540d66b669af54900b2e4bfc0ab82960e84a471</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Support Intel processor model 6 and model 0x2.</title>
<updated>2010-11-12T08:48:52+00:00</updated>
<author>
<name>H.J. Lu</name>
<email>hongjiu.lu@intel.com</email>
</author>
<published>2010-11-12T08:48:52+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=13b695749acf88139a2ce1ed2c949e0e64300a9b'/>
<id>13b695749acf88139a2ce1ed2c949e0e64300a9b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix comparison in sqrtl for IBM long double 128.</title>
<updated>2010-11-10T21:15:05+00:00</updated>
<author>
<name>Luis Machado</name>
<email>luisgpm@br.ibm.com</email>
</author>
<published>2010-11-10T21:15:05+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/glibc.git/commit/?id=da93d21475878725c9e0cb2b6e650bd8d3628435'/>
<id>da93d21475878725c9e0cb2b6e650bd8d3628435</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
