r944 - glibc-package/trunk/debian/sysdeps
Author: gotom
Date: 2005-07-15 12:18:04 + (Fri, 15 Jul 2005)
New Revision: 944
Modified:
glibc-package/trunk/debian/sysdeps/depflags.pl
Log:
Add the correct Replaces: libc6-prof to libc6-dev, not libc6.
Modified: glibc-package/trunk/debian/sysdeps/depflags.pl
===
--- glibc-package/trunk/debian/sysdeps/depflags.pl 2005-07-14 15:28:23 UTC
(rev 943)
+++ glibc-package/trunk/debian/sysdeps/depflags.pl 2005-07-15 12:18:04 UTC
(rev 944)
@@ -141,7 +141,7 @@
# Replace libc-dev ( 2.3.2.ds1-14) for fixing #239170.
# Replace libc-dev ( 2.3.5-2) for fixing #280030.
-push @{$libc_c{'Replaces'}}, ${libc}-dev ( 2.3.5-2);
+push @{$libc_dev_c{'Replaces'}}, ${libc}-prof ( 2.3.5-2);
# Conflict old initrd-tools ( 0.1.79) that cannot work with new ldd.
push @{$libc_c{'Conflicts'}}, 'initrd-tools ( 0.1.79)';
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
Very simple: gethostbyname() returns a struct hostent * for which the
C library has to allocate some internal memory. However,
POSIX/SUS/etc. does not define any API to tell the C library that the
returned pointer is no longer needed, so the allocated memory cannot be
freed by the C library until the next call to gethostbyname().
Solution: do not use the gethostby* functions. Use get{addr|name}info()
instead, they do not have this API problem (and have other advantages
as well).
Florian and Gabor -- thanks! Gabor, I am using gethostbyname for portability
reasons, since some systems may lack the other APIs, but it indeed would be
good then to add a code path that uses the abovementioned functions, which I
recently became aware of myself.
Finally -- when the program is:
#include stdlib.h
#include netdb.h
int main()
{
stuct hostent* hi = gethostbyname(www.google.com);
free(hi);
return 0;
}
the number of leaks reported does not change (nor other errors appear) so it
seems that it is not the hostent structure that causes this, but rather some
other state that gethostbyname keeps. Note that mudflap prints the leak
report at program termination.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
* Vesselin Peev:
This is not a problem, unless this number grows with each
gethostbyname invocation. The underlying programming pattern which
causes this is quite common and perfectly harmless (if you get the
threading issues right, of coruse).
Just tested it in a loop, the leaks stay constant.
Fine, thanks.
If you are saying the underlying programming pattern is quite common
and harmless, that does not also mean that the leaks are
non-existent and mudflap is confused, right?
Yes. AFAIK, mudflap does not perform pointer tracing (unlike
valgrind). Therefore, it cannot detect if heap objects which are
allocated when the program terminates are still reachable, which is
the case here.
Could you please elucidate what is this programming pattern that
causes the leaks, if it is possible to do with a programming
snippet?
A variable at global scope which points to an object allocated on the
heap, for example:
static char *name = NULL;
void
set_name (char *n)
{
free (name);
name = strdup (n);
}
There's no need to free name at program termination because the kernel
will do it for you anyway.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317861: conflicting definitions of P_ALL, P_PID, and P_PGID
On Thu, Jul 14, 2005 at 09:31:24PM -0700, Matt Kraai wrote: On Thu, Jul 14, 2005 at 02:42:23PM -0400, Daniel Jacobowitz wrote: On Mon, Jul 11, 2005 at 09:47:11AM -0700, Matt Kraai wrote: Package: libc6-dev Version: 2.3.2.ds1-22 Severity: serious kbd-chooser fails to build because the definitions of P_ALL, P_PID, and P_PGID in /usr/include/sys/wait.h conflict with those in /usr/include/linux/wait.h: cc -c -Wall -I. -DNDEBUG=1 -fomit-frame-pointer -Os -DAT_KBD -DUSB_KBD loadkeys.c In file included from /usr/include/debian-installer/exec.h:29, from /usr/include/debian-installer.h:5, from loadkeys.y:24: /usr/include/sys/wait.h:100: error: syntax error before numeric constant loadkeys.y: In function 'addfunc': loadkeys.y:595: warning: comparison is always false due to limited range of data type make[1]: *** [loadkeys.o] Error 1 make[1]: Leaving directory `/tmp/buildd/kbd-chooser-1.15' make: *** [build-stamp] Error 2 Where is linux/wait.h being included from? Is it necessary? loadkeys.y includes linux/keyboard.h, which includes linux/wait.h. loadkeys.y does use some of the macros defined in linux/keyboard.h, so it seems like it should include it. linux/keyboard.h does not appear to use anything from linux/wait.h, though, so I'm not sure why it includes it. linux/keyboard.h is definitely one of the headers I would recommend not including. The network headers are generally safe, but that's about it. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
On Fri, Jul 15, 2005 at 05:10:09PM +0300, Vesselin Peev wrote: I know the problem is not present with valgrind on Debian, too, so the above then holds for the Debian libc package, too. From his words one can conclude that there must be a better integration between mudflap and glibc. Well, I know nothing about mudflap, but valgrind calls __libc_freeres() at program termination to avoid internal data allocated by glibc being reported as leaks. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318429: libc6.1-dev: failure with g++-4.0 caused by ucontext.h
Package: libc6.1-dev Version: 2.3.2.ds1-22 Severity: serious Hello, ucontext.h has a faulty struct definition on ia64, see http://buildd.debian.org/fetch.php?pkg=icewmver=1.2.21%2B1.2.22pre2-1arch=ia64stamp=1121106846file=logas=raw for details. Error message: /usr/include/sys/ucontext.h:49: error: array bound is not an integer constant g++-3.x seems to permit this, 4.0 does not. Regards, Eduard. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: ia64 Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-dsa-itanium-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6.1-dev depends on: ii libc6.1 2.3.2.ds1-22 GNU C Library: Shared libraries an ii linux-kernel-headers2.6.12.0-1 Linux Kernel Headers for developme Versions of packages libc6.1-dev recommends: ii gcc [c-compiler] 4:4.0.0-2 The GNU C compiler ii gcc-2.96 [c-compiler] 1:2.96-9 The GNU C compiler ii gcc-3.2 [c-compiler] 1:3.2.3-9 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-7 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.4-5The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.0-12 The GNU C compiler -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
On Thu, Jul 14, 2005 at 10:17:32PM +0300, Vesselin Peev wrote:
Could you please elucidate what is this programming pattern that causes the
leaks, if it is possible to do with a programming snippet? I find it very
strange that a well-working program will have leaks that are considered
necessary because of a quite common usage pattern. Isn't there a better,
more perfect way?
Very simple: gethostbyname() returns a struct hostent * for which the
C library has to allocate some internal memory. However,
POSIX/SUS/etc. does not define any API to tell the C library that the
returned pointer is no longer needed, so the allocated memory cannot be
freed by the C library until the next call to gethostbyname().
Solution: do not use the gethostby* functions. Use get{addr|name}info()
instead, they do not have this API problem (and have other advantages
as well).
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#318244: segmentation fault with many files
Processing commands for [EMAIL PROTECTED]: reassign 318244 libc6 Bug#318244: segmentation fault with many files Bug reassigned from package `make' to `libc6'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Do you realize all your sexual dreams? Now you can!
Your favorite online pills store. http://eakux.wbzpife7b6wm0fw.sottedbbfhm.com Experience is a dear teacher, but fools will learn at no other. God does not care about our mathematical difficulties. He integrates empirically. Our lives teach us who we are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#318244: segmentation fault with many files
reassign 318244 libc6 thanks Hi, This does not seem to be something that changes in make are going to fix. make essentially makes a glob (3) call; and that library call is where the segmentation violation occurs. Considering that the number of entries in the directory are insanely high, this could be something that libc was not prepared for (memory exhausted?). Anyway, rassigning to the package where this can be addressed. manoj -- Most people would rather die than think; in fact, they do so. -Bertrand Russell Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
* Vesselin Peev: I'm thinking of submitting a wish about better handling, You could reuse this bug report (downgrade it to wishlist, reassign if necessary). if possible with the mudflap architecture, of internal data allocated by libc. Proper handling should of course include no unaccessed registered object warnings. Barring that, I'd request a mudflap option to suppress those warnings. What would you advise me? Mudflap needs some GNU libc interface to do this. __libc_freeres looks very internal. It's not documented, either. I believe it can go away in the next release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
Well, I know nothing about mudflap, but valgrind calls __libc_freeres()
at program termination to avoid internal data allocated by glibc being
reported as leaks.
Thanks for mentioning this, Gabor! I searched for more info about it, and
found it mentioned in the Valgrind FAQ, and also in the libstdc++
documentation. The latter says thankfully mentions how to use
__libc_freeres. Here's a possible revised version of the gethostbyname
snippet:
#include stdio.h
#include netdb.h
#include cstdlib
extern C void __libc_freeres();
int main()
{
atexit(__libc_freeres);
gethostbyname(www.google.com);
char *s = new char[100];
return 0;
}
After compiling it with mudflap on and the -print-leaks options on as well,
I got:
1 memory leak -- the one I deliberately introduced in the code!
The other, the erroneously reported ones, were gone for good!
However, there were many mudflap warning: unaccessed registered object
reports. Yet it seems they are benign -- registered object here means object
that is registered by mudflap itself. I cannot find a way to suppress those
warnings (no option in mudflap) but they all go away when I do not use
the -print-leaks option.
But still this is significant progress for my needs, since mudflap now shows
only *real* memory leaks! This is indeed much better!
I'm thinking of submitting a wish about better handling, if possible with
the mudflap architecture, of internal data allocated by libc. Proper
handling should of course include no unaccessed registered object
warnings. Barring that, I'd request a mudflap option to suppress those
warnings. What would you advise me?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
those college chicks don`t know anything Winnie
These are real amateurs who have webcams on their computers in their dorm rooms! This is not one of those porn sites with professional girls who get paid to do this in front of the camera, these are the average girls next door, at college, trying to make money and meet guys! It wont take you more then 1 minute to just check this out what are you waiting for? http://stankfinger.com/co25/ dyad you bed me web you casbah me bye you fudge me parenthood you bunsen me goat you gluey me jeopardy you buxton me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
D0wlnoadable 70+ XXX V1deos with P0RNSTARS - X64
We have the hottest Pornostars pics and videos inside. Thousands of new photo and clips, including Pornostars movies. See hot Pornostars videos now! Click here for http://baroness.net.wallkbaby.info/ cool photos and video clips and dvd movies -- chain coercible desk condition defendant bead autocorrelate asthma almost atlantes cordage cunning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Wanna see a nude college babe? Pearl
Do you want to see real amateurs who have webcams on their computers in their dorm rooms? This is not one of those sites with professional girls who get paid to do this in front of the camera, these are the average girls next door, at college, trying to make money and meet guys! Get free access to a huge database of hot college girls, unlimited cam shows with LIVE CHAT and there are no Pay-Per-Minute charges! http://smokeethebear.com/co25/ battle you connive me judge you guiding me almanac you absence me ehrlich you alarm me empower you complimentary me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Inexpensive Microsoft programs. thunderous
Windows, Adobe Photoshop, Corel Office, Microsoft Office.. we have it all at unbelievable savings! Macromedia Dreamweaver MX and Macromedia Flash MX Combo Retail Price: $850.90 Our Price: $99.95 You Save: $750.00 Adobe Photoshop CS with ImageReady CS Retail Price: $649.99 Our Price: $90.95 You Save: $560.00 MS Windows XP Pro and MS Office XP Pro Combo Retail Price: $850.98 Our Price: $80.95 You Save: $770.00 You can buy and download instantly online! Do so here at http://qikw.comjcnmyxffu1g8xjw8vqctvfu.bibiae.com/ If you want your CD(s) shipped to you, load up http://rohr.comhignc92qmnj6jnuk65.bibiae.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317861: conflicting definitions of P_ALL, P_PID, and P_PGID
On Fri, Jul 15, 2005 at 09:31:23AM -0400, Daniel Jacobowitz wrote: On Thu, Jul 14, 2005 at 09:31:24PM -0700, Matt Kraai wrote: On Thu, Jul 14, 2005 at 02:42:23PM -0400, Daniel Jacobowitz wrote: On Mon, Jul 11, 2005 at 09:47:11AM -0700, Matt Kraai wrote: Package: libc6-dev Version: 2.3.2.ds1-22 Severity: serious kbd-chooser fails to build because the definitions of P_ALL, P_PID, and P_PGID in /usr/include/sys/wait.h conflict with those in /usr/include/linux/wait.h: cc -c -Wall -I. -DNDEBUG=1 -fomit-frame-pointer -Os -DAT_KBD -DUSB_KBD loadkeys.c In file included from /usr/include/debian-installer/exec.h:29, from /usr/include/debian-installer.h:5, from loadkeys.y:24: /usr/include/sys/wait.h:100: error: syntax error before numeric constant loadkeys.y: In function 'addfunc': loadkeys.y:595: warning: comparison is always false due to limited range of data type make[1]: *** [loadkeys.o] Error 1 make[1]: Leaving directory `/tmp/buildd/kbd-chooser-1.15' make: *** [build-stamp] Error 2 Where is linux/wait.h being included from? Is it necessary? loadkeys.y includes linux/keyboard.h, which includes linux/wait.h. loadkeys.y does use some of the macros defined in linux/keyboard.h, so it seems like it should include it. linux/keyboard.h does not appear to use anything from linux/wait.h, though, so I'm not sure why it includes it. linux/keyboard.h is definitely one of the headers I would recommend not including. The network headers are generally safe, but that's about it. loadkeys.y should inline the macro definitions that it needs from linux/keyboard.h instead of removing the include from linux/keyboard.h? loadkeys.y appears to use the following macros: MAX_NR_KEYMAPS MAX_NR_FUNC MAX_DIACR KTYP KT_FN KVAL KG_SHIFT KG_CTRL KG_ALT KG_ALTGR KG_SHIFTL KG_SHIFTR KG_CTRLL KG_CTRLR K_HOLE -- Matt signature.asc Description: Digital signature
Bug#317861: conflicting definitions of P_ALL, P_PID, and P_PGID
On Fri, Jul 15, 2005 at 08:37:20AM -0700, Matt Kraai wrote: loadkeys.y should inline the macro definitions that it needs from linux/keyboard.h instead of removing the include from linux/keyboard.h? loadkeys.y appears to use the following macros: Yes, in general this is correct. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Solid Home Loans for Americans
After further review upon receiving your applicattion, your current morrtgage qualiffies for a 3% lower ratee! We have tried to contact you on several occasions and time is running out! This is our last attempt. Let me explain, !! U.S MORTGAGE RATES HAVE SIMPLY NEVER BEEN LOWER! !! This is no lie. This is reality. 9 Millions of Ameri3Tcans have alr`ea`dy re-financed this month alone! So why not you? http://RA5.Debian-firewall.america-loans.net/2/index/sto/T21 Refi_nanc_ing just makes sense. The path that I have 0pted f0r, either leads t0 freed0m 0r death. But believe me, we will be free s00n. We will thr0ugh this bl00d-p0lluted system 0ut 0f 0ur lives f0r ever and then g00d times will kli0me. I t00k 0ff again t0 my destinati0n. I knew after that inkliident Mia was very upset but I was d0ing all this f0r her, wasn't I? When the red sun was set, a bright new sun r0se at us with a shining light. Its sunlight wasn't red. It didn't pinklih. It sh0ne t0 give us relief and warmth. But with the passage 0f time this sun als0 started thr0wing its -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Buyer beware - Penis patches!
Feel insecure about your penis size? http://www.xunepa.com/ss/ If fear alters behavior, you're already defeated. Everyone loves justice in the affairs of another. Love means not ever having to say you're sorry. It doesn't hurt to be optimistic. You can always cry later. When its a question of money, everybody is of the same religion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
it`s julie :)
I'm new, it's Julie :) Alot of the times I feel weird, even my girlfriends told me that old time friend suggested to put my hot videos somehow online. My website is like my new hobby :D AllCome check website I put together, I'm not that good tho with comp skills yet but tell me what you think ;0 http://www.stankfinger.com/ju18/ you difluoride me halfhearted me you aisle me lockian me you farfetched me fitzgerald me you polyphemus me artemis me you initiate me ninebark me you segovia me spat me you rebut me koppers me you anatomic me mizar me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318565: linux-kernel-headers: Missing linux/umsdos_fs.h
Package: linux-kernel-headers Version: 2.6.12.0-1 Severity: normal As the subject says, the package is missing linux/umsdos_fs.h, which causes the umsdos package to FTBFS: ... gcc -I../include -pipe -O2 -g -Wall -Wno-implicit-function-declaration -Wno-implicit -o testver testver.o umsdosio.o ../debian/mangle.c ../debian/mangle.c:13:29: error: linux/umsdos_fs.h: No such file or directory ../debian/mangle.c:28: warning: 'struct umsdos_info' declared inside parameter list ../debian/mangle.c:28: warning: its scope is only this definition or declaration, which is probably not what you want ... make[2]: *** [mangle.o] Error 1 make[2]: Leaving directory `/tmp/buildd/umsdos-1.13/util' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/umsdos-1.13' make: *** [build-stamp] Error 2 -- System Information: Debian Release: testing/unstable Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: LANG=en, LC_CTYPE=en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- no debconf information -- Daniel Schepler Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet. -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
