bug-commoncpp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

quick question (?bug report?)


From: Kirill Smelkov
Subject: quick question (?bug report?)
Date: Tue, 15 Jan 2002 15:29:26 +0300

Hello. Using Common C++(1.9.4) library on Linux/glibc(2.2.2) system we
discovered an unexpected library behaviour.
I don't know wheather this behaviour is due to my bugs or Common C++ or pthread
libraries limitations/bugs.

Here follows the problem description.

Suppose we have an object derived from ost::Thread. Let it name be A

and suppose somewhere in code we have the following fragment:

    AP = new A;
    AP->Start();
    
The problem is that AP->Start just never returns.


In our case this type of behaviour appeared when thread creation code was in
the library and the program starts just with forking
so main looks like

main()
{
    if (fork()) exit(0);

    [continue daemon stuff including thread creation etc]
}

Our library was linked with -lpthread and the program link doesnt contain
-lpthread:
(ldd ./program output)
        libtwork.so => /terminus/lib/libtwork.so (0x4002d000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
(0x40060000)
        libm.so.6 => /lib/libm.so.6 (0x400a3000)
        libc.so.6 => /lib/libc.so.6 (0x400c6000)
        libccgnu-1.9.so.3 => /usr/local/lib/libccgnu-1.9.so.3 (0x401f0000)
        libdl.so.2 => /lib/libdl.so.2 (0x40222000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40226000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

but if main program link includes -lpthread everything is just ok (AP->Start()
doesnt look up) and
ldd output in this case foolows:
        libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000)
        libtwork.so => /terminus/lib/libtwork.so (0x40044000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
(0x40077000)
        libm.so.6 => /lib/libm.so.6 (0x400ba000)
        libc.so.6 => /lib/libc.so.6 (0x400dd000)
        libccgnu-1.9.so.3 => /usr/local/lib/libccgnu-1.9.so.3 (0x40207000)
        libdl.so.2 => /lib/libdl.so.2 (0x40239000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


During debuging we discovered that Common C++ uses functions from libpthread
mainly with 2_0 version i.e.
(bt output)
#0  __pthread_create_2_0 (thread=0x805729c, attr=0x80572a0,
    start_routine=0x4021bba8 <execHandler>, arg=0x8057298) at pthread.c:643
#1  0x4021ba8d in ost::Thread::Start (this=0x8057298, start=0x0) at
thread.cpp:390
#2  0x40060317 in Terminus::SLogFile::SLogFile (this=0x8054700,
address@hidden,
    logType=TOFILE, logLevel=LEMERGENCY) at LogFile/SLogFile.cpp:46
#3  0x0804d0f0 in LogFile (Level=LNOISE) at SCronLogFile.cpp:27
#4  0x0804bd76 in main (argc=1, argv=0xbffff5c4) at CronModule.cpp:109
#5  0x400f8e5e in __libc_start_main (main=0x804bc64 <main>, argc=1,
ubp_av=0xbffff5c4,
    init=0x804b55c <_init>, fini=0x8050808 <_fini>, rtld_fini=0x4000d3c4
<_dl_fini>,
    stack_end=0xbffff5bc) at ../sysdeps/generic/libc-start.c:129

but if we look at nm -C /usr/local/lib/libccgnu.so  | grep pthread
         U pthread_attr_destroy@@GLIBC_2.0
         U pthread_attr_init@@GLIBC_2.1             // <-- LOOK !!!
         U pthread_attr_setdetachstate@@GLIBC_2.0
         U pthread_attr_setinheritsched@@GLIBC_2.0
         U pthread_attr_setschedparam@@GLIBC_2.0
         U pthread_attr_setschedpolicy@@GLIBC_2.0
         U pthread_attr_setstacksize
         U pthread_cancel
         U pthread_cond_broadcast@@GLIBC_2.0
         U pthread_cond_destroy@@GLIBC_2.0
         U pthread_cond_init@@GLIBC_2.0
         U pthread_cond_signal@@GLIBC_2.0
         U pthread_cond_timedwait
         U pthread_cond_wait@@GLIBC_2.0
         U pthread_create
         U pthread_detach
         U pthread_exit@@GLIBC_2.0
         U pthread_getspecific
         U pthread_join
         U pthread_key_create
         U pthread_key_delete
         U pthread_kill
         U pthread_mutex_destroy@@GLIBC_2.0
         U pthread_mutex_init@@GLIBC_2.0
         U pthread_mutex_lock@@GLIBC_2.0
         U pthread_mutex_trylock
         U pthread_mutex_unlock@@GLIBC_2.0
         U pthread_mutexattr_init
         U pthread_mutexattr_settype
         w pthread_once
         U pthread_rwlock_destroy
         U pthread_rwlock_init
         U pthread_rwlock_rdlock
         U pthread_rwlock_tryrdlock
         U pthread_rwlock_trywrlock
         U pthread_rwlock_unlock
         U pthread_rwlock_wrlock
         U pthread_rwlockattr_init
         U pthread_self@@GLIBC_2.0
         U pthread_setcancelstate@@GLIBC_2.0
         U pthread_setcanceltype@@GLIBC_2.0
         U pthread_setspecific
         U pthread_sigmask
         U pthread_testcancel
         U pthread_yield

we see that pthread_attr_init uses 2_1 version.

to my mind attr_init 2_0 & 2_1 are different in treating size of pthread_attr_t
and it would be an error
to call thread_create_2_0 after attr_init_2_1.

I would be glad to hear from you.

Regards, Kirill Smelkov.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]