From uclibc-cvs at uclibc.org Sun Sep 2 08:35:26 2007 From: uclibc-cvs at uclibc.org (Kermit Elliot) Date: , 33 Aug 2007 12:35:26 -0300 Subject: Pharmacy Shop Message-ID: <362293779.53059696506389@uclibc.org> New pharmacy shop: http://kcoam.solveparticular.com/?714277367215 From bugs at busybox.net Tue Sep 4 07:16:52 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 4 Sep 2007 07:16:52 -0700 Subject: [uClibc 0001484]: compilation errors on uboot using uclibc toolchain. Message-ID: <3535fcde2c48e4379db146f30d40d62a@busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1484 ====================================================================== Reported By: rk_appan Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1484 Category: Architecture Specific Reproducibility: have not tried Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 09-04-2007 07:16 PDT Last Modified: 09-04-2007 07:16 PDT ====================================================================== Summary: compilation errors on uboot using uclibc toolchain. Description: I am using uclib0.9.28. When I am trying to build uboot, I am getting the following error: /home/kans/buildroot/toolchain_build_arm/gcc-4.2.0/gcc/config/arm/lib1funcs.asm:1000:undefined reference to `raise' I have enabled generic-arm and EABI option. Also, I there are warnings like warning: target CPU does not support interworking. I am getting strange errors like undefined reference to `getenv_IPaddr' and some other functions. The u-boot version what I am using is working fine with glibc toolchain. can anybody help to solve this problem. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 09-04-07 07:16 rk_appan New Issue 09-04-07 07:16 rk_appan Status new => assigned 09-04-07 07:16 rk_appan Assigned To => uClibc ====================================================================== From bugs at busybox.net Tue Sep 4 21:25:24 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 4 Sep 2007 21:25:24 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 09-04-2007 21:25 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-30-07 14:22 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. select() does not behave like a cancellation point (while it should). Could it be because select() is simply a syscall5 and we therefore never reach the sigwait() function of the pthread library? If I modify the select() call as follow, the thread is indeed canceled: r = select(0, NULL, NULL, &tv); if ((r == -1) && (errno == EINTR)) pthread_testcancel(); I eventually found where linuxthreads.old defines cancellable system calls: wrapsyscall.c and added an entry for select(2). Note: select() was previously listed as a cancellation point but it got removed by Ulrich Depper and I don't know why: CVSROOT: /cvs/glibc Module name: libc Changes by: drepper at sourceware.org 2002-12-15 13:43:25 Modified files: linuxthreads : wrapsyscall.c Log message: Remove creat, poll, pselect, readv, select, sigpause, sigsuspend, sigwaitinfo, waitid, and writev wrappers. I have attached to this report, a patch re-introducing select(2). ---------------------------------------------------------------------- hmoffatt - 09-04-07 21:25 ---------------------------------------------------------------------- I have an application which is hanging with uClibc 0.9.29. The main process is regularly calling fork() and exec(). There is also a thread which is doing a select() with a 1ms timeout in an endless loop. The application sometimes hangs just after the fork/exec; the exec has happened (there is a zombie process left around). I tried the patch in this bug report; now the program segfaults instead of hanging. So I don't think the patch is the correct solution. Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 06-27-07 13:52 chombourger Note Edited: 0002528 06-30-07 12:49 chombourger Note Edited: 0002528 06-30-07 14:18 chombourger File Added: uClibc-select-cancellation-point.patch 06-30-07 14:22 chombourger Note Edited: 0002528 07-01-07 22:26 chombourger Issue Monitored: chombourger 09-04-07 21:25 hmoffatt Note Added: 0002712 ====================================================================== From bugs at busybox.net Wed Sep 5 00:30:06 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 5 Sep 2007 00:30:06 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: <80c8ab3abb69941396b96c5ba0d9521b@busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 09-05-2007 00:30 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-30-07 14:22 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. select() does not behave like a cancellation point (while it should). Could it be because select() is simply a syscall5 and we therefore never reach the sigwait() function of the pthread library? If I modify the select() call as follow, the thread is indeed canceled: r = select(0, NULL, NULL, &tv); if ((r == -1) && (errno == EINTR)) pthread_testcancel(); I eventually found where linuxthreads.old defines cancellable system calls: wrapsyscall.c and added an entry for select(2). Note: select() was previously listed as a cancellation point but it got removed by Ulrich Depper and I don't know why: CVSROOT: /cvs/glibc Module name: libc Changes by: drepper at sourceware.org 2002-12-15 13:43:25 Modified files: linuxthreads : wrapsyscall.c Log message: Remove creat, poll, pselect, readv, select, sigpause, sigsuspend, sigwaitinfo, waitid, and writev wrappers. I have attached to this report, a patch re-introducing select(2). ---------------------------------------------------------------------- hmoffatt - 09-04-07 21:25 ---------------------------------------------------------------------- I have an application which is hanging with uClibc 0.9.29. The main process is regularly calling fork() and exec(). There is also a thread which is doing a select() with a 1ms timeout in an endless loop. The application sometimes hangs just after the fork/exec; the exec has happened (there is a zombie process left around). I tried the patch in this bug report; now the program segfaults instead of hanging. So I don't think the patch is the correct solution. ---------------------------------------------------------------------- chombourger - 09-05-07 00:30 ---------------------------------------------------------------------- Three questions: (a) have you tried running this program on a glibc system and does it work? (b) is your app. making any use of pthread_cancel() and pthread_join()? (c) can you provide us a stripped down version of your application so that we can reproduce the bug/segfault with it? Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 06-27-07 13:52 chombourger Note Edited: 0002528 06-30-07 12:49 chombourger Note Edited: 0002528 06-30-07 14:18 chombourger File Added: uClibc-select-cancellation-point.patch 06-30-07 14:22 chombourger Note Edited: 0002528 07-01-07 22:26 chombourger Issue Monitored: chombourger 09-04-07 21:25 hmoffatt Note Added: 0002712 09-05-07 00:30 chombourger Note Added: 0002713 ====================================================================== From bugs at busybox.net Wed Sep 5 00:54:16 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 5 Sep 2007 00:54:16 -0700 Subject: [uClibc 0001486]: powerpc: neither soft_float nor kernel emulated fpu working Message-ID: <3266851143ffa7da66d30d45dd8acb55@bugs.uclibc.org> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1486 ====================================================================== Reported By: busyben Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1486 Category: Architecture Specific Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 09-05-2007 00:54 PDT Last Modified: 09-05-2007 00:54 PDT ====================================================================== Summary: powerpc: neither soft_float nor kernel emulated fpu working Description: I always get "illegal instruction" errors when trying to printf(%f, some_float_or_double). Since I use a embedded powerpc without fpu, I compiled uclibc with soft-float enabled (-msoft-float). But this does not seems to work. Therefore I tried the floating point kernel-emulation in the linux kernel, which gives lots of warnings during compiling (see below 1.). After that, there is no illegal instruction anymore, but printf(%f,...) gives always 0.147484 (see 2.) I am using OpenWrt with uClibc 0.9.28.2, Linux Kernel 2.6.22.1 together with a PowerPC 405 hard core in a Xilnix VirtexII Pro FPGA XC2VP30. Is this a but in uClibc's soft-float AND/OR the kernels ppc/math-emu? What can I do to get fp-requiring applications running? If this helps: when I try to run rrdtool, I also get an error about symbol 'rintf' (see 3.), although I compiled everything with option -fPIC. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 09-05-07 00:54 busyben New Issue 09-05-07 00:54 busyben Status new => assigned 09-05-07 00:54 busyben Assigned To => uClibc 09-05-07 00:54 busyben File Added: float-test.c ====================================================================== From bugs at busybox.net Wed Sep 5 02:58:56 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 5 Sep 2007 02:58:56 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 09-05-2007 02:58 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-30-07 14:22 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. select() does not behave like a cancellation point (while it should). Could it be because select() is simply a syscall5 and we therefore never reach the sigwait() function of the pthread library? If I modify the select() call as follow, the thread is indeed canceled: r = select(0, NULL, NULL, &tv); if ((r == -1) && (errno == EINTR)) pthread_testcancel(); I eventually found where linuxthreads.old defines cancellable system calls: wrapsyscall.c and added an entry for select(2). Note: select() was previously listed as a cancellation point but it got removed by Ulrich Depper and I don't know why: CVSROOT: /cvs/glibc Module name: libc Changes by: drepper at sourceware.org 2002-12-15 13:43:25 Modified files: linuxthreads : wrapsyscall.c Log message: Remove creat, poll, pselect, readv, select, sigpause, sigsuspend, sigwaitinfo, waitid, and writev wrappers. I have attached to this report, a patch re-introducing select(2). ---------------------------------------------------------------------- hmoffatt - 09-04-07 21:25 ---------------------------------------------------------------------- I have an application which is hanging with uClibc 0.9.29. The main process is regularly calling fork() and exec(). There is also a thread which is doing a select() with a 1ms timeout in an endless loop. The application sometimes hangs just after the fork/exec; the exec has happened (there is a zombie process left around). I tried the patch in this bug report; now the program segfaults instead of hanging. So I don't think the patch is the correct solution. ---------------------------------------------------------------------- chombourger - 09-05-07 00:30 ---------------------------------------------------------------------- Three questions: (a) have you tried running this program on a glibc system and does it work? (b) is your app. making any use of pthread_cancel() and pthread_join()? (c) can you provide us a stripped down version of your application so that we can reproduce the bug/segfault with it? ---------------------------------------------------------------------- hmoffatt - 09-05-07 02:58 ---------------------------------------------------------------------- My application is in Python. At the time my hang occurs I am not using pthread_join or cancel; a finite set of threads have been created some time earlier and should continue to exist for the life of the program. Hence the original problem in this report doesn't describe my situation. Nonetheless the patch had some impact which suggests it may not be right. My original process (not one of the threads) is regularly calling fork() and exec() (via python wrappers). It appears that the process hangs somewhere after exec(), before returning to my interpreted program. strace shows that the program did get SIGCHLD as the last thing that happened, meaning that the child has exited. Then it seems to be sleeping waiting for something to happen. There is another thread which is calling select() with a 1ms sleep indefinitely. I think it hangs also though I will have to retest to be sure. The thread manager thread seems to be still running ok, calling poll() with a 1 second timeout. strace shows it is still running. When I put in the patch from this report, the select() thread dies with SIGSEGV. I am trying to build glibc for the embedded system now. I will also try to run it on my desktop with glibc and reproduce it. Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 06-27-07 13:52 chombourger Note Edited: 0002528 06-30-07 12:49 chombourger Note Edited: 0002528 06-30-07 14:18 chombourger File Added: uClibc-select-cancellation-point.patch 06-30-07 14:22 chombourger Note Edited: 0002528 07-01-07 22:26 chombourger Issue Monitored: chombourger 09-04-07 21:25 hmoffatt Note Added: 0002712 09-05-07 00:30 chombourger Note Added: 0002713 09-05-07 02:58 hmoffatt Note Added: 0002714 ====================================================================== From bugs at busybox.net Wed Sep 5 21:58:34 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 5 Sep 2007 21:58:34 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: <33db00763ecd923b05b78a40009d7f53@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 09-05-2007 21:58 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-30-07 14:22 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. select() does not behave like a cancellation point (while it should). Could it be because select() is simply a syscall5 and we therefore never reach the sigwait() function of the pthread library? If I modify the select() call as follow, the thread is indeed canceled: r = select(0, NULL, NULL, &tv); if ((r == -1) && (errno == EINTR)) pthread_testcancel(); I eventually found where linuxthreads.old defines cancellable system calls: wrapsyscall.c and added an entry for select(2). Note: select() was previously listed as a cancellation point but it got removed by Ulrich Depper and I don't know why: CVSROOT: /cvs/glibc Module name: libc Changes by: drepper at sourceware.org 2002-12-15 13:43:25 Modified files: linuxthreads : wrapsyscall.c Log message: Remove creat, poll, pselect, readv, select, sigpause, sigsuspend, sigwaitinfo, waitid, and writev wrappers. I have attached to this report, a patch re-introducing select(2). ---------------------------------------------------------------------- hmoffatt - 09-04-07 21:25 ---------------------------------------------------------------------- I have an application which is hanging with uClibc 0.9.29. The main process is regularly calling fork() and exec(). There is also a thread which is doing a select() with a 1ms timeout in an endless loop. The application sometimes hangs just after the fork/exec; the exec has happened (there is a zombie process left around). I tried the patch in this bug report; now the program segfaults instead of hanging. So I don't think the patch is the correct solution. ---------------------------------------------------------------------- chombourger - 09-05-07 00:30 ---------------------------------------------------------------------- Three questions: (a) have you tried running this program on a glibc system and does it work? (b) is your app. making any use of pthread_cancel() and pthread_join()? (c) can you provide us a stripped down version of your application so that we can reproduce the bug/segfault with it? ---------------------------------------------------------------------- hmoffatt - 09-05-07 02:58 ---------------------------------------------------------------------- My application is in Python. At the time my hang occurs I am not using pthread_join or cancel; a finite set of threads have been created some time earlier and should continue to exist for the life of the program. Hence the original problem in this report doesn't describe my situation. Nonetheless the patch had some impact which suggests it may not be right. My original process (not one of the threads) is regularly calling fork() and exec() (via python wrappers). It appears that the process hangs somewhere after exec(), before returning to my interpreted program. strace shows that the program did get SIGCHLD as the last thing that happened, meaning that the child has exited. Then it seems to be sleeping waiting for something to happen. There is another thread which is calling select() with a 1ms sleep indefinitely. I think it hangs also though I will have to retest to be sure. The thread manager thread seems to be still running ok, calling poll() with a 1 second timeout. strace shows it is still running. When I put in the patch from this report, the select() thread dies with SIGSEGV. I am trying to build glibc for the embedded system now. I will also try to run it on my desktop with glibc and reproduce it. ---------------------------------------------------------------------- hmoffatt - 09-05-07 21:58 ---------------------------------------------------------------------- I have now tested this with glibc 2.3.6 with linuxthreads (not NPTL). It segfaults just the same as with your patch for uClibc. I guess that could be considered a positive sign.. probably meaning that my bug is somewhere else. Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 06-27-07 13:52 chombourger Note Edited: 0002528 06-30-07 12:49 chombourger Note Edited: 0002528 06-30-07 14:18 chombourger File Added: uClibc-select-cancellation-point.patch 06-30-07 14:22 chombourger Note Edited: 0002528 07-01-07 22:26 chombourger Issue Monitored: chombourger 09-04-07 21:25 hmoffatt Note Added: 0002712 09-05-07 00:30 chombourger Note Added: 0002713 09-05-07 02:58 hmoffatt Note Added: 0002714 09-05-07 21:58 hmoffatt Note Added: 0002721 ====================================================================== From bugs at busybox.net Thu Sep 6 01:14:41 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 6 Sep 2007 01:14:41 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: <9087a02eb520d6e8609abce073dc27d2@busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 09-06-2007 01:14 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-30-07 14:22 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. select() does not behave like a cancellation point (while it should). Could it be because select() is simply a syscall5 and we therefore never reach the sigwait() function of the pthread library? If I modify the select() call as follow, the thread is indeed canceled: r = select(0, NULL, NULL, &tv); if ((r == -1) && (errno == EINTR)) pthread_testcancel(); I eventually found where linuxthreads.old defines cancellable system calls: wrapsyscall.c and added an entry for select(2). Note: select() was previously listed as a cancellation point but it got removed by Ulrich Depper and I don't know why: CVSROOT: /cvs/glibc Module name: libc Changes by: drepper at sourceware.org 2002-12-15 13:43:25 Modified files: linuxthreads : wrapsyscall.c Log message: Remove creat, poll, pselect, readv, select, sigpause, sigsuspend, sigwaitinfo, waitid, and writev wrappers. I have attached to this report, a patch re-introducing select(2). ---------------------------------------------------------------------- hmoffatt - 09-04-07 21:25 ---------------------------------------------------------------------- I have an application which is hanging with uClibc 0.9.29. The main process is regularly calling fork() and exec(). There is also a thread which is doing a select() with a 1ms timeout in an endless loop. The application sometimes hangs just after the fork/exec; the exec has happened (there is a zombie process left around). I tried the patch in this bug report; now the program segfaults instead of hanging. So I don't think the patch is the correct solution. ---------------------------------------------------------------------- chombourger - 09-05-07 00:30 ---------------------------------------------------------------------- Three questions: (a) have you tried running this program on a glibc system and does it work? (b) is your app. making any use of pthread_cancel() and pthread_join()? (c) can you provide us a stripped down version of your application so that we can reproduce the bug/segfault with it? ---------------------------------------------------------------------- hmoffatt - 09-05-07 02:58 ---------------------------------------------------------------------- My application is in Python. At the time my hang occurs I am not using pthread_join or cancel; a finite set of threads have been created some time earlier and should continue to exist for the life of the program. Hence the original problem in this report doesn't describe my situation. Nonetheless the patch had some impact which suggests it may not be right. My original process (not one of the threads) is regularly calling fork() and exec() (via python wrappers). It appears that the process hangs somewhere after exec(), before returning to my interpreted program. strace shows that the program did get SIGCHLD as the last thing that happened, meaning that the child has exited. Then it seems to be sleeping waiting for something to happen. There is another thread which is calling select() with a 1ms sleep indefinitely. I think it hangs also though I will have to retest to be sure. The thread manager thread seems to be still running ok, calling poll() with a 1 second timeout. strace shows it is still running. When I put in the patch from this report, the select() thread dies with SIGSEGV. I am trying to build glibc for the embedded system now. I will also try to run it on my desktop with glibc and reproduce it. ---------------------------------------------------------------------- hmoffatt - 09-05-07 21:58 ---------------------------------------------------------------------- I have now tested this with glibc 2.3.6 with linuxthreads (not NPTL). It segfaults just the same as with your patch for uClibc. I guess that could be considered a positive sign.. probably meaning that my bug is somewhere else. ---------------------------------------------------------------------- chombourger - 09-06-07 01:14 ---------------------------------------------------------------------- Ok interesting point. Do you have a backtrace when it crashes? Wondering if the segfaults occurs within the libc. Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 06-27-07 13:52 chombourger Note Edited: 0002528 06-30-07 12:49 chombourger Note Edited: 0002528 06-30-07 14:18 chombourger File Added: uClibc-select-cancellation-point.patch 06-30-07 14:22 chombourger Note Edited: 0002528 07-01-07 22:26 chombourger Issue Monitored: chombourger 09-04-07 21:25 hmoffatt Note Added: 0002712 09-05-07 00:30 chombourger Note Added: 0002713 09-05-07 02:58 hmoffatt Note Added: 0002714 09-05-07 21:58 hmoffatt Note Added: 0002721 09-06-07 01:14 chombourger Note Added: 0002722 ====================================================================== From bugs at busybox.net Thu Sep 6 07:45:48 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 6 Sep 2007 07:45:48 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: <4f7d3d025409ed77f04356ff6bb82d2e@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 09-06-2007 07:45 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-30-07 14:22 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. select() does not behave like a cancellation point (while it should). Could it be because select() is simply a syscall5 and we therefore never reach the sigwait() function of the pthread library? If I modify the select() call as follow, the thread is indeed canceled: r = select(0, NULL, NULL, &tv); if ((r == -1) && (errno == EINTR)) pthread_testcancel(); I eventually found where linuxthreads.old defines cancellable system calls: wrapsyscall.c and added an entry for select(2). Note: select() was previously listed as a cancellation point but it got removed by Ulrich Depper and I don't know why: CVSROOT: /cvs/glibc Module name: libc Changes by: drepper at sourceware.org 2002-12-15 13:43:25 Modified files: linuxthreads : wrapsyscall.c Log message: Remove creat, poll, pselect, readv, select, sigpause, sigsuspend, sigwaitinfo, waitid, and writev wrappers. I have attached to this report, a patch re-introducing select(2). ---------------------------------------------------------------------- hmoffatt - 09-04-07 21:25 ---------------------------------------------------------------------- I have an application which is hanging with uClibc 0.9.29. The main process is regularly calling fork() and exec(). There is also a thread which is doing a select() with a 1ms timeout in an endless loop. The application sometimes hangs just after the fork/exec; the exec has happened (there is a zombie process left around). I tried the patch in this bug report; now the program segfaults instead of hanging. So I don't think the patch is the correct solution. ---------------------------------------------------------------------- chombourger - 09-05-07 00:30 ---------------------------------------------------------------------- Three questions: (a) have you tried running this program on a glibc system and does it work? (b) is your app. making any use of pthread_cancel() and pthread_join()? (c) can you provide us a stripped down version of your application so that we can reproduce the bug/segfault with it? ---------------------------------------------------------------------- hmoffatt - 09-05-07 02:58 ---------------------------------------------------------------------- My application is in Python. At the time my hang occurs I am not using pthread_join or cancel; a finite set of threads have been created some time earlier and should continue to exist for the life of the program. Hence the original problem in this report doesn't describe my situation. Nonetheless the patch had some impact which suggests it may not be right. My original process (not one of the threads) is regularly calling fork() and exec() (via python wrappers). It appears that the process hangs somewhere after exec(), before returning to my interpreted program. strace shows that the program did get SIGCHLD as the last thing that happened, meaning that the child has exited. Then it seems to be sleeping waiting for something to happen. There is another thread which is calling select() with a 1ms sleep indefinitely. I think it hangs also though I will have to retest to be sure. The thread manager thread seems to be still running ok, calling poll() with a 1 second timeout. strace shows it is still running. When I put in the patch from this report, the select() thread dies with SIGSEGV. I am trying to build glibc for the embedded system now. I will also try to run it on my desktop with glibc and reproduce it. ---------------------------------------------------------------------- hmoffatt - 09-05-07 21:58 ---------------------------------------------------------------------- I have now tested this with glibc 2.3.6 with linuxthreads (not NPTL). It segfaults just the same as with your patch for uClibc. I guess that could be considered a positive sign.. probably meaning that my bug is somewhere else. ---------------------------------------------------------------------- chombourger - 09-06-07 01:14 ---------------------------------------------------------------------- Ok interesting point. Do you have a backtrace when it crashes? Wondering if the segfaults occurs within the libc. ---------------------------------------------------------------------- hmoffatt - 09-06-07 07:45 ---------------------------------------------------------------------- My cross-gdb insists on trying to load the host libraries rather than the target ones so I can't get a meaningful back trace even though I have the build and a core file. :( Looks like it is reading the absolute paths from the core file; I really need to be able to prepend a path to those when loading into the cross-gdb. Is that possible? I have had even less success doing a live cross-gdb against gdbserver. Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 06-27-07 13:52 chombourger Note Edited: 0002528 06-30-07 12:49 chombourger Note Edited: 0002528 06-30-07 14:18 chombourger File Added: uClibc-select-cancellation-point.patch 06-30-07 14:22 chombourger Note Edited: 0002528 07-01-07 22:26 chombourger Issue Monitored: chombourger 09-04-07 21:25 hmoffatt Note Added: 0002712 09-05-07 00:30 chombourger Note Added: 0002713 09-05-07 02:58 hmoffatt Note Added: 0002714 09-05-07 21:58 hmoffatt Note Added: 0002721 09-06-07 01:14 chombourger Note Added: 0002722 09-06-07 07:45 hmoffatt Note Added: 0002723 ====================================================================== From bugs at busybox.net Thu Sep 6 07:51:08 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 6 Sep 2007 07:51:08 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: <5ae9a366001c61c20c1d26c9ddaa33ae@busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 09-06-2007 07:51 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-30-07 14:22 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. select() does not behave like a cancellation point (while it should). Could it be because select() is simply a syscall5 and we therefore never reach the sigwait() function of the pthread library? If I modify the select() call as follow, the thread is indeed canceled: r = select(0, NULL, NULL, &tv); if ((r == -1) && (errno == EINTR)) pthread_testcancel(); I eventually found where linuxthreads.old defines cancellable system calls: wrapsyscall.c and added an entry for select(2). Note: select() was previously listed as a cancellation point but it got removed by Ulrich Depper and I don't know why: CVSROOT: /cvs/glibc Module name: libc Changes by: drepper at sourceware.org 2002-12-15 13:43:25 Modified files: linuxthreads : wrapsyscall.c Log message: Remove creat, poll, pselect, readv, select, sigpause, sigsuspend, sigwaitinfo, waitid, and writev wrappers. I have attached to this report, a patch re-introducing select(2). ---------------------------------------------------------------------- hmoffatt - 09-04-07 21:25 ---------------------------------------------------------------------- I have an application which is hanging with uClibc 0.9.29. The main process is regularly calling fork() and exec(). There is also a thread which is doing a select() with a 1ms timeout in an endless loop. The application sometimes hangs just after the fork/exec; the exec has happened (there is a zombie process left around). I tried the patch in this bug report; now the program segfaults instead of hanging. So I don't think the patch is the correct solution. ---------------------------------------------------------------------- chombourger - 09-05-07 00:30 ---------------------------------------------------------------------- Three questions: (a) have you tried running this program on a glibc system and does it work? (b) is your app. making any use of pthread_cancel() and pthread_join()? (c) can you provide us a stripped down version of your application so that we can reproduce the bug/segfault with it? ---------------------------------------------------------------------- hmoffatt - 09-05-07 02:58 ---------------------------------------------------------------------- My application is in Python. At the time my hang occurs I am not using pthread_join or cancel; a finite set of threads have been created some time earlier and should continue to exist for the life of the program. Hence the original problem in this report doesn't describe my situation. Nonetheless the patch had some impact which suggests it may not be right. My original process (not one of the threads) is regularly calling fork() and exec() (via python wrappers). It appears that the process hangs somewhere after exec(), before returning to my interpreted program. strace shows that the program did get SIGCHLD as the last thing that happened, meaning that the child has exited. Then it seems to be sleeping waiting for something to happen. There is another thread which is calling select() with a 1ms sleep indefinitely. I think it hangs also though I will have to retest to be sure. The thread manager thread seems to be still running ok, calling poll() with a 1 second timeout. strace shows it is still running. When I put in the patch from this report, the select() thread dies with SIGSEGV. I am trying to build glibc for the embedded system now. I will also try to run it on my desktop with glibc and reproduce it. ---------------------------------------------------------------------- hmoffatt - 09-05-07 21:58 ---------------------------------------------------------------------- I have now tested this with glibc 2.3.6 with linuxthreads (not NPTL). It segfaults just the same as with your patch for uClibc. I guess that could be considered a positive sign.. probably meaning that my bug is somewhere else. ---------------------------------------------------------------------- chombourger - 09-06-07 01:14 ---------------------------------------------------------------------- Ok interesting point. Do you have a backtrace when it crashes? Wondering if the segfaults occurs within the libc. ---------------------------------------------------------------------- hmoffatt - 09-06-07 07:45 ---------------------------------------------------------------------- My cross-gdb insists on trying to load the host libraries rather than the target ones so I can't get a meaningful back trace even though I have the build and a core file. :( Looks like it is reading the absolute paths from the core file; I really need to be able to prepend a path to those when loading into the cross-gdb. Is that possible? I have had even less success doing a live cross-gdb against gdbserver. ---------------------------------------------------------------------- chombourger - 09-06-07 07:51 ---------------------------------------------------------------------- You could use the gdb setting 'set solib-absolute-prefix PATH' to tell gdb the base prefix of your target file-system That used to work for me. Hope this helps! Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 06-27-07 13:52 chombourger Note Edited: 0002528 06-30-07 12:49 chombourger Note Edited: 0002528 06-30-07 14:18 chombourger File Added: uClibc-select-cancellation-point.patch 06-30-07 14:22 chombourger Note Edited: 0002528 07-01-07 22:26 chombourger Issue Monitored: chombourger 09-04-07 21:25 hmoffatt Note Added: 0002712 09-05-07 00:30 chombourger Note Added: 0002713 09-05-07 02:58 hmoffatt Note Added: 0002714 09-05-07 21:58 hmoffatt Note Added: 0002721 09-06-07 01:14 chombourger Note Added: 0002722 09-06-07 07:45 hmoffatt Note Added: 0002723 09-06-07 07:51 chombourger Note Added: 0002724 ====================================================================== From bugs at busybox.net Thu Sep 6 16:27:57 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 6 Sep 2007 16:27:57 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: <64505720dbf769260aed226b89d02b37@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 09-06-2007 16:27 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-30-07 14:22 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. select() does not behave like a cancellation point (while it should). Could it be because select() is simply a syscall5 and we therefore never reach the sigwait() function of the pthread library? If I modify the select() call as follow, the thread is indeed canceled: r = select(0, NULL, NULL, &tv); if ((r == -1) && (errno == EINTR)) pthread_testcancel(); I eventually found where linuxthreads.old defines cancellable system calls: wrapsyscall.c and added an entry for select(2). Note: select() was previously listed as a cancellation point but it got removed by Ulrich Depper and I don't know why: CVSROOT: /cvs/glibc Module name: libc Changes by: drepper at sourceware.org 2002-12-15 13:43:25 Modified files: linuxthreads : wrapsyscall.c Log message: Remove creat, poll, pselect, readv, select, sigpause, sigsuspend, sigwaitinfo, waitid, and writev wrappers. I have attached to this report, a patch re-introducing select(2). ---------------------------------------------------------------------- hmoffatt - 09-04-07 21:25 ---------------------------------------------------------------------- I have an application which is hanging with uClibc 0.9.29. The main process is regularly calling fork() and exec(). There is also a thread which is doing a select() with a 1ms timeout in an endless loop. The application sometimes hangs just after the fork/exec; the exec has happened (there is a zombie process left around). I tried the patch in this bug report; now the program segfaults instead of hanging. So I don't think the patch is the correct solution. ---------------------------------------------------------------------- chombourger - 09-05-07 00:30 ---------------------------------------------------------------------- Three questions: (a) have you tried running this program on a glibc system and does it work? (b) is your app. making any use of pthread_cancel() and pthread_join()? (c) can you provide us a stripped down version of your application so that we can reproduce the bug/segfault with it? ---------------------------------------------------------------------- hmoffatt - 09-05-07 02:58 ---------------------------------------------------------------------- My application is in Python. At the time my hang occurs I am not using pthread_join or cancel; a finite set of threads have been created some time earlier and should continue to exist for the life of the program. Hence the original problem in this report doesn't describe my situation. Nonetheless the patch had some impact which suggests it may not be right. My original process (not one of the threads) is regularly calling fork() and exec() (via python wrappers). It appears that the process hangs somewhere after exec(), before returning to my interpreted program. strace shows that the program did get SIGCHLD as the last thing that happened, meaning that the child has exited. Then it seems to be sleeping waiting for something to happen. There is another thread which is calling select() with a 1ms sleep indefinitely. I think it hangs also though I will have to retest to be sure. The thread manager thread seems to be still running ok, calling poll() with a 1 second timeout. strace shows it is still running. When I put in the patch from this report, the select() thread dies with SIGSEGV. I am trying to build glibc for the embedded system now. I will also try to run it on my desktop with glibc and reproduce it. ---------------------------------------------------------------------- hmoffatt - 09-05-07 21:58 ---------------------------------------------------------------------- I have now tested this with glibc 2.3.6 with linuxthreads (not NPTL). It segfaults just the same as with your patch for uClibc. I guess that could be considered a positive sign.. probably meaning that my bug is somewhere else. ---------------------------------------------------------------------- chombourger - 09-06-07 01:14 ---------------------------------------------------------------------- Ok interesting point. Do you have a backtrace when it crashes? Wondering if the segfaults occurs within the libc. ---------------------------------------------------------------------- hmoffatt - 09-06-07 07:45 ---------------------------------------------------------------------- My cross-gdb insists on trying to load the host libraries rather than the target ones so I can't get a meaningful back trace even though I have the build and a core file. :( Looks like it is reading the absolute paths from the core file; I really need to be able to prepend a path to those when loading into the cross-gdb. Is that possible? I have had even less success doing a live cross-gdb against gdbserver. ---------------------------------------------------------------------- chombourger - 09-06-07 07:51 ---------------------------------------------------------------------- You could use the gdb setting 'set solib-absolute-prefix PATH' to tell gdb the base prefix of your target file-system That used to work for me. Hope this helps! ---------------------------------------------------------------------- hmoffatt - 09-06-07 16:27 ---------------------------------------------------------------------- Great, solib-absolute-prefix was exactly what I needed. I got the following when tracing against glibc; I don't have a build with the latest uclibc ready to test at the moment. Core was generated by `/usr/bin/python /opt/calyptech/lib/webserver/server.py'. Program terminated with signal 11, Segmentation fault. http://busybox.net/bugs/view.php?id=0 0x4021b8ec in sem_wait () from /home/hamish/work/robots/glibc-romfs/lib/libpthread.so.0 (gdb) (gdb) bt http://busybox.net/bugs/view.php?id=0 0x4021b8ec in sem_wait () from /home/hamish/work/robots/glibc-romfs/lib/libpthread.so.0 http://busybox.net/bugs/view.php?id=1 0xbe5ff54c in ?? () gdb is insisting that my core file does not match the python binary though so it may be confused. I'm sure that it does (I copied the binary back out of the embedded system). I'm not sure if this is related to threads or not. Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 06-27-07 13:52 chombourger Note Edited: 0002528 06-30-07 12:49 chombourger Note Edited: 0002528 06-30-07 14:18 chombourger File Added: uClibc-select-cancellation-point.patch 06-30-07 14:22 chombourger Note Edited: 0002528 07-01-07 22:26 chombourger Issue Monitored: chombourger 09-04-07 21:25 hmoffatt Note Added: 0002712 09-05-07 00:30 chombourger Note Added: 0002713 09-05-07 02:58 hmoffatt Note Added: 0002714 09-05-07 21:58 hmoffatt Note Added: 0002721 09-06-07 01:14 chombourger Note Added: 0002722 09-06-07 07:45 hmoffatt Note Added: 0002723 09-06-07 07:51 chombourger Note Added: 0002724 09-06-07 16:27 hmoffatt Note Added: 0002725 ====================================================================== From bugs at busybox.net Thu Sep 6 18:44:09 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 6 Sep 2007 18:44:09 -0700 Subject: [uClibc 0001493]: fopen(, "a") or "w" causes crash. The gdb data follows: Message-ID: <2e909fb2f896220ba10d7f54fc324e1f@busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1493 ====================================================================== Reported By: akennedy Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1493 Category: Other Reproducibility: always Severity: crash Priority: normal Status: assigned ====================================================================== Date Submitted: 09-06-2007 18:44 PDT Last Modified: 09-06-2007 18:44 PDT ====================================================================== Summary: fopen(, "a") or "w" causes crash. The gdb data follows: Description: http://busybox.net/bugs/view.php?id=0 0x0805d17f in __malloc_consolidate () (gdb) backtrace http://busybox.net/bugs/view.php?id=0 0x0805d17f in __malloc_consolidate () http://busybox.net/bugs/view.php?id=1 0x0805c65d in malloc () http://busybox.net/bugs/view.php?id=2 0x0805a98f in _stdio_fopen () http://busybox.net/bugs/view.php?id=3 0x0805a61e in fopen () ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 09-06-07 18:44 akennedy New Issue 09-06-07 18:44 akennedy Status new => assigned 09-06-07 18:44 akennedy Assigned To => uClibc ====================================================================== From bugs at busybox.net Fri Sep 7 07:36:10 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 7 Sep 2007 07:36:10 -0700 Subject: [uClibc 0001493]: fopen(, "a") or "w" causes crash. The gdb data follows: Message-ID: <6695d430fe4bd1cb8c65fade73832788@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1493 ====================================================================== Reported By: akennedy Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1493 Category: Other Reproducibility: always Severity: crash Priority: normal Status: assigned ====================================================================== Date Submitted: 09-06-2007 18:44 PDT Last Modified: 09-07-2007 07:36 PDT ====================================================================== Summary: fopen(, "a") or "w" causes crash. The gdb data follows: Description: http://busybox.net/bugs/view.php?id=0 0x0805d17f in __malloc_consolidate () (gdb) backtrace http://busybox.net/bugs/view.php?id=0 0x0805d17f in __malloc_consolidate () http://busybox.net/bugs/view.php?id=1 0x0805c65d in malloc () http://busybox.net/bugs/view.php?id=2 0x0805a98f in _stdio_fopen () http://busybox.net/bugs/view.php?id=3 0x0805a61e in fopen () ====================================================================== ---------------------------------------------------------------------- akennedy - 09-07-07 07:36 ---------------------------------------------------------------------- This error seems to be only in the file: libc/stdlib/malloc-standard/free.c because when I changed to the simple-malloc, I no longer get the segfault. Issue History Date Modified Username Field Change ====================================================================== 09-06-07 18:44 akennedy New Issue 09-06-07 18:44 akennedy Status new => assigned 09-06-07 18:44 akennedy Assigned To => uClibc 09-06-07 19:07 akennedy Issue Monitored: akennedy 09-07-07 07:36 akennedy Note Added: 0002726 ====================================================================== From bugs at busybox.net Thu Sep 13 07:27:36 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 13 Sep 2007 07:27:36 -0700 Subject: [uClibc 0001500]: Cross compiler toolchain build issue using buildroot with uClibc-0.9.26(Linux kernel version 2.6.18) Message-ID: <53682d4c23a094a48deaa9afc8ea7a55@busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1500 ====================================================================== Reported By: rahul Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1500 Category: Other Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 09-13-2007 07:27 PDT Last Modified: 09-13-2007 07:27 PDT ====================================================================== Summary: Cross compiler toolchain build issue using buildroot with uClibc-0.9.26(Linux kernel version 2.6.18) Description: I am trying to build the toolchain using buildroot with uClibc-0.9.26. I am using the kernel version linux-2.6.18 It is throwing errors. Error log: In file included from fork.S:57: ../../../../include/asm/mipsregs.h:205:2: #error Bad page size configuration! make[6]: *** [fork.o] Error 1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 09-13-07 07:27 rahul New Issue 09-13-07 07:27 rahul Status new => assigned 09-13-07 07:27 rahul Assigned To => uClibc ====================================================================== From bugs at busybox.net Thu Sep 13 11:24:12 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 13 Sep 2007 11:24:12 -0700 Subject: [uClibc 0001501]: BASH built with uClibc does not support "set -o pipefail" or $PIPESTATUS builtin variable Message-ID: <441e7040f1cf2effee2b8d197b72cdd0@busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1501 ====================================================================== Reported By: murphy666 Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1501 Category: Architecture Specific Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 09-13-2007 11:24 PDT Last Modified: 09-13-2007 11:24 PDT ====================================================================== Summary: BASH built with uClibc does not support "set -o pipefail" or $PIPESTATUS builtin variable Description: When building BASH (3.2 or 3.1 with latest patch) using buildroot & uClibc (tested uClibc 0.9.29,0.9.28.3) I'm unable to use PIPEFAIL or PIPESTATUS. PIPESTATUS Description : http://tldp.org/LDP/abs/html/internalvariables.html pipefail script example : set -o pipefail cat /tmp/anynotfound | tee -a /tmp/test will always return 0 has exit code. with the pipefail mode, the exit code should be the last non zero exit code (in this example cat /tmp/anynotfound fail so it should return 1) PIPESTATUS exmaple : exit 1 | exit 2 | exit 3 echo ${PIPESTATUS[@]} PIPESTATUS should return string "1 2 3" but always return "0" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 09-13-07 11:24 murphy666 New Issue 09-13-07 11:24 murphy666 Status new => assigned 09-13-07 11:24 murphy666 Assigned To => uClibc ====================================================================== From vapier at uclibc.org Fri Sep 14 17:26:11 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 14 Sep 2007 17:26:11 -0700 (PDT) Subject: svn commit: trunk/uClibc/extra/config/lxdialog Message-ID: <20070915002611.1847330060@busybox.net> Author: vapier Date: 2007-09-14 17:26:11 -0700 (Fri, 14 Sep 2007) New Revision: 19832 Log: fix from Kevin Day to make sure we use strchr() rather than index() Modified: trunk/uClibc/extra/config/lxdialog/util.c Changeset: Modified: trunk/uClibc/extra/config/lxdialog/util.c =================================================================== --- trunk/uClibc/extra/config/lxdialog/util.c 2007-09-14 18:48:44 UTC (rev 19831) +++ trunk/uClibc/extra/config/lxdialog/util.c 2007-09-15 00:26:11 UTC (rev 19832) @@ -336,7 +336,7 @@ newl = 1; word = tempstr; while (word && *word) { - sp = index(word, ' '); + sp = strchr(word, ' '); if (sp) *sp++ = 0; @@ -348,7 +348,7 @@ if (wlen > room || (newl && wlen < 4 && sp && wlen + 1 + strlen(sp) > room - && (!(sp2 = index(sp, ' ')) + && (!(sp2 = strchr(sp, ' ')) || wlen + 1 + (sp2 - sp) > room))) { cur_y++; cur_x = x; From vapier at uclibc.org Fri Sep 14 17:36:49 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 14 Sep 2007 17:36:49 -0700 (PDT) Subject: svn commit: trunk/uClibc/include Message-ID: <20070915003649.6F0B930043@busybox.net> Author: vapier Date: 2007-09-14 17:36:49 -0700 (Fri, 14 Sep 2007) New Revision: 19833 Log: drop __user hack for crappy kernel headers and document the __linux__ grease Modified: trunk/uClibc/include/features.h Changeset: Modified: trunk/uClibc/include/features.h =================================================================== --- trunk/uClibc/include/features.h 2007-09-15 00:26:11 UTC (rev 19832) +++ trunk/uClibc/include/features.h 2007-09-15 00:36:49 UTC (rev 19833) @@ -413,12 +413,12 @@ # include #endif +/* Some people like to build up uClibc with *-elf toolchains, so + * a little grease here until we drop '#ifdef __linux__' checks + * from our source code. + */ #ifndef __linux__ # define __linux__ 1 #endif -/* Disable __user, which shows up in 2.6.x include asm headers - * that get pulled in by signal.h */ -#define __user - #endif /* features.h */ From vapier at uclibc.org Fri Sep 14 17:52:56 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 14 Sep 2007 17:52:56 -0700 (PDT) Subject: svn commit: trunk/uClibc/libc/string Message-ID: <20070915005256.98DEB30043@busybox.net> Author: vapier Date: 2007-09-14 17:52:56 -0700 (Fri, 14 Sep 2007) New Revision: 19834 Log: add strerror_r symbol alias as some autotool based packages simply use AC_CHECK_LIB() to see if a function exists rather than checking the headers Modified: trunk/uClibc/libc/string/__xpg_strerror_r.c Changeset: Modified: trunk/uClibc/libc/string/__xpg_strerror_r.c =================================================================== --- trunk/uClibc/libc/string/__xpg_strerror_r.c 2007-09-15 00:36:49 UTC (rev 19833) +++ trunk/uClibc/libc/string/__xpg_strerror_r.c 2007-09-15 00:52:56 UTC (rev 19834) @@ -5,11 +5,16 @@ * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. */ +/* Make sure we get proper strerror_r() prototype */ +#define strerror_r __moo + #include #include #include #include "_syserrmsg.h" +#undef strerror_r + libc_hidden_proto(__xpg_strerror_r) libc_hidden_proto(memcpy) libc_hidden_proto(strlen) @@ -271,3 +276,4 @@ #endif /* __UCLIBC_HAS_ERRNO_MESSAGES__ */ libc_hidden_def(__xpg_strerror_r) +weak_alias(__xpg_strerror_r, strerror_r) From vapier at uclibc.org Fri Sep 14 20:58:21 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 14 Sep 2007 20:58:21 -0700 (PDT) Subject: svn commit: trunk/uClibc/test/inet Message-ID: <20070915035821.74AD030043@busybox.net> Author: vapier Date: 2007-09-14 20:58:20 -0700 (Fri, 14 Sep 2007) New Revision: 19835 Log: actually update errors variable when a test fails Modified: trunk/uClibc/test/inet/tst-network.c Changeset: Modified: trunk/uClibc/test/inet/tst-network.c =================================================================== --- trunk/uClibc/test/inet/tst-network.c 2007-09-15 00:52:56 UTC (rev 19834) +++ trunk/uClibc/test/inet/tst-network.c 2007-09-15 03:58:20 UTC (rev 19835) @@ -61,6 +61,7 @@ if (res != tests[i].number) { + ++errors; printf ("Test failed for inet_network (\"%s\"):\n", tests[i].network); printf ("Expected return value %u (0x%x) but got %u (0x%x).\n", From vapier at uclibc.org Fri Sep 14 23:50:03 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 14 Sep 2007 23:50:03 -0700 (PDT) Subject: svn commit: trunk/uClibc/include/netinet Message-ID: <20070915065003.63AE9A48EC@busybox.net> Author: vapier Date: 2007-09-14 23:50:02 -0700 (Fri, 14 Sep 2007) New Revision: 19836 Log: sync with glibc Modified: trunk/uClibc/include/netinet/icmp6.h trunk/uClibc/include/netinet/if_tr.h trunk/uClibc/include/netinet/ip6.h Changeset: Modified: trunk/uClibc/include/netinet/icmp6.h =================================================================== --- trunk/uClibc/include/netinet/icmp6.h 2007-09-15 03:58:20 UTC (rev 19835) +++ trunk/uClibc/include/netinet/icmp6.h 2007-09-15 06:50:02 UTC (rev 19836) @@ -1,4 +1,4 @@ -/* Copyright (C) 1991,92,93,94,95,96,97,2000 Free Software Foundation, Inc. +/* Copyright (C) 1991-1997,2000,2006 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -191,13 +191,13 @@ /* followed by option specific data */ }; -#define ND_OPT_SOURCE_LINKADDR 1 -#define ND_OPT_TARGET_LINKADDR 2 -#define ND_OPT_PREFIX_INFORMATION 3 -#define ND_OPT_REDIRECTED_HEADER 4 -#define ND_OPT_MTU 5 -#define ND_OPT_RTR_ADV_INTERVAL 7 -#define ND_OPT_HOME_AGENT_INFO 8 +#define ND_OPT_SOURCE_LINKADDR 1 +#define ND_OPT_TARGET_LINKADDR 2 +#define ND_OPT_PREFIX_INFORMATION 3 +#define ND_OPT_REDIRECTED_HEADER 4 +#define ND_OPT_MTU 5 +#define ND_OPT_RTR_ADV_INTERVAL 7 +#define ND_OPT_HOME_AGENT_INFO 8 struct nd_opt_prefix_info /* prefix information */ { @@ -211,9 +211,9 @@ struct in6_addr nd_opt_pi_prefix; }; -#define ND_OPT_PI_FLAG_ONLINK 0x80 -#define ND_OPT_PI_FLAG_AUTO 0x40 -#define ND_OPT_PI_FLAG_RADDR 0x20 +#define ND_OPT_PI_FLAG_ONLINK 0x80 +#define ND_OPT_PI_FLAG_AUTO 0x40 +#define ND_OPT_PI_FLAG_RADDR 0x20 struct nd_opt_rd_hdr /* redirected header */ { @@ -300,11 +300,11 @@ #define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x10 #if BYTE_ORDER == BIG_ENDIAN -# define ICMP6_RR_PCOUSE_DECRVLTIME 0x80000000 -# define ICMP6_RR_PCOUSE_DECRPLTIME 0x40000000 +# define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000 +# define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000 #elif BYTE_ORDER == LITTLE_ENDIAN -# define ICMP6_RR_PCOUSE_DECRVLTIME 0x80 -# define ICMP6_RR_PCOUSE_DECRPLTIME 0x40 +# define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80 +# define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40 #endif struct rr_result /* router renumbering result message */ Modified: trunk/uClibc/include/netinet/if_tr.h =================================================================== --- trunk/uClibc/include/netinet/if_tr.h 2007-09-15 03:58:20 UTC (rev 19835) +++ trunk/uClibc/include/netinet/if_tr.h 2007-09-15 06:50:02 UTC (rev 19836) @@ -1,4 +1,4 @@ -/* Copyright (C) 1997 Free Software Foundation, Inc. +/* Copyright (C) 1997, 2005 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -21,13 +21,83 @@ #include #include -#include -#include +/* IEEE 802.5 Token-Ring magic constants. The frame sizes omit the preamble + and FCS/CRC (frame check sequence). */ +#define TR_ALEN 6 /* Octets in one token-ring addr */ +#define TR_HLEN (sizeof (struct trh_hdr) + sizeof (struct trllc)) +#define AC 0x10 +#define LLC_FRAME 0x40 +/* LLC and SNAP constants */ +#define EXTENDED_SAP 0xAA +#define UI_CMD 0x03 + +/* This is an Token-Ring frame header. */ +struct trh_hdr +{ + u_int8_t ac; /* access control field */ + u_int8_t fc; /* frame control field */ + u_int8_t daddr[TR_ALEN]; /* destination address */ + u_int8_t saddr[TR_ALEN]; /* source address */ + u_int16_t rcf; /* route control field */ + u_int16_t rseg[8]; /* routing registers */ +}; + +/* This is an Token-Ring LLC structure */ +struct trllc +{ + u_int8_t dsap; /* destination SAP */ + u_int8_t ssap; /* source SAP */ + u_int8_t llc; /* LLC control field */ + u_int8_t protid[3]; /* protocol id */ + u_int16_t ethertype; /* ether type field */ +}; + +/* Token-Ring statistics collection data. */ +struct tr_statistics +{ + unsigned long rx_packets; /* total packets received */ + unsigned long tx_packets; /* total packets transmitted */ + unsigned long rx_bytes; /* total bytes received */ + unsigned long tx_bytes; /* total bytes transmitted */ + unsigned long rx_errors; /* bad packets received */ + unsigned long tx_errors; /* packet transmit problems */ + unsigned long rx_dropped; /* no space in linux buffers */ + unsigned long tx_dropped; /* no space available in linux */ + unsigned long multicast; /* multicast packets received */ + unsigned long transmit_collision; + + /* detailed Token-Ring errors. See IBM Token-Ring Network + Architecture for more info */ + + unsigned long line_errors; + unsigned long internal_errors; + unsigned long burst_errors; + unsigned long A_C_errors; + unsigned long abort_delimiters; + unsigned long lost_frames; + unsigned long recv_congest_count; + unsigned long frame_copied_errors; + unsigned long frequency_errors; + unsigned long token_errors; + unsigned long dummy1; +}; + +/* source routing stuff */ +#define TR_RII 0x80 +#define TR_RCF_DIR_BIT 0x80 +#define TR_RCF_LEN_MASK 0x1f00 +#define TR_RCF_BROADCAST 0x8000 /* all-routes broadcast */ +#define TR_RCF_LIMITED_BROADCAST 0xC000 /* single-route broadcast */ +#define TR_RCF_FRAME2K 0x20 +#define TR_RCF_BROADCAST_MASK 0xC000 +#define TR_MAXRIFLEN 18 + #ifdef __USE_BSD -struct trn_hdr { +struct trn_hdr +{ u_int8_t trn_ac; /* access control field */ u_int8_t trn_fc; /* field control field */ u_int8_t trn_dhost[TR_ALEN]; /* destination host */ Modified: trunk/uClibc/include/netinet/ip6.h =================================================================== --- trunk/uClibc/include/netinet/ip6.h 2007-09-15 03:58:20 UTC (rev 19835) +++ trunk/uClibc/include/netinet/ip6.h 2007-09-15 06:50:02 UTC (rev 19836) @@ -1,4 +1,4 @@ -/* Copyright (C) 1991-1997, 2001, 2003 Free Software Foundation, Inc. +/* Copyright (C) 1991-1997, 2001, 2003, 2006 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -89,7 +89,8 @@ uint8_t ip6r0_segleft; /* segments left */ uint8_t ip6r0_reserved; /* reserved field */ uint8_t ip6r0_slmap[3]; /* strict/loose bit map */ - struct in6_addr ip6r0_addr[1]; /* up to 23 addresses */ + /* followed by up to 127 struct in6_addr */ + struct in6_addr ip6r0_addr[0]; }; /* Fragment header */ @@ -101,14 +102,14 @@ uint32_t ip6f_ident; /* identification */ }; -#if BYTE_ORDER == BIG_ENDIAN -#define IP6F_OFF_MASK 0xfff8 /* mask out offset from _offlg */ -#define IP6F_RESERVED_MASK 0x0006 /* reserved bits in ip6f_offlg */ -#define IP6F_MORE_FRAG 0x0001 /* more-fragments flag */ +#if BYTE_ORDER == BIG_ENDIAN +# define IP6F_OFF_MASK 0xfff8 /* mask out offset from _offlg */ +# define IP6F_RESERVED_MASK 0x0006 /* reserved bits in ip6f_offlg */ +# define IP6F_MORE_FRAG 0x0001 /* more-fragments flag */ #else /* BYTE_ORDER == LITTLE_ENDIAN */ -#define IP6F_OFF_MASK 0xf8ff /* mask out offset from _offlg */ -#define IP6F_RESERVED_MASK 0x0600 /* reserved bits in ip6f_offlg */ -#define IP6F_MORE_FRAG 0x0100 /* more-fragments flag */ +# define IP6F_OFF_MASK 0xf8ff /* mask out offset from _offlg */ +# define IP6F_RESERVED_MASK 0x0600 /* reserved bits in ip6f_offlg */ +# define IP6F_MORE_FRAG 0x0100 /* more-fragments flag */ #endif /* IPv6 options */ @@ -175,7 +176,7 @@ }; /* Router alert values (in network byte order) */ -#if BYTE_ORDER == BIG_ENDIAN +#if BYTE_ORDER == BIG_ENDIAN # define IP6_ALERT_MLD 0x0000 # define IP6_ALERT_RSVP 0x0001 # define IP6_ALERT_AN 0x0002 From bugs at busybox.net Sat Sep 15 00:15:50 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Sat, 15 Sep 2007 00:15:50 -0700 Subject: [uClibc 0001500]: Cross compiler toolchain build issue using buildroot with uClibc-0.9.26(Linux kernel version 2.6.18) Message-ID: <821274228166728795a5657347705c5d@busybox.net> The following issue has been CLOSED ====================================================================== http://busybox.net/bugs/view.php?id=1500 ====================================================================== Reported By: rahul Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1500 Category: Other Reproducibility: always Severity: major Priority: normal Status: closed Resolution: no change required Fixed in Version: ====================================================================== Date Submitted: 09-13-2007 07:27 PDT Last Modified: 09-15-2007 00:15 PDT ====================================================================== Summary: Cross compiler toolchain build issue using buildroot with uClibc-0.9.26(Linux kernel version 2.6.18) Description: I am trying to build the toolchain using buildroot with uClibc-0.9.26. I am using the kernel version linux-2.6.18 It is throwing errors. Error log: In file included from fork.S:57: ../../../../include/asm/mipsregs.h:205:2: #error Bad page size configuration! make[6]: *** [fork.o] Error 1 ====================================================================== ---------------------------------------------------------------------- vapier - 09-15-07 00:15 ---------------------------------------------------------------------- 0.9.26 isnt supported ... i imagine that error is fixed in newer versions Issue History Date Modified Username Field Change ====================================================================== 09-13-07 07:27 rahul New Issue 09-13-07 07:27 rahul Status new => assigned 09-13-07 07:27 rahul Assigned To => uClibc 09-15-07 00:15 vapier Note Added: 0002741 09-15-07 00:15 vapier Status assigned => closed 09-15-07 00:15 vapier Resolution open => no change required ====================================================================== From vapier at uclibc.org Sat Sep 15 00:25:55 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Sat, 15 Sep 2007 00:25:55 -0700 (PDT) Subject: svn commit: trunk/uClibc/libc/sysdeps/linux/mips Message-ID: <20070915072555.393C4A4944@busybox.net> Author: vapier Date: 2007-09-15 00:25:54 -0700 (Sat, 15 Sep 2007) New Revision: 19837 Log: Atsushi Nemoto writes: In MIPS syscall(2), .cpload was added to an the error path, but it was not enough for ABIs other then O32. Use SETUP_GP, SETUP_GP64 and RESTORE_GP64 to handle all ABIs. This patch fixes an error path of MIPS pipe(2) too. Modified: trunk/uClibc/libc/sysdeps/linux/mips/pipe.S trunk/uClibc/libc/sysdeps/linux/mips/syscall.S Changeset: Modified: trunk/uClibc/libc/sysdeps/linux/mips/pipe.S =================================================================== --- trunk/uClibc/libc/sysdeps/linux/mips/pipe.S 2007-09-15 06:50:02 UTC (rev 19836) +++ trunk/uClibc/libc/sysdeps/linux/mips/pipe.S 2007-09-15 07:25:54 UTC (rev 19837) @@ -14,7 +14,11 @@ .globl pipe .ent pipe, 0 + .type pipe, at function pipe: +#ifdef __PIC__ + SETUP_GP +#endif li v0,__NR_pipe syscall bnez a3, 1f @@ -28,7 +32,9 @@ /* uClibc change -- stop */ #ifdef __PIC__ + SETUP_GP64(v0, pipe) PTR_LA t9, __syscall_error + RESTORE_GP64 jr t9 #else j __syscall_error Modified: trunk/uClibc/libc/sysdeps/linux/mips/syscall.S =================================================================== --- trunk/uClibc/libc/sysdeps/linux/mips/syscall.S 2007-09-15 06:50:02 UTC (rev 19836) +++ trunk/uClibc/libc/sysdeps/linux/mips/syscall.S 2007-09-15 07:25:54 UTC (rev 19837) @@ -29,8 +29,10 @@ .type syscall, at function .ent syscall syscall: +#ifdef __PIC__ + SETUP_GP +#endif .set noreorder - .cpload t9; move v0, a0 /* Load system call number from first arg. */ move a0, a1 /* Move the next three args up a register. */ move a1, a2 @@ -68,7 +70,9 @@ move a0,v0 /* Pass return val to C function. */ #ifdef __PIC__ + SETUP_GP64(v0, syscall) PTR_LA t9, __syscall_error + RESTORE_GP64 jr t9 #else j __syscall_error From vapier at uclibc.org Sat Sep 15 00:40:58 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Sat, 15 Sep 2007 00:40:58 -0700 (PDT) Subject: svn commit: trunk/uClibc/libc Message-ID: <20070915074058.0A036A5D36@busybox.net> Author: vapier Date: 2007-09-15 00:40:58 -0700 (Sat, 15 Sep 2007) New Revision: 19838 Log: setup OUTPUT_FORMAT() in linker script (helps with multilib) Modified: trunk/uClibc/libc/Makefile.in Changeset: Modified: trunk/uClibc/libc/Makefile.in =================================================================== --- trunk/uClibc/libc/Makefile.in 2007-09-15 07:25:54 UTC (rev 19837) +++ trunk/uClibc/libc/Makefile.in 2007-09-15 07:40:58 UTC (rev 19838) @@ -54,6 +54,8 @@ lib-so-y += $(libc) objclean-y += libc_clean +OUTPUT_FORMAT = $(CC) $(CFLAGS) $(LDFLAGS) -Wl,--verbose 2>&1 | sed -n 's/^OUTPUT_FORMAT("\([^"]*\)",.*/\1/p' + ifeq ($(DOMULTI),n) $(libc:.$(MAJOR_VERSION)=): $(libc_OUT)/libc_so.a $(LIBS-libc.so) $(call link.so,$(libc_FULL_NAME),$(MAJOR_VERSION)) @@ -64,6 +66,7 @@ endif $(Q)$(RM) $@ $(Q)cp $(top_srcdir)extra/scripts/format.lds $@ + $(Q)echo "OUTPUT_FORMAT ( $(shell $(OUTPUT_FORMAT)) )" >> $@ ifeq ($(COMPAT_ATEXIT),y) $(Q)echo "GROUP ( $(NONSHARED_LIBNAME) $(SHARED_MAJORNAME) $(ASNEEDED) )" >> $@ else From vapier at uclibc.org Sat Sep 15 00:42:01 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Sat, 15 Sep 2007 00:42:01 -0700 (PDT) Subject: svn commit: trunk/uClibc Message-ID: <20070915074201.DE1BAA5D36@busybox.net> Author: vapier Date: 2007-09-15 00:42:01 -0700 (Sat, 15 Sep 2007) New Revision: 19839 Log: simplify binutils as-needed support and enable it all the time regardless of ssp Modified: trunk/uClibc/Rules.mak Changeset: Modified: trunk/uClibc/Rules.mak =================================================================== --- trunk/uClibc/Rules.mak 2007-09-15 07:40:58 UTC (rev 19838) +++ trunk/uClibc/Rules.mak 2007-09-15 07:42:01 UTC (rev 19839) @@ -335,12 +335,8 @@ # Check for AS_NEEDED support in linker script (binutils>=2.16.1 has it) ifndef ASNEEDED -ifneq ($(UCLIBC_HAS_SSP),y) -export ASNEEDED:= -else -export ASNEEDED:=$(shell (LD_TMP=$(mktemp LD_XXXXXX) ; echo "GROUP ( AS_NEEDED ( /usr/lib/libc.so ) )" > $LD_TMP && if $(LD) -T $LD_TMP -o /dev/null > /dev/null 2>&1; then echo "AS_NEEDED ( $(UCLIBC_LDSO) )"; else echo "$(UCLIBC_LDSO)"; fi; rm -f $LD_TMP ) ) +export ASNEEDED:=$(shell $(LD) --help 2>/dev/null | grep -q -- --as-needed && echo "AS_NEEDED ( $(UCLIBC_LDSO) )" || echo "$(UCLIBC_LDSO)") endif -endif # Add a bunch of extra pedantic annoyingly strict checks XWARNINGS=$(subst ",, $(strip $(WARNINGS))) -Wstrict-prototypes -fno-strict-aliasing From vapier at uclibc.org Sat Sep 15 00:50:59 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Sat, 15 Sep 2007 00:50:59 -0700 (PDT) Subject: svn commit: trunk/uClibc: ldso/include ldso/ldso/sparc libc/string etc... Message-ID: <20070915075059.68EC4A6056@busybox.net> Author: vapier Date: 2007-09-15 00:50:58 -0700 (Sat, 15 Sep 2007) New Revision: 19840 Log: Blue Swirl writes: I got the library to compile with the attached patches, though dynamic loader crashes early. In buildroot I changed the architecture name by hand from sparc to sparc64, otherwise the compiler produced 32-bit files with V9 (64-bit) instructions. This configuration is not supported by QEMU, so I aimed for pure 64-bit. I think Sparc64 option needs to be added to buildroot. The _Qp_ ops seem to be required by the ABI. This and setjmp patches are just hacks to get the compilation further. The _Qp_ ops can be found in glibc, would it be OK to use those? V9 assembler requires declarations for global register use. The mem* functions in sparc32 directory did not work. They are actually used only by the hybrid 32-bit + V9 CPU configuration. Modified: trunk/uClibc/ldso/include/dl-syscall.h trunk/uClibc/ldso/ldso/sparc/dl-startup.h trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memchr.S trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memcpy.S trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memset.S trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/stpcpy.S trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcat.S trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strchr.S trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcmp.S trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcpy.S trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strlen.S trunk/uClibc/libc/sysdeps/linux/sparc/Makefile.arch trunk/uClibc/libc/sysdeps/linux/sparc/__longjmp.S trunk/uClibc/libc/sysdeps/linux/sparc/_math_inc.h trunk/uClibc/libc/sysdeps/linux/sparc/bits/setjmp.h Changeset: Modified: trunk/uClibc/ldso/include/dl-syscall.h =================================================================== --- trunk/uClibc/ldso/include/dl-syscall.h 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/ldso/include/dl-syscall.h 2007-09-15 07:50:58 UTC (rev 19840) @@ -16,7 +16,11 @@ /* Pull in whatever this particular arch's kernel thinks the kernel version of * struct stat should look like. It turns out that each arch has a different * opinion on the subject, and different kernel revs use different names... */ +#if defined(__sparc_v9__) && (__WORDSIZE == 64) +#define kernel_stat64 stat +#else #define kernel_stat stat +#endif #include #include Modified: trunk/uClibc/ldso/ldso/sparc/dl-startup.h =================================================================== --- trunk/uClibc/ldso/ldso/sparc/dl-startup.h 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/ldso/ldso/sparc/dl-startup.h 2007-09-15 07:50:58 UTC (rev 19840) @@ -9,6 +9,7 @@ .global _start\n\ .type _start,%function\n\ .align 32\n\ + .register %g2, #scratch\n\ _start:\n\ /* Allocate space for functions to drop their arguments. */\n\ sub %sp, 6*4, %sp\n\ Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memchr.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memchr.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memchr.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include "sparc64/memchr.S" +#include "../../sparc64/memchr.S" Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memcpy.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memcpy.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memcpy.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include "sparc64/sparcv9b/memcpy.S" +#include "../../sparc64/sparcv9b/memcpy.S" Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memset.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memset.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/memset.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include +#include "../../sparc64/memset.S" Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/stpcpy.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/stpcpy.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/stpcpy.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include +#include "../../sparc64/stpcpy.S" Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcat.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcat.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcat.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include +#include "../../sparc64/strcat.S" Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strchr.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strchr.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strchr.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include +#include "../../sparc64/strchr.S" Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcmp.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcmp.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcmp.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include +#include "../../sparc64/strcmp.S" Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcpy.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcpy.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strcpy.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include +#include "../../sparc64/strcpy.S" Modified: trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strlen.S =================================================================== --- trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strlen.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/string/sparc/sparc32/sparcv9b/strlen.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -1,4 +1,4 @@ #define ASI_PNF 0x82 #define ASI_BLK_P 0xf0 #define XCC icc -#include +#include "../../sparc64/strlen.S" Modified: trunk/uClibc/libc/sysdeps/linux/sparc/Makefile.arch =================================================================== --- trunk/uClibc/libc/sysdeps/linux/sparc/Makefile.arch 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/sysdeps/linux/sparc/Makefile.arch 2007-09-15 07:50:58 UTC (rev 19840) @@ -5,7 +5,7 @@ # Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. # -CSRC := brk.c __syscall_error.c +CSRC := brk.c __syscall_error.c qp_ops.c SSRC := \ __longjmp.S fork.S vfork.S clone.S setjmp.S bsd-setjmp.S bsd-_setjmp.S \ Modified: trunk/uClibc/libc/sysdeps/linux/sparc/__longjmp.S =================================================================== --- trunk/uClibc/libc/sysdeps/linux/sparc/__longjmp.S 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/sysdeps/linux/sparc/__longjmp.S 2007-09-15 07:50:58 UTC (rev 19840) @@ -30,7 +30,8 @@ .type __longjmp,%function .align 4 __longjmp: - + .register %g2, #scratch + .register %g3, #scratch /* Store our arguments in global registers so we can still * use them while unwinding frames and their register windows. */ Modified: trunk/uClibc/libc/sysdeps/linux/sparc/_math_inc.h =================================================================== --- trunk/uClibc/libc/sysdeps/linux/sparc/_math_inc.h 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/sysdeps/linux/sparc/_math_inc.h 2007-09-15 07:50:58 UTC (rev 19840) @@ -7,7 +7,9 @@ #include #define __ASSEMBLY__ +#ifndef __sparc_v9__ #include +#endif /* Is alignment really needed? */ Modified: trunk/uClibc/libc/sysdeps/linux/sparc/bits/setjmp.h =================================================================== --- trunk/uClibc/libc/sysdeps/linux/sparc/bits/setjmp.h 2007-09-15 07:42:01 UTC (rev 19839) +++ trunk/uClibc/libc/sysdeps/linux/sparc/bits/setjmp.h 2007-09-15 07:50:58 UTC (rev 19840) @@ -25,7 +25,7 @@ #include -#if __WORDSIZE == 64 +#if 0 /*__WORDSIZE == 64*/ #ifndef _ASM typedef struct __sparc64_jmp_buf From vapier at uclibc.org Sat Sep 15 01:11:31 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Sat, 15 Sep 2007 01:11:31 -0700 (PDT) Subject: svn commit: trunk/uClibc/test/inet Message-ID: <20070915081131.5ED48A606B@busybox.net> Author: vapier Date: 2007-09-15 01:11:30 -0700 (Sat, 15 Sep 2007) New Revision: 19841 Log: add more tests as suggested by Natanael Copa and as harvested from: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92880 Modified: trunk/uClibc/test/inet/tst-network.c Changeset: Modified: trunk/uClibc/test/inet/tst-network.c