phtread_create while pthread_cond_timedwait in gdb
arkadius....@googlemail.com
I experience a strange behavior while using gdb to test my software.
As long as I dont run it with gdb it works fine. My program is
simple.
Short description:
My main method does create a thread A and waits at
pthread_cond_timedwait (timeout is 10 seconds).
Thread A is performing a short sleep of 1 second and creates a thread
B.
Thread B does a simple printf.
It seems that everytime I do create a thread 'pthread_cond_timedwait'
return with ETIMEDOUT instantly. I have already tried this with
semaphores and the function sem_timedwait() with the same result.
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
static void *func1(void*);
static void *func2(void*);
static pthread_cond_t s_cond = PTHREAD_COND_INITIALIZER;
static pthread_mutex_t s_mutex = PTHREAD_MUTEX_INITIALIZER;
static pthread_t s_thread1;
static pthread_t s_thread2;
int main(int argc, char **argv)
{
int rc = 0;
struct timespec curts = { 0 }; /* transformed timeout
value */
/* create thread */
if (pthread_create(&s_thread1, NULL, func1, NULL))
{
printf("Unable to create timer thread\n");
return 0;
}
if (clock_gettime(CLOCK_REALTIME, &curts) == -1)
{
printf("Could not read realtime timer \n");
return 0;
}
/* Add 10 seconds to current time*/
curts.tv_sec += 10;
if(pthread_mutex_lock(&s_mutex))
{
printf("Could not lock mutex \n");
return 0;
}
printf("THREAD 0: pthread_cond_timedwait\n");
rc = pthread_cond_timedwait(&s_cond, &s_mutex, &curts);
if (rc == ETIMEDOUT)
{
printf("THREAD 0: Timer expired \n");
}
if(pthread_mutex_unlock(&s_mutex))
{
printf("Could not unlock mutex \n");
return 0;
}
return 1;
}
/
*----------------------------------------------------------------------------
*/
static void *func1(void *args)
{
/* warte 1 sekunde */
printf("THREAD 1: usleep(1000000)\n");
usleep(1000000);
/* create thread */
if (pthread_create(&s_thread2, NULL, func2, NULL))
{
printf("Unable to create timer thread\n");
return NULL;
}
return NULL;
}
/
*----------------------------------------------------------------------------
*/
static void *func2(void *args)
{
printf("THREAD 2: printf\n");
return NULL;
}
When I run this program without gdb I get the following (as expected):
THREAD 0: pthread_cond_timedwait
THREAD 1: usleep(1000000)
THREAD 2: printf
/* waiting 9 seconds */
THREAD 0: Timer expired
When I run this program WITH gdb I get following:
[New Thread -1210066256 (LWP 13250)]
[New Thread -1210070112 (LWP 13253)]
THREAD 0: pthread_cond_timedwait
THREAD 1: usleep(1000000)
[New Thread -1218462816 (LWP 13254)]
[Thread -1210070112 (LWP 13253) exited]
THREAD 2: printf
[Thread -1218462816 (LWP 13254) exited]
/* doesnt wait single second */
THREAD 0: Waiting for timer timeout failed
Can anyone tell me why this only occurs when I start my program with
gdb?
thx in advance!
ma...@pulsesoft.com
> Hi,
>
> I experience a strange behavior while using gdb to test my software.
> As long as I dont run it with gdb it works fine. My program is
> simple.
>
> Short description:
> My main method does create a thread A and waits at
> pthread_cond_timedwait (timeout is 10 seconds).
> Thread A is performing a short sleep of 1 second and creates a thread
> B.
> Thread B does a simple printf.
>
> It seems that everytime I do create a thread 'pthread_cond_timedwait'
> return with ETIMEDOUT instantly. I have already tried this with
> semaphores and the function sem_timedwait() with the same result.
>
>
[..snip..]
>
> When I run this program without gdb I get the following (as expected):
>
> THREAD 0: pthread_cond_timedwait
> THREAD 1: usleep(1000000)
> THREAD 2: printf
> /* waiting 9 seconds */
> THREAD 0: Timer expired
>
> When I run this program WITH gdb I get following:
>
> [New Thread -1210066256 (LWP 13250)]
> [New Thread -1210070112 (LWP 13253)]
> THREAD 0: pthread_cond_timedwait
> THREAD 1: usleep(1000000)
> [New Thread -1218462816 (LWP 13254)]
> [Thread -1210070112 (LWP 13253) exited]
> THREAD 2: printf
> [Thread -1218462816 (LWP 13254) exited]
> /* doesnt wait single second */
> THREAD 0: Waiting for timer timeout failed
The above code doesn't feature string "THREAD 0: Waiting for timer
timeout failed". It would be better if you'd post the version of code
that does.
That said i'm getting even weirder results here,
pthread_cond_timedwait never returns at all.. Interesting.
> Can anyone tell me why this only occurs when I start my program with
> gdb?
There are many things that are done differently when the application is
running under the gdb.
>
> thx in advance!
P.S. Btw. usleep has a tendency of returning EINTR under gdb. And in
general it's safer to use looping nanosleep if one needs to sleep
for exact amount of time.
--
mailto:av1...@comtv.ru
arkadius....@googlemail.com
right output:
When I run this program without gdb I get the following (as
expected):
THREAD 0: pthread_cond_timedwait
THREAD 1: usleep(1000000)
THREAD 2: printf
/* waiting 9 seconds */
THREAD 0: Timer expired
When I run this program WITH gdb I get following:
[New Thread -1210066256 (LWP 13250)]
[New Thread -1210070112 (LWP 13253)]
THREAD 0: pthread_cond_timedwait
THREAD 1: usleep(1000000)
[New Thread -1218462816 (LWP 13254)]
[Thread -1210070112 (LWP 13253) exited]
THREAD 2: printf
[Thread -1218462816 (LWP 13254) exited]
/* doesnt wait single second */
THREAD 0: Timer expired
> That said i'm getting even weirder results here,
> pthread_cond_timedwait never returns at all.. Interesting.
Does it occur with and/or without gdb?
Could you try the following code. It uses semaphores instead of
condition variables.
Compiled with:
gcc -Wall -Werror -lpthread -lrt -o test test.c
#include <errno.h>
#include <pthread.h>
#include <semaphore.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
static void *func1(void*);
static void *func2(void*);
static sem_t s_sem;
static pthread_t s_thread1;
static pthread_t s_thread2;
int main(int argc, char **argv)
{
struct timespec curts = { 0 }; /* transformed timeout
value */
/* create thread */
if (pthread_create(&s_thread1, NULL, func1, NULL))
{
printf("Unable to create timer thread\n");
return 0;
}
if (clock_gettime(CLOCK_REALTIME, &curts) == -1)
{
printf("Could not read realtime timer \n");
return 0;
}
/* Wait 10 seconds */
curts.tv_sec += 10;
printf("THREAD 0: sem_timedwait(10sek)\n");
if (sem_timedwait(&s_sem, &curts))
{
if (errno == ETIMEDOUT)
{
printf("THREAD 0: Timer expired \n");
}
}
return 1;
}
/
*----------------------------------------------------------------------------
*/
static void *func1(void *args)
{
/* warte 1 sekunde */
printf("THREAD 1: usleep(1000000)\n");
usleep(1000000);
/* create thread */
if (pthread_create(&s_thread2, NULL, func2, NULL))
{
printf("Unable to create timer thread\n");
return NULL;
}
return NULL;
}
/
*----------------------------------------------------------------------------
*/
static void *func2(void *args)
{
printf("THREAD 2: printf\n");
return NULL;
}
Thanks
On 25 Jun., 19:42, m...@pulsesoft.com wrote:
> mailto:av1...@comtv.ru- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
ma...@pulsesoft.com
> Thanks for the quick answer and sorry for the mistake. This is the
> right output:
>
> When I run this program without gdb I get the following (as
> expected):
>
> THREAD 0: pthread_cond_timedwait
> THREAD 1: usleep(1000000)
> THREAD 2: printf
> /* waiting 9 seconds */
> THREAD 0: Timer expired
>
>
> When I run this program WITH gdb I get following:
>
> [New Thread -1210066256 (LWP 13250)]
> [New Thread -1210070112 (LWP 13253)]
> THREAD 0: pthread_cond_timedwait
> THREAD 1: usleep(1000000)
> [New Thread -1218462816 (LWP 13254)]
> [Thread -1210070112 (LWP 13253) exited]
> THREAD 2: printf
> [Thread -1218462816 (LWP 13254) exited]
> /* doesnt wait single second */
> THREAD 0: Timer expired
>
>> That said i'm getting even weirder results here,
>> pthread_cond_timedwait never returns at all.. Interesting.
>
> Does it occur with and/or without gdb?
With gdb.
> Could you try the following code. It uses semaphores instead of
> condition variables.
> Compiled with:
> gcc -Wall -Werror -lpthread -lrt -o test test.c
>
[..snip..]
With this one i get results similar to yours, i.e. sem_timedwait
returns with an error, errno is set to ETIMEDOUT, semaphore value
is zero, in other words the sem_timedwait is wrong.
[..snip..]
P.S. Please do not top post.
--
mailto:av1...@comtv.ru
arkadius....@googlemail.com
Thank you!
I could not find any information about these "bugs".
Didn't nobody came along this until now?
Are there any fixes for this?
ma...@pulsesoft.com
[..snip..]
>
> Thank you!
>
> I could not find any information about these "bugs".
> Didn't nobody came along this until now?
> Are there any fixes for this?
Apparently not, and according to an informed source the bug can
be anywhere - kernel, glibc, gdb. Most likely ptrace related.
I'd guess that the best course of action is to alert the GDB
developers at: http://sourceware.org/gdb/mailing-lists/
Please, if you will find the answer why this happens, do share.
P.S. I'm also curious if this happens with LinuxThreads, my
system lacks some libraries so i can not easily test it
myself (via LD_ASSUME_KERNEL for instance)
--
mailto:av1...@comtv.ru
David Schwartz
> Thank you!
>
> I could not find any information about these "bugs".
> Didn't nobody came along this until now?
> Are there any fixes for this?
I'm sorry, what bug? You are seeing two different behaviors, one with
gdb and one without. But both behaviors are equally reasonable, and
the code doesn't do anything to force one behavior over the other.
This is typical with multi-threaded code. Slight changes in the system
or environment can result in different behavior.
If you care if 'pthread_cond_timedwait' returns early, call it in a
loop.
http://en.wikipedia.org/wiki/Spurious_wakeup
It is not a bug if the same program does two different things under
the same or different conditions unless one of those two things is
unreasonable.
DS
ma...@pulsesoft.com
> On Jun 26, 8:32 am, arkadius.nowakow...@googlemail.com wrote:
>
>> Thank you!
>>
>> I could not find any information about these "bugs".
>> Didn't nobody came along this until now?
>> Are there any fixes for this?
>
> I'm sorry, what bug? You are seeing two different behaviors, one with
> gdb and one without. But both behaviors are equally reasonable, and
> the code doesn't do anything to force one behavior over the other.
http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_wait.html
<quote>
The pthread_cond_timedwait() function shall be equivalent to
pthread_cond_wait(), except that an error is returned if the absolute
time specified by abstime passes (that is, system time equals or
exceeds abstime) before the condition cond is signaled or broadcasted,
or if the absolute time specified by abstime has already been passed
at the time of the call.
</quote>
On his system the time has NOT passed yet the call returns ETIMEDOUT,
this contradicts the above text.
On my system the call never returns at all.
>
> This is typical with multi-threaded code. Slight changes in the system
> or environment can result in different behavior.
>
> If you care if 'pthread_cond_timedwait' returns early, call it in a
> loop.
> http://en.wikipedia.org/wiki/Spurious_wakeup
Spurious wakeups have nothing to do with it.
> It is not a bug if the same program does two different things under
> the same or different conditions unless one of those two things is
> unreasonable.
>
> DS
--
mailto:av1...@comtv.ru
Rainer Weikusat
> David Schwartz <dav...@webmaster.com> writes:
>> On Jun 26, 8:32 am, arkadius.nowakow...@googlemail.com wrote:
>>> I could not find any information about these "bugs".
>>> Didn't nobody came along this until now?
>>> Are there any fixes for this?
>>
>> I'm sorry, what bug? You are seeing two different behaviors, one with
>> gdb and one without. But both behaviors are equally reasonable, and
>> the code doesn't do anything to force one behavior over the other.
>
> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_wait.html
>
> <quote>
> The pthread_cond_timedwait() function shall be equivalent to
> pthread_cond_wait(), except that an error is returned if the absolute
> time specified by abstime passes (that is, system time equals or
> exceeds abstime) before the condition cond is signaled or broadcasted,
> or if the absolute time specified by abstime has already been passed
> at the time of the call.
> </quote>
>
> On his system the time has NOT passed yet the call returns ETIMEDOUT,
> this contradicts the above text.
That's an assumption. But neither the value of the 'curts' variable at
the time of the pthread_cond_timedwait call is known nor is 'time of
day' known.
> On my system the call never returns at all.
It works as one would assume here, gdb notwithstanding. How is clock
synchronisation done one the affected systems (if it is done)?
ma...@pulsesoft.com
> ma...@pulsesoft.com writes:
>> David Schwartz <dav...@webmaster.com> writes:
>>> On Jun 26, 8:32 am, arkadius.nowakow...@googlemail.com wrote:
>>>> I could not find any information about these "bugs".
>>>> Didn't nobody came along this until now?
>>>> Are there any fixes for this?
>>>
>>> I'm sorry, what bug? You are seeing two different behaviors, one with
>>> gdb and one without. But both behaviors are equally reasonable, and
>>> the code doesn't do anything to force one behavior over the other.
>>
>> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_wait.html
>>
>> <quote>
>> The pthread_cond_timedwait() function shall be equivalent to
>> pthread_cond_wait(), except that an error is returned if the absolute
>> time specified by abstime passes (that is, system time equals or
>> exceeds abstime) before the condition cond is signaled or broadcasted,
>> or if the absolute time specified by abstime has already been passed
>> at the time of the call.
>> </quote>
>>
>> On his system the time has NOT passed yet the call returns ETIMEDOUT,
>> this contradicts the above text.
>
> That's an assumption. But neither the value of the 'curts' variable at
> the time of the pthread_cond_timedwait call is known nor is 'time of
> day' known.
Yes you are correct, but humans have builtin clock with high enough
resolution to tell between instant and 10 seconds delayed action,
and i assume OP based his assumptions on this internal clock.
>> On my system the call never returns at all.
>
> It works as one would assume here, gdb notwithstanding. How is clock
> synchronisation done one the affected systems (if it is done)?
I'm not sure what you are asking. Since i can not speak for the OP i'll
summarize what happens here:
~$ uname -a
Linux linmac 2.6.23-exp #1 Thu Oct 11 07:23:51 MSD 2007 ppc GNU/Linux
~$ /lib/libc-2.5.so | head -2
GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
~$ gdb --version | head -1
GNU gdb 6.8
pthread_cond_timedwait version (with REALTIME and MONOTONIC clocks)
Without GDB - ETIMEDOUT after 10 seconds
With GDB - Never returns
sem_timedwait version
Without GDB - ETIMEDOUT after 10 seconds
With GDB - ETIMEDOUT before 10 seconds elapsed
Later i will probably try it on a few X86 boxes.
--
mailto:av1...@comtv.ru
Rainer Weikusat
pthread_cond_timedwait does not wait until some amount of time has
passed, but until a specific time and date have been reached (or
passed).
David Schwartz
> David Schwartz <dav...@webmaster.com> writes:
> > On Jun 26, 8:32 am, arkadius.nowakow...@googlemail.com wrote:
> <quote>
> The pthread_cond_timedwait() function shall be equivalent to
> pthread_cond_wait(), except that an error is returned if the absolute
> time specified by abstime passes (that is, system time equals or
> exceeds abstime) before the condition cond is signaled or broadcasted,
> or if the absolute time specified by abstime has already been passed
> at the time of the call.
> </quote>
>
> On his system the time has NOT passed yet the call returns ETIMEDOUT,
> this contradicts the above text.
On Jun 27, 1:37 am, m...@pulsesoft.com wrote:
> On his system the time has NOT passed yet the call returns ETIMEDOUT,
> this contradicts the above text.
That's not what he said. His code shows:
rc = pthread_cond_timedwait(&s_cond, &s_mutex, &curts);
if (rc == ETIMEDOUT)
{
printf("THREAD 0: Timer expired \n");
}
And he never claimed the message "THREAD 0: Timer expired" was
printed.
He later posted some other code, that does not call
pthread_cond_timedwait, and claimed it produced that message. At no
time did he claim pthread_cond_timedwait returned ETIMEDOUT.
If semtimedwait is returned ETIMEDOUT before the specified absolute
time has passed, that is a bug, but it has nothing to do with
pthread_create, pthread_cond_timedwait, your standard excerpt, or any
of those things.
On modern (NPTL) Linux systems, sem_timedwait becomes a futex wait,
returning ETIMEDOUT if that's what the kernel returns from sys_futex.
Looking at the logic in futex_wait, it looks to me like it could
return ETIMEDOUT if the timer got cancelled for some reason other than
it expiring, such as the task being interrupted.
That code is very hard to read, at least it is for me.
DS
ma...@pulsesoft.com
I'm well aware of that, OPs code set the time to 10 seconds in the
future using realtime clock, mine does so with either realtime or
monotonic, and with monotonic pthread_cond_timedwait does wait for
10-eps seconds, where eps is time elapsed between calling
clock_gettime and pthread_cond_timedwait (i.e. few nanoseconds).
P.S. No need to be that nitpicky.
--
mailto:av1...@comtv.ru
ma...@pulsesoft.com
> On Jun 27, 1:37 am, m...@pulsesoft.com wrote:
>> David Schwartz <dav...@webmaster.com> writes:
>> > On Jun 26, 8:32 am, arkadius.nowakow...@googlemail.com wrote:
>
>> <quote>
>> The pthread_cond_timedwait() function shall be equivalent to
>> pthread_cond_wait(), except that an error is returned if the absolute
>> time specified by abstime passes (that is, system time equals or
>> exceeds abstime) before the condition cond is signaled or broadcasted,
>> or if the absolute time specified by abstime has already been passed
>> at the time of the call.
>> </quote>
>>
>> On his system the time has NOT passed yet the call returns ETIMEDOUT,
>> this contradicts the above text.
>
> On Jun 27, 1:37 am, m...@pulsesoft.com wrote:
>
>> On his system the time has NOT passed yet the call returns ETIMEDOUT,
>> this contradicts the above text.
>
> That's not what he said. His code shows:
>
> rc = pthread_cond_timedwait(&s_cond, &s_mutex, &curts);
> if (rc == ETIMEDOUT)
> {
> printf("THREAD 0: Timer expired \n");
> }
>
> And he never claimed the message "THREAD 0: Timer expired" was
> printed.
Right, he said that it prints "THREAD 0: Waiting for timer timeout
failed", the string that wasn't in the code he posted. So you are
right that spurious wakeup might have happened in this case.
However there are no spurious wakeups for sem_timedwait and there's
no explanation (yet) as to why under gdb pthread version blocks
indefinitely on my system.
> He later posted some other code, that does not call
> pthread_cond_timedwait, and claimed it produced that message. At no
> time did he claim pthread_cond_timedwait returned ETIMEDOUT.
>
> If semtimedwait is returned ETIMEDOUT before the specified absolute
> time has passed, that is a bug, but it has nothing to do with
> pthread_create, pthread_cond_timedwait, your standard excerpt, or any
> of those things.
It does for my case when the code never returns from
pthread_cond_timedwait. And i'm not sure what pthread_create has to do
with any of this.
> On modern (NPTL) Linux systems, sem_timedwait becomes a futex wait,
> returning ETIMEDOUT if that's what the kernel returns from sys_futex.
> Looking at the logic in futex_wait, it looks to me like it could
> return ETIMEDOUT if the timer got cancelled for some reason other than
> it expiring, such as the task being interrupted.
>
> That code is very hard to read, at least it is for me.
>
> DS
--
mailto:av1...@comtv.ru
Rainer Weikusat
But you still haven't understood (and likely never will) that starting
to wait until the 'date' 'random time in the past + 10 seconds' has
been reached at the date 'random time after the first' does not equal
'wait for ten seconds'.
Which happens to be about the only useful remark one can make
regarding the posted code, given that this isn't a generally
reproducible phenomenon.
ma...@pulsesoft.com
[..snip..]
> But you still haven't understood (and likely never will) that starting
> to wait until the 'date' 'random time in the past + 10 seconds' has
> been reached at the date 'random time after the first' does not equal
> 'wait for ten seconds'.
Probably i never will. What i do understand is that the call to
clock_gettime (after pthread_cond/sem_timedwait returned ETIMEDOUT)
set's timespec to the value that is well behind the one supplied
to pthread_cond/sem_timedwait.
> Which happens to be about the only useful remark one can make
> regarding the posted code, given that this isn't a generally
> reproducible phenomenon.
--
mailto:av1...@comtv.ru
ma...@pulsesoft.com
Drop pthread_cond out of that, it has legitimate reasons to return
with zero status and i myself, so far, haven't seen it return
ETIMEDOUT. The problem with ETIMEDOUT + sem_timedwait and
pthread_cond_timedwait never returning stays for the time being.
--
mailto:av1...@comtv.ru
arkadius....@googlemail.com
> THREAD 0: Waiting for timer timeout failed
It was a copy-and-paste mistake from a previous code version. The
correct printout is:
> THREAD 0: Timer expired
This can also be found in my code.
The crux of this code example is that inside GDB the creation of a
thread
(see the GDB message: [New Thread -1218462816 (LWP 13254)] ) leads
immediatelly,
without the expected 10 sedond delay, to the returning of
sem_timedwait, which sets errno to ETIMEDOUT.
Using condition variables the call pthread_cond_timedwait also returns
before the expected 10 seconds have
elapsed with the return code ETIMEDOUT.
Dirty workaround for this strange behaviour:
After sem_timedwait returns with an error and errno is set to
ETIMEDOUT, I call clock_gettime(CLOCK_REALTIME, &curts)
to check if the estimated time has elapsed. If not, I call
sem_timedwait with the firstly calculated abs-time again.
Unfortunately that won't fix your problem where the
pthread_cond_timedwait does not return at all.