The first change worth mentioning would be the new sanity checking. A
copy and paste from fedora's release notes:
The version of glibc provided with [glibc-2.3.4.10041021.ebuild]
performs additional internal sanity checks to prevent and detect data
corruption as early as possible. By default, should corruption be
detected, a message similar to the following will be displayed on
standard error (or logged via syslog if stderr is not open):
*** glibc detected *** double free or corruption: 0x0937d008 ***
By default, the program that generated this error will also be killed;
however, this (and whether or not an error message is generated) can be
controlled via the MALLOC_CHECK_ environment variable. The following
settings are supported:
* 0 — Do not generate an error message, and do not kill the program
* 1 — Generate an error message, but do not kill the program
* 2 — Do not generate an error message, but kill the program
* 3 — Generate an error message and kill the program
Note that this change will expose bugs in applications themselves, and
bug reports should go to the application's maintainer, not
toolchain@gentoo.org... Though I guess it was a tad bit rude of me not
to give everyone a heads-up earlier. ^^;
Applications known to fail with the new sanity checking:
1) gtksee on at least amd64 (invalid pointer)
2) xorg-x11 6.8 on ppc -only- if you are using the composite extension
(double free) (lu_zero, correct me if i'm wrong here... also, was there
any progress on fixing this with ajax?)
?) probably more but that's all I remember. jhuebel has mentioned one or
two others, but I have forgotten them. :/
We could probably make the malloc check default to just printing an
error if enough people are bothered by this change, but I really don't
like that idea. Uncovering potentially nasty bugs is usually a good
thing, and that's what this change does.
Next up on the list of things I really should have mentioned earlier is
a change in how .local is handled. Another paste, this time from the
suse release notes:
Change in Resolver Library
Incompatible change: the resolver library treats the .local top level
domain as link-local domain and sends multicast DNS requests to the
multicast address 224.0.0.251 port 5353 instead of normal DNS requests.
If you already use the .local domain in your nameserver configuration
you will have to switch to another domain name. See
http://www.multicastdns.org for more information on multicast DNS.
It was also rude of me not to mention this before, as it seems to have
upset a couple of users. Instead of applying the multicast dns updates
unconditionally like suse does, we could make this logic USE-dependant.
Suse 9.2 seems to have a method to enable/disable the mdns change,
however, so I'll probably look at what's different soon-ish... I would
certainly prefer a runtime solution over a compile-time one. If anyone
is more familiar with suse than myself and can point me at docs (I cant
find the 9.2 release notes... only the livecd is out) or give me a
heads-up, that would also be appreciated. :)
For anyone starting to worry, the multicast dns and sanity checking
changes are not in any ebuild ---currently in the tree--- other than
2.3.4.20041021, and this ebuild is marked as testing/unstable on all
archs it is keyworded for. The problem with how .local is handled with
the multicast dns patch needs to be thought out before this ebuild hits
stable, and a few applications will also need a little work.
Feedback and testing are appreciated, as always. :)
Travis Tilley
--
gentoo-dev@gentoo.org mailing list
copy and paste from fedora's release notes:
The version of glibc provided with [glibc-2.3.4.10041021.ebuild]
performs additional internal sanity checks to prevent and detect data
corruption as early as possible. By default, should corruption be
detected, a message similar to the following will be displayed on
standard error (or logged via syslog if stderr is not open):
*** glibc detected *** double free or corruption: 0x0937d008 ***
By default, the program that generated this error will also be killed;
however, this (and whether or not an error message is generated) can be
controlled via the MALLOC_CHECK_ environment variable. The following
settings are supported:
* 0 — Do not generate an error message, and do not kill the program
* 1 — Generate an error message, but do not kill the program
* 2 — Do not generate an error message, but kill the program
* 3 — Generate an error message and kill the program
Note that this change will expose bugs in applications themselves, and
bug reports should go to the application's maintainer, not
toolchain@gentoo.org... Though I guess it was a tad bit rude of me not
to give everyone a heads-up earlier. ^^;
Applications known to fail with the new sanity checking:
1) gtksee on at least amd64 (invalid pointer)
2) xorg-x11 6.8 on ppc -only- if you are using the composite extension
(double free) (lu_zero, correct me if i'm wrong here... also, was there
any progress on fixing this with ajax?)
?) probably more but that's all I remember. jhuebel has mentioned one or
two others, but I have forgotten them. :/
We could probably make the malloc check default to just printing an
error if enough people are bothered by this change, but I really don't
like that idea. Uncovering potentially nasty bugs is usually a good
thing, and that's what this change does.
Next up on the list of things I really should have mentioned earlier is
a change in how .local is handled. Another paste, this time from the
suse release notes:
Change in Resolver Library
Incompatible change: the resolver library treats the .local top level
domain as link-local domain and sends multicast DNS requests to the
multicast address 224.0.0.251 port 5353 instead of normal DNS requests.
If you already use the .local domain in your nameserver configuration
you will have to switch to another domain name. See
http://www.multicastdns.org for more information on multicast DNS.
It was also rude of me not to mention this before, as it seems to have
upset a couple of users. Instead of applying the multicast dns updates
unconditionally like suse does, we could make this logic USE-dependant.
Suse 9.2 seems to have a method to enable/disable the mdns change,
however, so I'll probably look at what's different soon-ish... I would
certainly prefer a runtime solution over a compile-time one. If anyone
is more familiar with suse than myself and can point me at docs (I cant
find the 9.2 release notes... only the livecd is out) or give me a
heads-up, that would also be appreciated. :)
For anyone starting to worry, the multicast dns and sanity checking
changes are not in any ebuild ---currently in the tree--- other than
2.3.4.20041021, and this ebuild is marked as testing/unstable on all
archs it is keyworded for. The problem with how .local is handled with
the multicast dns patch needs to be thought out before this ebuild hits
stable, and a few applications will also need a little work.
Feedback and testing are appreciated, as always. :)
Travis Tilley
--
gentoo-dev@gentoo.org mailing list