[1003.1(2013)/Issue7+TC1 0000863]: Explicitly disallow longjmp from pthread_once init_routine

[Austin Group Bug Tracker]

The following issue has been UPDATED.
======================================================================
http://austingroupbugs.net/view.php?id=863
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 863
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: Resolved
Name: Rich Felker
Organization: musl libc
User Reference:
Section: pthread_once
Page Number: 1684
Line Number: 54499
Interp Status: ---
Final Accepted Text: See
http://austingroupbugs.net/view.php?id=863#c2366.
Resolution: Reopened
Fixed in Version:
======================================================================
Date Submitted: 2014-08-05 22:09 UTC
Last Modified: 2014-09-04 15:08 UTC
======================================================================
Summary: Explicitly disallow longjmp from pthread_once
init_routine
======================================================================

Issue History
Date Modified Username Field Change
======================================================================
2014-08-05 22:09 dalias New Issue
2014-08-05 22:09 dalias Name => Rich Felker
2014-08-05 22:09 dalias Organization => musl libc
2014-08-05 22:09 dalias Section => pthread_once
2014-08-05 22:09 dalias Page Number => unknown
2014-08-05 22:09 dalias Line Number => unknown
2014-08-06 01:24 dalias Note Added: 0002333
2014-08-08 11:01 jilles Note Added: 0002339
2014-08-08 13:21 steffen Note Added: 0002341
2014-08-08 16:05 dalias Note Added: 0002342
2014-08-08 18:29 steffen Note Added: 0002344
2014-08-28 15:37 Don Cragun Note Added: 0002366
2014-08-28 16:14 Don Cragun Note Edited: 0002366
2014-08-28 16:16 Don Cragun Note Edited: 0002366
2014-08-28 16:17 Don Cragun Page Number unknown => 1684
2014-08-28 16:17 Don Cragun Line Number unknown => 54499
2014-08-28 16:17 Don Cragun Interp Status => ---
2014-08-28 16:17 Don Cragun Final Accepted Text => See
http://austingroupbugs.net/view.php?id=863#c2366.
2014-08-28 16:17 Don Cragun Status New => Resolved
2014-08-28 16:17 Don Cragun Resolution Open => Accepted As
Marked
2014-08-28 16:23 Don Cragun Note Edited: 0002366
2014-08-28 16:23 Don Cragun Tag Attached: tc2-2008
2014-08-28 16:41 dalias Note Added: 0002367
2014-08-28 17:13 mdempsky Note Added: 0002368
2014-08-28 17:55 dalias Note Added: 0002369
2014-08-28 23:27 mdempsky Note Added: 0002370
2014-09-04 15:08 nick Resolution Accepted As Marked =>
Reopened
======================================================================

[Austin Group Bug Tracker]

A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=863
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 863
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: Resolved
Name: Rich Felker
Organization: musl libc
User Reference:
Section: pthread_once
Page Number: 1684
Line Number: 54499
Interp Status: ---
Final Accepted Text: See
http://austingroupbugs.net/view.php?id=863#c2366.
Resolution: Reopened
Fixed in Version:
======================================================================
Date Submitted: 2014-08-05 22:09 UTC
Last Modified: 2014-09-04 15:36 UTC
======================================================================
Summary: Explicitly disallow longjmp from pthread_once
init_routine
======================================================================

----------------------------------------------------------------------
(0002371) Don Cragun (manager) - 2014-09-04 15:36
http://austingroupbugs.net/view.php?id=863#c2371
----------------------------------------------------------------------
Add new paragraph after P1684, L54487:
<blockquote>If init_routine() does not return to pthread_once() other than
by being cancelled, the results are undefined.</blockqoute>

Change "None" on P1684, L54499 in APPLICATION USAGE to:
<blockquote>If init_routine() recursively calls pthread_once() with the
same once_control, the recursive call will not call the specified
init_routine, and thus the specified init_routine() will not complete, and
thus the recursive call to pthread_once() will not return.</blockquote>

Issue History
Date Modified Username Field Change
======================================================================
2014-08-05 22:09 dalias New Issue
2014-08-05 22:09 dalias Name => Rich Felker
2014-08-05 22:09 dalias Organization => musl libc
2014-08-05 22:09 dalias Section => pthread_once
2014-08-05 22:09 dalias Page Number => unknown
2014-08-05 22:09 dalias Line Number => unknown
2014-08-06 01:24 dalias Note Added: 0002333
2014-08-08 11:01 jilles Note Added: 0002339
2014-08-08 13:21 steffen Note Added: 0002341
2014-08-08 16:05 dalias Note Added: 0002342
2014-08-08 18:29 steffen Note Added: 0002344
2014-08-28 15:37 Don Cragun Note Added: 0002366
2014-08-28 16:14 Don Cragun Note Edited: 0002366
2014-08-28 16:16 Don Cragun Note Edited: 0002366
2014-08-28 16:17 Don Cragun Page Number unknown => 1684
2014-08-28 16:17 Don Cragun Line Number unknown => 54499
2014-08-28 16:17 Don Cragun Interp Status => ---
2014-08-28 16:17 Don Cragun Final Accepted Text => See
http://austingroupbugs.net/view.php?id=863#c2366.
2014-08-28 16:17 Don Cragun Status New => Resolved
2014-08-28 16:17 Don Cragun Resolution Open => Accepted As
Marked
2014-08-28 16:23 Don Cragun Note Edited: 0002366
2014-08-28 16:23 Don Cragun Tag Attached: tc2-2008
2014-08-28 16:41 dalias Note Added: 0002367
2014-08-28 17:13 mdempsky Note Added: 0002368
2014-08-28 17:55 dalias Note Added: 0002369
2014-08-28 23:27 mdempsky Note Added: 0002370
2014-09-04 15:08 nick Resolution Accepted As Marked =>
Reopened
2014-09-04 15:36 Don Cragun Note Added: 0002371
======================================================================

[Joerg Schilling]

Post by Austin Group Bug Tracker
----------------------------------------------------------------------
(0002371) Don Cragun (manager) - 2014-09-04 15:36
http://austingroupbugs.net/view.php?id=863#c2371
----------------------------------------------------------------------
<blockquote>If init_routine() does not return to pthread_once() other than
by being cancelled, the results are undefined.</blockqoute>

If init_routine() called longjmp() before the cancellation happens, this will
still cause an undefined behavior as then the local storage from pthread_once()
that holds the cleanup handler is not valid at cancellation time.

Jörg

[Rich Felker]

Post by Joerg Schilling

Post by Austin Group Bug Tracker
----------------------------------------------------------------------
(0002371) Don Cragun (manager) - 2014-09-04 15:36
http://austingroupbugs.net/view.php?id=863#c2371
----------------------------------------------------------------------
<blockquote>If init_routine() does not return to pthread_once() other than
by being cancelled, the results are undefined.</blockqoute>

If init_routine() called longjmp() before the cancellation happens, this will
still cause an undefined behavior as then the local storage from pthread_once()
that holds the cleanup handler is not valid at cancellation time.

Indeed. I think the text should say something along the lines of:

"If the call to init_routine ends except via a return statement or
acting upon cancellation, the behavior is undefined."

This covers the case you're concerned about, since such use of longjmp
"terminates the call" in the language of the C standard.

It also covers another issue I mentioned that hasn't yet been
addressed: what happens with the init_routine calls pthread_exit. I
think morally calling pthread_exit should be identical to acting on
cancellation, but it's probably preferable just to leave the behavior
undefined.

Rich

[Rich Felker]

Post by Rich Felker

Post by Joerg Schilling

Post by Austin Group Bug Tracker
----------------------------------------------------------------------
(0002371) Don Cragun (manager) - 2014-09-04 15:36
http://austingroupbugs.net/view.php?id=863#c2371
----------------------------------------------------------------------
<blockquote>If init_routine() does not return to pthread_once() other than
by being cancelled, the results are undefined.</blockqoute>

If init_routine() called longjmp() before the cancellation happens, this will
still cause an undefined behavior as then the local storage from pthread_once()
that holds the cleanup handler is not valid at cancellation time.

"If the call to init_routine ends except via a return statement or
acting upon cancellation, the behavior is undefined."
This covers the case you're concerned about, since such use of longjmp
"terminates the call" in the language of the C standard.
It also covers another issue I mentioned that hasn't yet been
addressed: what happens with the init_routine calls pthread_exit. I
think morally calling pthread_exit should be identical to acting on
cancellation, but it's probably preferable just to leave the behavior
undefined.

However, it was pointed out to me that this could wrongly be
interpreted as saying that calling execve from init_routine results in
undefined behavior. While doing so doesn't seem to make a lot of
sense, there's certainly no reason for it to be forbidden.

What about just being explicit?

"If the call to init_routine is terminated by a call to longjmp,
_longjmp, or siglongjmp, the behavior is undefined."

Optionally pthread_exit could be added to that list.

Rich

[Joerg Schilling]

Post by Rich Felker
What about just being explicit?
"If the call to init_routine is terminated by a call to longjmp,
_longjmp, or siglongjmp, the behavior is undefined."

This looks better than the current text.

Jörg

[Joerg Schilling]

Post by Rich Felker

Post by Joerg Schilling
If init_routine() called longjmp() before the cancellation happens, this will
still cause an undefined behavior as then the local storage from pthread_once()
that holds the cleanup handler is not valid at cancellation time.

"If the call to init_routine ends except via a return statement or
acting upon cancellation, the behavior is undefined."
This covers the case you're concerned about, since such use of longjmp
"terminates the call" in the language of the C standard.
It also covers another issue I mentioned that hasn't yet been
addressed: what happens with the init_routine calls pthread_exit. I
think morally calling pthread_exit should be identical to acting on
cancellation, but it's probably preferable just to leave the behavior
undefined.

I see calling pthread_exit as a "covered" use case as the stack is still intact
at that time and thus the local variables can be used.

Cancellation also seems to be OK as long as the stack is still intact which
forbids the use of longjmp() from init_routine().

Jörg

[Austin Group Bug Tracker]

The following issue has been UPDATED.
======================================================================
http://austingroupbugs.net/view.php?id=863
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 863
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: Resolved
Name: Rich Felker
Organization: musl libc
User Reference:
Section: pthread_once
Page Number: 1684
Line Number: 54499
Interp Status: ---
Final Accepted Text: See
http://austingroupbugs.net/view.php?id=863#c2371.
Resolution: Accepted As Marked
Fixed in Version:
======================================================================
Date Submitted: 2014-08-05 22:09 UTC
Last Modified: 2014-09-04 15:50 UTC
======================================================================
Summary: Explicitly disallow longjmp from pthread_once
init_routine
======================================================================

Issue History
Date Modified Username Field Change
======================================================================
2014-08-05 22:09 dalias New Issue
2014-08-05 22:09 dalias Name => Rich Felker
2014-08-05 22:09 dalias Organization => musl libc
2014-08-05 22:09 dalias Section => pthread_once
2014-08-05 22:09 dalias Page Number => unknown
2014-08-05 22:09 dalias Line Number => unknown
2014-08-06 01:24 dalias Note Added: 0002333
2014-08-08 11:01 jilles Note Added: 0002339
2014-08-08 13:21 steffen Note Added: 0002341
2014-08-08 16:05 dalias Note Added: 0002342
2014-08-08 18:29 steffen Note Added: 0002344
2014-08-28 15:37 Don Cragun Note Added: 0002366
2014-08-28 16:14 Don Cragun Note Edited: 0002366
2014-08-28 16:16 Don Cragun Note Edited: 0002366
2014-08-28 16:17 Don Cragun Page Number unknown => 1684
2014-08-28 16:17 Don Cragun Line Number unknown => 54499
2014-08-28 16:17 Don Cragun Interp Status => ---
2014-08-28 16:17 Don Cragun Final Accepted Text => See
http://austingroupbugs.net/view.php?id=863#c2366.
2014-08-28 16:17 Don Cragun Status New => Resolved
2014-08-28 16:17 Don Cragun Resolution Open => Accepted As
Marked
2014-08-28 16:23 Don Cragun Note Edited: 0002366
2014-08-28 16:23 Don Cragun Tag Attached: tc2-2008
2014-08-28 16:41 dalias Note Added: 0002367
2014-08-28 17:13 mdempsky Note Added: 0002368
2014-08-28 17:55 dalias Note Added: 0002369
2014-08-28 23:27 mdempsky Note Added: 0002370
2014-09-04 15:08 nick Resolution Accepted As Marked =>
Reopened
2014-09-04 15:36 Don Cragun Note Added: 0002371
2014-09-04 15:36 Don Cragun Note Edited: 0002371
2014-09-04 15:49 Don Cragun Note Edited: 0002371
2014-09-04 15:50 Don Cragun Final Accepted Text See
http://austingroupbugs.net/view.php?id=863#c2366. => See
http://austingroupbugs.net/view.php?id=863#c2371.
2014-09-04 15:50 Don Cragun Resolution Reopened => Accepted As
Marked
======================================================================