This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Mark Kettenis <kettenis@wins.uva.nl> writes: > Hmm, strange. I have been running netscape 4.72 standalone with the > new resolver from time to time the past days, and it seems to be > running fine, even better than with glibc 2.1.3 (or am I just > imagining that?). It's very simple. In a program using _res directly (netscape is doing that) you have somewhere in the memory: _res: .space old__res_size some_other_var: .word The resolver in libc/libresolv has a different size for _res which is greater than old__res_size. Therefore ld.so issues a warning and copies only the first old__res_size bytes (since it knows it would overwrite other data if more would be copied). Now the code in libc is accessing areas in the _res variable (the copy in the program) which are beyond the old size. This can lead to undefined results. It might also modify this memory areas which would result in changes to the some_other_var (or a var following it). If you don't see crashes you are only lucky. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |