Threading issues

Question

getvariana: tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.

Hi all,

I am trying to re-run a program which creates 5 threads and after pthread_join(), I do a return, based on which, I re-run the entire program i.e., it is in while(1) loop.

When I run the program for the second time, I get an error as you can see above. I am unable to trace its origin. Can anyone please explain why is this error caused ?

FYI: I dont use any mutex locks or semaphore. I wait for the threads to join after which I re-run the entire program. Does it have anything to do with race conditions ? I am assuming, that when I wait for all the 5 threads to join, only then I can move out of the pthread

main
{
    while(1)
    {
         test();
    }
}//main

test()
{
    for( i = 0; i < 5; i++ )
        pthread_create( &th[i], NULL, tfunc, &some_struct);

    for( i = 0; i < 5, i++ )
        pthread_join( th[i], NULL);
}

void * tfunc( void * ptr )
{
    // waiting for a callback function to set a global counter to a value
    // sleep until then
    if( g_count == value_needed )
        pthread_exit(NULL);
}

@barak manos Yes I am re-creating the threads in the while(1) loop. — Adit Ya, Feb 17 '14 at 09:43
@ed heal: I run this application on an ARM based target system which is not supporting gdb server ( dont know why ). So, atleast if I can know why this error is being caused, I could debug the issue — Adit Ya, Feb 17 '14 at 09:45
Well, typically, you should not recreate the threads inside the loop. You need to create them **before** you enter the loop (each one with its given priority), start them at the beginning of the loop and join them at the end of the loop. If you provide your code, then I might be able to help you understand the problem. — barak manos, Feb 17 '14 at 09:48
I have added the pseudo code of the functionality I needed. Hope it helps @barak manos — Adit Ya, Feb 17 '14 at 09:56
Yes I do have checks. And it doesnt fail. For one iteration of the while loop, I get the result but when the iteration happens the second time, I always get this error. — Adit Ya, Feb 23 '14 at 10:05
Can you post your entire code, so that we can recreate and debug the program. — Rizier123, Oct 07 '14 at 22:25

abligh · Accepted Answer · 2014-10-13T16:13:29.490

Here is your program cleaned up. It runs without the above assertion:

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <string.h>

static pthread_t th[5];

void *
tfunc (void *ptr)
{
  sleep (5);                    /* remove this to test it without the sleep */
  pthread_exit (NULL);
}

void
test ()
{
  int i;
  memset (th, 0, 5 * sizeof (pthread_t));

  for (i = 0; i < 5; i++)
    {
      if (pthread_create (&th[i], NULL, tfunc, NULL) < 0)
        perror ("pthread_create");
    }

  for (i = 0; i < 5; i++)
    {
      if (pthread_join (th[i], NULL) < 0)
        perror ("pthread_join");
    }
}

int
main (int argc, char **argv)
{
  while (1)
    {
      test ();
    }
  exit (0);
}

Here's what I noticed when cleaning it up:

for( i = 0; i < 5, i++ ) comma not semicolon means loop may not have been working
in test(), th was not zeroed meaning any failed pthread_create was using an old thread reference.
In tfunc, you did a pthread_join if ( g_count == value_needed ), but then you exited anyway, i.e. you were always immediately doing the pthread_join or the equivalent. Note I also tested the version below without the sleep(), so exiting immediately now works.
various other orthographic issues.
no error handling

As there were a few compilation problems, I suspect that you may not have compiled the code you pasted above, but something more complicated. And I suspect it's part of that that's causing the issue.

If you post a minimal example of compilable code that actually causes the issue, I might be able to help you further.

Just a note, POSIX 2001 deprecated bzero and POSIX 2008 removed it from the standard. Should be using memset. — JohnH, Oct 13 '14 at 15:56
@JohnH - thanks - didn't know that. I've switched it to `memset`. — abligh, Oct 13 '14 at 16:14
@abligh .. Sorry for the delayed response. I have said in one of my comments above that its a pseudo code that I've pasted above. The , was a typo error. While your answer is intact and it did really give me a better understanding, turns out that there was an issue in other compilation unit, that uses threads, that has caused this issue. Thanks for the help ! And for an extent helped me find an answer; gave me clarity that my code was not creating the problem. So marked it as answer :) — Adit Ya, Jun 01 '16 at 08:02

score 6 · Answer 2 · answered Oct 11 '14 at 06:02

6

tpp.c:63: __pthread_tpp_change_priority: Assertion is a known problem and solved:
https://sourceware.org/ml/libc-help/2008-05/msg00071.html
in brief, the problem is caused by repeated locking of a fast mutex, and solved by using a recursive mutex, and the default pthread_mutex_t is not recursive. Is it possible that there's pthread_mutex_t deeply inside the thread running code ??
BTW, to make the mutex recursive, plz set the mutex attribute with attribute PTHREAD_MUTEX_RECURSIVE_NP.

answered Oct 11 '14 at 06:02

Peixu Zhu

2,111
1
15
13

The thread you linked to seems to say if there is a `pthread_mutexattr` in use, you need to use `pthread_mutexattr_init` (obviously); I don't see it saying that you should use a recursive mutex rather than a fast mutex to avoid the error. OP is not using `pthread_mutexattr` at all per the original code sample anyway. – abligh Oct 12 '14 at 07:26
@abligh if you have not use `pthread_mutexattr`, the default is `fast mutex`. – Peixu Zhu Oct 12 '14 at 09:14
Sure, but the poster in the thread to which you referred was using an initialised value. What's evidence that fast mutex's are broken (rather than using an uninitialized `pthread_mutexattr` which is obviously undefined behaviour and thus broken)? – abligh Oct 12 '14 at 18:15
@abligh in the post "This seems ok, it works most of the time, however sometimes an error shows up from deep within the pthread library: tpp.c:63: __pthread_tpp_change_priority: Assertion ..." assertion failure will cause program aborted/broken. – Peixu Zhu Oct 13 '14 at 01:29
2

Sure, but OP says _"FYI: I dont use any mutex locks or semaphore"_. If he's not using any mutex locks or semaphores, how can the problem be the mutex type selected? – abligh Oct 13 '14 at 07:21
2

@abligh that's why I ask "Is it possible that there's pthread_mutex_t deeply inside the thread running code ?? " to clarify the problem – Peixu Zhu Oct 13 '14 at 13:04

score 0 · Answer 3 · answered Feb 22 '19 at 04:59

In my case, I have used the QCoreApplication and boost::thread and the error occurs when the program exits.I interrupted the whole boost::thread when the program received exit signal nevertheless it was not graceful enough.Therefore, I solved it by calling app.quit() actively in slot function.Maybe check the way of exit could help.

Threading issues

3 Answers3