This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug threads/20291] New: Set scheduler-locking on doesn't work correctly with pthread_create


https://sourceware.org/bugzilla/show_bug.cgi?id=20291

            Bug ID: 20291
           Summary: Set scheduler-locking on doesn't work correctly with
                    pthread_create
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: martin.galvan at tallertechnologies dot com
                CC: palves at redhat dot com
  Target Milestone: ---

Created attachment 9350
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9350&action=edit
Example code that triggers the bug

In the following code:

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

void *thread_func(void *unused)
{
    puts("Child thread.");

    return NULL;
}

int main()
{
    pthread_t thread;

    if (pthread_create(&thread, NULL, thread_func, NULL) == 0) /* Stop here */
    {
        puts("Child thread created.");

        if (pthread_join(thread, NULL) == 0)
        {
            puts("Child thread joined.");
        }
    }

    return 0;
}

If I stop at the "Stop here" line (before calling pthread_create), issue a "set
scheduler-locking on", and then a "next", the child thread will still run (and
finish) before "next" finishes:

Temporary breakpoint 1, main () at example.c:15
15          if (pthread_create(&thread, NULL, thread_func, NULL) == 0) /* Stop
here */
(gdb) set scheduler-locking on
(gdb) next
[New Thread 0x7ffff77f6700 (LWP 13087)]
Child thread.
[Thread 0x7ffff77f6700 (LWP 13087) exited]
17              puts("Child thread created.");
(gdb)

This doesn't happen with gdb 7.7.1, so I'm guessing some later commit
introduced the bug. The schedlock tests run fine for the current git master, so
I guess this wasn't covered by the testsuite.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]