14

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);
}
Improve this question
8
  • Are you re-creating the threads inside the while(1) loop? Commented Feb 17, 2014 at 9:34
  • @barak manos Yes I am re-creating the threads in the while(1) loop. Commented Feb 17, 2014 at 9: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 Commented Feb 17, 2014 at 9: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. Commented Feb 17, 2014 at 9:48
  • 1
    Can you post your entire code, so that we can recreate and debug the program. Commented Oct 7, 2014 at 22:25

3 Answers 3

Reset to default
7
+50

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Just a note, POSIX 2001 deprecated bzero and POSIX 2008 removed it from the standard. Should be using memset.
@JohnH - thanks - didn't know that. I've switched it to memset.
@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 :)
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.

Improve this answer

6 Comments

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 if you have not use pthread_mutexattr, the default is fast mutex.
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)?
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 that's why I ask "Is it possible that there's pthread_mutex_t deeply inside the thread running code ?? " to clarify the problem
|
0

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.