Subject: RE: Do you support pthread_cond_timedwait() function?
From: Kevin Hendricks (khendricks@ivey.uwo.ca)
Date: Wed Feb 06 2002 - 07:13:41 MST
Hi,
Your test code test.cc does exactly what it is supposed to do even in
your gdb runs (it never gets the SIGBUS that your real code does).
Since parameters are passed in registers in ppc, to get gdb to properly
show parameters in stack chains you must compile the code with -g and
-O0 (turn off optimzation, otherwise gdb may not properly show all
parameters in the list properly...they may never be stored to memory if
optimizations are turned on (x86 uses a parameter stack which never
exhibits this problem). If you change you compile to use the following:
g++ -O0 -g -D_REENTRANT -o test test.cc /usr/lib/libpthread.a
And then use gdb to step through you will see that the paramaters are
then saved to memory and are properly listed. Also, remember glibc is
compiled with -O2 or higher which means when you use gdb within glibc
the paramter lists may not be correct. If you want to debug inside
glibc, with a new gdb you need to build a new glibc with -O0 and -g.
You code simply runs fine on my machine and when properly compiled to
use gdb with ppc (-O0 -g) it shows nice values in the parameter lists.
My guess is that your problem is really someplace else and your test
code is not recreating the problem conditions.
If you want my help you will need to either show me the exact source of
what is actually creating the SIGBUS that I can compile myself or make a
real test program that actually generates a SIGBUS that I can compile
and test myself.
Kevin
> Hi,
> Thanks for you response, but I cannot solve the problem.
>
> 1. I can not recreate your problem using glibc-2.2.4 which is available
> as an update to for YDL 2.1 in the software section on the yellowdog ftp
> site
>
> My system version is here,
> I installed YDL 2.1 by CD-ROM(fuji-2.1-20011105-install.iso), and
> updated
> glibc/gcc/binutils in Yellow Dog Linux 2.1 Errata. The result of
> debugging in my system is always same, strange.
> Do you say that the test.cc works correctly in your system without
> changing of pointers?
>
> 2. Why the use of #pragma pack(1)? Is this really needed? PPC has
> alignment issues for structures that might be impacted by this command.
> Does the problem still happen in your test code without the "pragma
> pack(1)" with stock YDL 2.x glibc?
>
> I had complied test.cc without "pragma pack(1)", but the result of
> debugging is same. I described my ppc system, my pentium system, result
> of debugging, source of condvar.c, test.cc bellow. The result of
> debugging is without "pragma pack(1)" definition.
>
> I tried to find the "condvar.c" source code, and I found it
> (http://sources.redhat.com/cgi-
> bin/cvsweb.cgi/libc/linuxthreads/?cvsroot=
> glibc) According to "condvar.c" source code, pthread_cond_timewait()
> function just call pthread_cond_timedwait_relative() function, and the
> same parameters in function definition. Why the "cond", "mutex" and
> "abstime" pointer is change?
> Why the source code had a pthread_cond_timewait_relative() function is
> different?("at internals.h:384" in ppc, "at condvar.c:140" in pentium)
>
> ####[My PPC System]####
> [root@powerpc sensor]# uname -a
> Linux powerpc.infosec.co.kr 2.4.10-12a #1 Tue Oct 9 04:29:39 EDT 2001
> ppc
> unknown [root@powerpc sensor]# rpm -q gcc
> gcc-2.95.4-4h
> [root@powerpc sensor]# rpm -q glibc
> glibc-2.2.4-19k
>
> pthread_cond_timedwait (cond=0x100219d8, mutex=0x7ffff9e8,
> abstime=0x7ffff9d0) at condvar.c:234
> 234 condvar.c: No such file or directory.
> Current language: auto; currently c
> (gdb) step
> pthread_cond_timedwait_relative (cond=0x1, mutex=0xfeda908,
> abstime=0x300256bc) at internals.h:384
> 384 internals.h: No such file or directory.
>
> ####[My Pentium System]####
> [root@Linux2 sensor]# uname -a
> Linux Linux2 2.2.17-8wl2 #1 Sun Jan 14 22:01:31 KST 2001 i686 unknown
> [root@Linux2 sensor]# rpm -q gcc
> gcc-2.96-69
> [root@Linux2 sensor]# rpm -q glibc
> glibc-2.2-9
>
> Breakpoint 2, WaitForSingleEvent (tEvent=@0x80580e0, ms=5000) at
> test.cc:92 92 retcode=pthread_cond_timedwait(&tEvent,
> &tMut,
> &timeout); (gdb) step
> pthread_cond_timedwait (cond=0x80580e0, mutex=0xbffffa10,
> abstime=0xbffffa38) at condvar.c:234
> 234 condvar.c: No such file or directory.
> Current language: auto; currently c
> (gdb) step
> pthread_cond_timedwait_relative (cond=0x80580e0, mutex=0xbffffa10,
> abstime=0xbffffa38) at condvar.c:140
> 140 in condvar.c
>
> ####[samples of "condvar.c" source]####
> static int pthread_cond_timedwait_relative(pthread_cond_t *cond,
> pthread_mutex_t *mutex, const struct timespec * abstime); int
> pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex,
> const struct timespec * abstime) {
> /* Indirect call through pointer! */
> return pthread_cond_timedwait_relative(cond, mutex, abstime);
> }
>
---- Kevin B. Hendricks Associate Professor of Operations and Information Technology Richard Ivey School of Business, University of Western Ontario London Ontario, CANADA N6A 3K7 khendricks@ivey.uwo.ca
This archive was generated by hypermail 2a24 : Wed Feb 06 2002 - 07:30:58 MST