RE: Do you support pthread_cond_timedwait() function?


Subject: RE: Do you support pthread_cond_timedwait() function?
From: ??? (shyang@infosec.co.kr)
Date: Tue Feb 05 2002 - 19:42:10 MST


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);
}

[test.cc]
//#pragma pack(1)

#include <ctype.h> //isalpha
#include <sys/time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <net/ethernet.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <netinet/udp.h>
#include <netinet/ip_icmp.h>
#include <pthread.h>

//Linux define
#define TRUE 1
#define FALSE 0
"test.cc" 101L, 2102C
#define TRUE 1
#define FALSE 0

//#define NULL ('\0')
//Linux typedef
typedef unsigned char BYTE;
typedef unsigned short int WORD;
typedef unsigned long DWORD;
typedef unsigned long * LPDWORD;
typedef char * LPSTR;
typedef const char * LPTSTR;
typedef LPTSTR LPCTSTR;
typedef WORD BOOL;
typedef DWORD HANDLE;
typedef HANDLE HKEY;

pthread_cond_t g_tEvent;

DWORD WaitForSingleEvent(pthread_cond_t &tEvent, DWORD ms);

void main(void)
{
        printf("Test Program\n");
        pthread_cond_init(&g_tEvent, NULL);
        while(1)
        {
                if(WaitForSingleEvent(g_tEvent, 5000)==EINTR)
                {
                        printf("[main] WaitForsingleEvent\n");
                }
                printf("[main] WaitForsingleEvent - Timeout(5s)\n");
        }
        pthread_cond_destroy(&g_tEvent);
}

DWORD WaitForSingleEvent(pthread_cond_t &tEvent, DWORD ms)
{
        int retcode=0;
        struct timeval now;
        struct timespec timeout;
        DWORD usec;

        pthread_mutex_t tMut;
        pthread_mutex_init(&tMut, NULL);

        gettimeofday(&now, NULL);

        usec=(now.tv_usec+ms*1000);
        timeout.tv_sec=now.tv_sec+(DWORD)(usec/1000000);
        timeout.tv_nsec=(usec%1000000)*1000;

        retcode=pthread_cond_timedwait(&tEvent, &tMut, &timeout);

        pthread_mutex_destroy(&tMut);

    if((retcode==ETIMEDOUT)||(retcode==EBUSY))
        {
                return retcode;
        }
        return EINTR;
}

-----Original Message-----
From: Kevin Hendricks [mailto:khendricks@ivey.uwo.ca]
Sent: Wednesday, February 06, 2002 1:19 AM
To: ¾ç½ÂÈ£
Cc: yellowdog-devel@lists.yellowdoglinux.com
Subject: Re: Do you support pthread_cond_timedwait() function?

Hi,

> We found some problems during the porting process of our product to
> Yellowdog linux.
> Our product is a program that uses 'Multi-Thread' and to correctly
> operate the 'Multi-Thread', we uses a program called 'pthread'.
> Product can correctly be operated under intel series system linux (wow
> linux 7.0).

A few things:

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

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?

Since you got a SIGBUS and not a SIGSEGV my guess you are trying to
access the wrong place in the structuree due to the pragma pack. I do
not think it is portable to run pragma pack(1) on a structure that
includes data types declared by glibc for mutexes and condvars.

Please try it without that compiler commands since it is not needed for
the test code to run.

Kevin

----
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 : Tue Feb 05 2002 - 20:04:29 MST