Gentoo Archives: gentoo-dev

From: Travis Tilley <lv@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] a few more -major- glibc changes worth noting
Date: Thu, 28 Oct 2004 22:47:03
Message-Id: 418176E5.6060107@gentoo.org
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

Replies