This is sources Bugzilla
Bugzilla Version 2.17.5
Bugzilla Bug 6868
  stack dirtied after pthread_create Last modified: 2008-09-05 01:29
     Query page      Enter new bug
Bug#: 6868   Hardware:   Reporter: Luca Bruno <lethalman88@gmail.com>
Host: Target: Build:
Product:     Add CC:
Component:   Version:   CC:
Remove selected CCs
Status: RESOLVED   Priority:  
Resolution: INVALID   Severity:  
Assigned To: Ulrich Drepper <drepper@redhat.com>   Target Milestone:  
Flags: Requestee:
  backport ()
  examined ()
  testsuite ()
Summary:
Keywords:

Attachment Description Type Created Actions
a.c testcase text/plain 2008-09-04 20:34 Edit None
a2.c illustration text/plain 2008-09-05 01:29 Edit None
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 6868 depends on: Show dependency tree
Show dependency graph
Bug 6868 blocks:

Additional Comments:


Leave as RESOLVED INVALID
Reopen bug
Mark bug as VERIFIED

View Bug Activity   |   Format For Printing


Description:   Last confirmed: 0000-00-00 00:00 Opened: 2008-09-04 20:32
Hello,
I've debian amd64 libc6 version 2.7-13. Two people on i386, debian and ubuntu,
with both libc6 2.7-10.
I'm attaching a testcase showing how after pthread_create the "i" variable gets
undefined values. If the "i" variable is declared outside the main function,
this doesn't happen.
Doesn't happen for me on amd64.
The other guy is going to open an entry on the debian BTS if this is not libc
related.

------- Additional Comment #1 From Luca Bruno 2008-09-04 20:34 -------
Created an attachment (id=2939)
testcase

------- Additional Comment #2 From Jakub Jelinek 2008-09-04 20:47 -------
Don't bother, the testcase is invalid.  The array variable may go out of scope
before threads have a chance to read that value, there is no synchronization in
between (like a barrier).

------- Additional Comment #3 From Luca Bruno 2008-09-04 20:55 -------
Let me understand bettere please.
The problem is not in the array variable. The problem is that the "i" variable
gets dirtied after pthread_create. It happens just after the first thread is
launched, I don't understand what chance you're talking about.
Could you exaplain why doesn't it happen on amd64?

------- Additional Comment #4 From Sean P Curry 2008-09-05 01:27 -------
Hello Luca,

First off, I believe you meant for the first argument to the pthread_create call
(on line 20) to be "&threads[i]", not "&threads[10]". &threads[10] is indexing
beyond the array of "pthread_t". This typo is why you said that "'i' gets
dirtied after the first pthread_create call". 

If you fix that problem and run your test case repeatedly, you will find that
sometimes the output is correct, with the correct 'i' values (0-9) being
printed, but sometimes invalid values are printed by the threads. You may think
this is caused by an undefined "i" value, but it is actually because the scope
of the "array[10]" is local to the main function. ie: when the main
function/thread ends, any variables with local scope will become undefined, and
cannot be depended upon. So, sometimes all of the 10 threads are completing
their printf calls while main's local variables are still valid, and sometimes not. 

Defining the "i" variable outside the main function does not fix the problem,
because the threads are attempting to print the values from the "array[10]"
variable, not from the "i" variable directly.

To see that this is a variable scope problem (and not a problem with
pthread_create), you could declare "array[10]" outside the main function (thus
giving the array a global scope), or you could create a barrier using
"pthread_join", so that the main thread does not exit until all threads have
completed (see attachment a2.c).

I hope this helps you to understand what Jakob is saying.

------- Additional Comment #5 From Sean P Curry 2008-09-05 01:29 -------
Created an attachment (id=2940)
illustration

attaching a2.c

     Query page      Enter new bug
Actions: New | Query | bug # | Reports | Requests   New Account | Log In