From vda at uclibc.org Wed Aug 1 03:19:55 2007 From: vda at uclibc.org (vda at uclibc.org) Date: Wed, 1 Aug 2007 03:19:55 -0700 (PDT) Subject: svn commit: trunk/uClibc/libc/pwd_grp Message-ID: <20070801101955.7C387A4680@busybox.net> Author: vda Date: 2007-08-01 03:19:51 -0700 (Wed, 01 Aug 2007) New Revision: 19386 Log: sgetspent: add missing free/__uc_malloc calls (spotted by Peter S. Mazinger ) Modified: trunk/uClibc/libc/pwd_grp/pwd_grp.c Changeset: Modified: trunk/uClibc/libc/pwd_grp/pwd_grp.c =================================================================== --- trunk/uClibc/libc/pwd_grp/pwd_grp.c 2007-08-01 09:53:01 UTC (rev 19385) +++ trunk/uClibc/libc/pwd_grp/pwd_grp.c 2007-08-01 10:19:51 UTC (rev 19386) @@ -729,6 +729,8 @@ } *sp; struct spwd *result; + free(sp); + sp = __uc_malloc(sizeof(*sp)); sgetspent_r(string, &sp->spwd, sp->line_buff, sizeof(sp->line_buff), &result); return result; } From bugs at busybox.net Wed Aug 1 10:19:15 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 1 Aug 2007 10:19:15 -0700 Subject: [uClibc 0001452]: rint() bad on x86. Message-ID: <60b9fdd62ad06942f83d8c650ffaaf6a@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1452 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1452 Category: Architecture Specific Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 07-31-2007 05:55 PDT Last Modified: 08-01-2007 10:19 PDT ====================================================================== Summary: rint() bad on x86. Description: On x86 with Linux uclibc's rint() function returns bad results. This was tracked down to Linux's defaulting to 80-bit floating point rounding, and uclibc's 64-bit function. There are two ways of dealing with this: 1) Reset FPU to 64-bit precision. 2) Import glibc's functions for this and its variants. I'm currently working on doing the latter in my personal tree, and will submit a patch when I finish. ====================================================================== ---------------------------------------------------------------------- chmeee - 08-01-07 10:19 ---------------------------------------------------------------------- The attached diff fixes the rint() functions by importing the glibc code for them. Issue History Date Modified Username Field Change ====================================================================== 07-31-07 05:55 chmeee New Issue 07-31-07 05:55 chmeee Status new => assigned 07-31-07 05:55 chmeee Assigned To => uClibc 08-01-07 10:18 chmeee File Added: uclibc_fp_fix.diff 08-01-07 10:19 chmeee Note Added: 0002647 ====================================================================== From bugs at busybox.net Mon Aug 6 11:53:00 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Mon, 6 Aug 2007 11:53:00 -0700 Subject: [uClibc 0001453]: setlinebuf() doesn't work Message-ID: The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1453 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1453 Category: Stdio Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 08-06-2007 11:53 PDT Last Modified: 08-06-2007 11:53 PDT ====================================================================== Summary: setlinebuf() doesn't work Description: setlinebuf() ends up setting unbuffered mode. The attached patch fixes this. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 08-06-07 11:53 chmeee New Issue 08-06-07 11:53 chmeee Status new => assigned 08-06-07 11:53 chmeee Assigned To => uClibc 08-06-07 11:53 chmeee File Added: setvbuf.diff ====================================================================== From bugs at busybox.net Tue Aug 21 04:03:13 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 21 Aug 2007 04:03:13 -0700 Subject: [uClibc 0001468]: Couple more bugs in gethostbyname() (patch attached) Message-ID: <668241a630daa20de2e4706542683e13@bugs.uclibc.org> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1468 ====================================================================== Reported By: vvv Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1468 Category: Networking Support Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-21-2007 04:03 PDT Last Modified: 08-21-2007 04:03 PDT ====================================================================== Summary: Couple more bugs in gethostbyname() (patch attached) Description: The following bugs have been observed in gethostbyname(): 1. gethostbyname() fails if DNS server returns more than 23 addresses (reported by me as 0001361) 2. gethostbyname() fails if the response from DNS server is truncated (i.e. the full response would contain more than 512 bytes). Such situation existed for a couple days for vpn.corbina.net - DNS was returning 29 addresses. 3. The h_aliases[0] field of struct hostent points to a corrupted buffer (the buffer is always overwritten by h_addr_list[0]). The attached patch fixes the issue for uClibc-0.9.29. Note: this patch makes my fixes of 0001361 redundant. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 08-21-07 04:03 vvv New Issue 08-21-07 04:03 vvv Status new => assigned 08-21-07 04:03 vvv Assigned To => uClibc 08-21-07 04:03 vvv File Added: resolv.patch ====================================================================== From bugs at busybox.net Thu Aug 23 17:19:41 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 23 Aug 2007 17:19:41 -0700 Subject: [uClibc 0000972]: errno broken in linuxthreads.old Message-ID: <2aa60778aad0de1c3c6c4b790fd2bac0@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=972 ====================================================================== Reported By: bsfost Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 972 Category: Posix Threads Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 07-27-2006 05:36 PDT Last Modified: 08-23-2007 17:19 PDT ====================================================================== Summary: errno broken in linuxthreads.old Description: I have a problem where, effectively, errno is never set in threads within applications built with uClibc (using the linuxthreads.old library). Debugging has shown that the system call (send(), in the case of the example) is made and the global/libc errno is set prior to returning to application code. The subsequent request to retrieve the error code calls into __errno_location() in the linuxthreads.old library, which finds the appropriate thread descriptor and returns (*self->p_errnop), which was never set. I didn't see anything obvious that "intended" to set the thread specific errno value based on system calls made on that thread's behalf (i.e., I would expect this in the syscall wrappers, perhaps..?), but I'm fairly new to this library so I'm not sure whether this is considered a bug, misconfiguration or simple lack of functionality. For completeness, I compared the behavior with an _old_ glibc-2.2 system which looked like it had the same general design. The application worked in this case, but I noticed that the thread_self() call (while requesting the errno value in the thread, following the failed syscall) ended up returning a pointer to the __pthread_initial_thread structure rather than the specific thread structure I assume it created when it cloned (which is what happens in uClibc's thread_self()). I also tested a quick change in uClibc by setting __pthread_manager_thread's p_errnop to '&_errno' as well as new threads created in pthread_handle_create(). This change allowed expected behavior, but it's probably not the appropriate fix. Any information on this is greatly appreciated, and let me know if I've been unclear or missed any important points. Thanks. Brian ====================================================================== ---------------------------------------------------------------------- andre_rosa - 08-23-07 17:19 ---------------------------------------------------------------------- The attached file has different behavior in mipsel platform when comparing with glibc in a regular PC. Issue History Date Modified Username Field Change ====================================================================== 07-27-06 05:36 bsfost New Issue 07-27-06 05:36 bsfost Status new => assigned 07-27-06 05:36 bsfost Assigned To => uClibc 08-23-07 17:11 andre_rosa Issue Monitored: andre_rosa 08-23-07 17:18 andre_rosa File Added: main3.c 08-23-07 17:19 andre_rosa Note Added: 0002680 ====================================================================== From bugs at busybox.net Mon Aug 27 02:46:14 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Mon, 27 Aug 2007 02:46:14 -0700 Subject: [uClibc 0001476]: Weird linking behaviour Message-ID: <4f8a5ab9738b62d691a32cce2f84693f@bugs.uclibc.org> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1476 ====================================================================== Reported By: sors Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1476 Category: Posix Threads Reproducibility: always Severity: block Priority: normal Status: assigned ====================================================================== Date Submitted: 08-27-2007 02:46 PDT Last Modified: 08-27-2007 02:46 PDT ====================================================================== Summary: Weird linking behaviour Description: I have an application that is linked dynamically to a shared lib, which itself uses pthreads and is dynamically linked to the pthreads lib. When a worker thread is created and started, the thread function is called. But the main thread (which created the worker thread) never is scheduled/run again! If the worker thread contains an infinitive loop, it runs forever. If it exits (by using return) the whole process doesn't do anything anymore.. It is blocked. IF I link the pthreads lib to the application as well, the same code works fine. The main thread and the worker thread are both scheduled as expected. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 08-27-07 02:46 sors New Issue 08-27-07 02:46 sors Status new => assigned 08-27-07 02:46 sors Assigned To => uClibc ====================================================================== From bugs at busybox.net Fri Aug 31 10:49:37 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 31 Aug 2007 10:49:37 -0700 Subject: [uClibc 0001481]: PowerPC does not appear to cope with kernel with 64KB pages enabled on 0.9.29. Message-ID: <391400defec0101949a1d863b84bbafb@busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1481 ====================================================================== Reported By: jbj Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1481 Category: Architecture Specific Reproducibility: always Severity: block Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2007 10:49 PDT Last Modified: 08-31-2007 10:49 PDT ====================================================================== Summary: PowerPC does not appear to cope with kernel with 64KB pages enabled on 0.9.29. Description: This was reproduced using a recent buildroot snapshot. The symptoms are identical to http://bugs.uclibc.org/view.php?id=1345 and it only fails on a kernel that happens to have CONFIG_PPC_64K_PAGES=y yet. Every dynamicly linked program booting under, for example, the stock RHEL5 kernel which has that set, fails with 'can't map .so' errors. Can debug further, but all investigation so far aligns with bug 1345. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 08-31-07 10:49 jbj New Issue 08-31-07 10:49 jbj Status new => assigned 08-31-07 10:49 jbj Assigned To => uClibc ======================================================================