1 |
The first change worth mentioning would be the new sanity checking. A |
2 |
copy and paste from fedora's release notes: |
3 |
|
4 |
The version of glibc provided with [glibc-2.3.4.10041021.ebuild] |
5 |
performs additional internal sanity checks to prevent and detect data |
6 |
corruption as early as possible. By default, should corruption be |
7 |
detected, a message similar to the following will be displayed on |
8 |
standard error (or logged via syslog if stderr is not open): |
9 |
|
10 |
*** glibc detected *** double free or corruption: 0x0937d008 *** |
11 |
|
12 |
By default, the program that generated this error will also be killed; |
13 |
however, this (and whether or not an error message is generated) can be |
14 |
controlled via the MALLOC_CHECK_ environment variable. The following |
15 |
settings are supported: |
16 |
|
17 |
* 0 — Do not generate an error message, and do not kill the program |
18 |
* 1 — Generate an error message, but do not kill the program |
19 |
* 2 — Do not generate an error message, but kill the program |
20 |
* 3 — Generate an error message and kill the program |
21 |
|
22 |
|
23 |
Note that this change will expose bugs in applications themselves, and |
24 |
bug reports should go to the application's maintainer, not |
25 |
toolchain@g.o... Though I guess it was a tad bit rude of me not |
26 |
to give everyone a heads-up earlier. ^^; |
27 |
|
28 |
Applications known to fail with the new sanity checking: |
29 |
|
30 |
1) gtksee on at least amd64 (invalid pointer) |
31 |
2) xorg-x11 6.8 on ppc -only- if you are using the composite extension |
32 |
(double free) (lu_zero, correct me if i'm wrong here... also, was there |
33 |
any progress on fixing this with ajax?) |
34 |
?) probably more but that's all I remember. jhuebel has mentioned one or |
35 |
two others, but I have forgotten them. :/ |
36 |
|
37 |
We could probably make the malloc check default to just printing an |
38 |
error if enough people are bothered by this change, but I really don't |
39 |
like that idea. Uncovering potentially nasty bugs is usually a good |
40 |
thing, and that's what this change does. |
41 |
|
42 |
|
43 |
Next up on the list of things I really should have mentioned earlier is |
44 |
a change in how .local is handled. Another paste, this time from the |
45 |
suse release notes: |
46 |
|
47 |
Change in Resolver Library |
48 |
|
49 |
Incompatible change: the resolver library treats the .local top level |
50 |
domain as link-local domain and sends multicast DNS requests to the |
51 |
multicast address 224.0.0.251 port 5353 instead of normal DNS requests. |
52 |
If you already use the .local domain in your nameserver configuration |
53 |
you will have to switch to another domain name. See |
54 |
http://www.multicastdns.org for more information on multicast DNS. |
55 |
|
56 |
|
57 |
It was also rude of me not to mention this before, as it seems to have |
58 |
upset a couple of users. Instead of applying the multicast dns updates |
59 |
unconditionally like suse does, we could make this logic USE-dependant. |
60 |
Suse 9.2 seems to have a method to enable/disable the mdns change, |
61 |
however, so I'll probably look at what's different soon-ish... I would |
62 |
certainly prefer a runtime solution over a compile-time one. If anyone |
63 |
is more familiar with suse than myself and can point me at docs (I cant |
64 |
find the 9.2 release notes... only the livecd is out) or give me a |
65 |
heads-up, that would also be appreciated. :) |
66 |
|
67 |
|
68 |
For anyone starting to worry, the multicast dns and sanity checking |
69 |
changes are not in any ebuild ---currently in the tree--- other than |
70 |
2.3.4.20041021, and this ebuild is marked as testing/unstable on all |
71 |
archs it is keyworded for. The problem with how .local is handled with |
72 |
the multicast dns patch needs to be thought out before this ebuild hits |
73 |
stable, and a few applications will also need a little work. |
74 |
|
75 |
Feedback and testing are appreciated, as always. :) |
76 |
|
77 |
|
78 |
Travis Tilley |
79 |
|
80 |
-- |
81 |
gentoo-dev@g.o mailing list |