[Bug c++/45479] New: Exceptions not delivered properly after thread cancellation

[Bug c++/45479] New: Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

[root@localhost Desktop]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/apps/gnu/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6-20100828/configure --prefix=/apps/gnu
--disable-bootstrap --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-languages=c,c++ --with-ppl=/apps/gnu
--with-cloog=/apps/gnu --with-mpc=/apps/gnu --with-mpfr=/apps/gnu
--with-gmp=/apps/gnu --with-libelf=/apps/gnu --disable-multilib
--disable-werror
Thread model: posix
gcc version 4.6.0 20100828 (experimental) (GCC) 

When a thread is cancelled via pthread_cancel, the cancelled thread's stack is
not being unwound properly and exception delivery is bugged.  This issue is
preventing me from being able to port a working system from Sun Studio/Solaris
to gcc/Linux.


-- 
           Summary: Exceptions not delivered properly after thread
                    cancellation
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mikedalpee at enginsol dot com
 GCC build triplet: x86_64-unknown-linux
  GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #1 from mikedalpee at enginsol dot com  2010-09-01 13:13 -------
Created an attachment (id=21633)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21633&action=view)
Program that demonstrates the bug


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #2 from mikedalpee at enginsol dot com  2010-09-01 13:13 -------
Created an attachment (id=21634)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21634&action=view)
script that builds the bug program


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #3 from mikedalpee at enginsol dot com  2010-09-01 13:16 -------
Created an attachment (id=21635)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21635&action=view)
output of the bug program


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #4 from mikedalpee at enginsol dot com  2010-09-01 13:27 -------
Created an attachment (id=21637)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21637&action=view)
Expected output of bug program - generated on Solaris 9 using Sun Studio 12.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #5 from mikedalpee at enginsol dot com  2010-09-01 13:32 -------
This bug occurs across all versions of the compiler I have tested - 4.3, 4.4,
4.5, and 4.6. The bug is preventing me from porting software, because correct
destructor excecution in a cancelled thread is fundamental to the proper
functioning of this software.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-09-01 13:40 -------
I am sure this is more a pthread implementation issue, so a glibc bug
on sourceware.org/bugzilla would be more appropriate.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2010-09-01 13:53 -------
Likewise about ICC.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2010-09-02 00:44 -------
Doing:
        catch (int i)
        {
                Guard g(ioSync);

                cout << "Caught " << i << endl << flush;
                sched_yield();
                pthread_testcancel();
        }

Fixes the issue.  Note there is a blog entry about POSIX thread cancel and C++
exceptions by Uli somewhere.  There was huge discussion on a mailing list about
it too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #9 from mikedalpee at enginsol dot com  2010-09-02 01:13 -------
That fix didn't change the behaviour one bit for me - was there more to it than
just moving the two lines from where they were to the exception handler?  Also,
as I am new to this venue, could you please tell me where I can find the
reference material you cited?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2010-09-02 01:19 -------
http://lmgtfy.com/?q=posix+thread+cancel+C%2B%2B+exceptions

the third link is an interesting news group entry.

http://udrepper.livejournal.com/21541.html

etc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #11 from mikedalpee at enginsol dot com  2010-09-02 13:43 -------
Created an attachment (id=21663)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21663&action=view)
Workaround for the problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #12 from mikedalpee at enginsol dot com  2010-09-02 13:44 -------
Created an attachment (id=21664)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21664&action=view)
output of the workaround


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #13 from mikedalpee at enginsol dot com  2010-09-02 13:46 -------
Simply adding an additional scope to the catch part of the function f2 try
block caused the program to execute properly.  So is this a code generation bug
or a glibc bug?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #14 from mikedalpee at enginsol dot com  2010-09-03 00:05 -------
Created an attachment (id=21679)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21679&action=view)
Program that demostrates the bug


-- 

mikedalpee at enginsol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #21633|0                           |1
        is obsolete|                            |
  Attachment #21635|0                           |1
        is obsolete|                            |
  Attachment #21637|0                           |1
        is obsolete|                            |
  Attachment #21663|0                           |1
        is obsolete|                            |
  Attachment #21664|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[mikedalpee at enginsol dot com]

------- Comment #15 from mikedalpee at enginsol dot com  2010-09-03 00:24 -------
I have spent a lot more time playing around with this, and after running the
exception1 program numerous times, the behaviour oscillates between working
correctly or not working at all.  So there appears to be some sort of race
condition during the the stack unwinding process that results from a thread
cancellation.  

In particular, it does not appear that the thread is being reliably cancelled
at the pthread_testcancel call - sometimes f2 seems to run beyond the
pthread_testcancel, which causes the throw to execute, and results in an abort
(seems to want to act like an uncaught exception propagated out).  If you
comment out the throw, f2 will sometimes continue to construct additional
objects past 50. I have also noticed that sometimes a bunch of the Y objects
get destructed, but then the program suddenly summarily exits.  I also tried
setting the cancellation type to asynchronous, but that doesn't make any
difference - sometimes it works, sometimes it don't. Its very unpredictable.

In any case, I need someone to tell me if this is the appropriate place to have
aired this particular bug, or would it be better placed in the glibc bugzilla.
I really do need this to work reliably so my 400K+ SLOC port can have a chance
to work without requiring a major redesign of the underlying thread framework.
FYI, this has been working flawlessly under Solaris/Sun Studio C++ for the last
10 years.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[redi at gcc dot gnu dot org]

------- Comment #16 from redi at gcc dot gnu dot org  2010-09-10 09:55 -------
There certainly is a race condition: there's no ordering between pthread_cancel
and pthread_testcancel so the main thread can run f2(50) before thread2 calls
pthread_cancel, which is why you see it sometimes run beyond the cancellation
point.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[redi at gcc dot gnu dot org]

------- Comment #17 from redi at gcc dot gnu dot org  2010-09-10 10:11 -------
(In reply to comment #15)
> In particular, it does not appear that the thread is being reliably cancelled
> at the pthread_testcancel call - sometimes f2 seems to run beyond the
> pthread_testcancel,

As I said above, that's consistent with f2(50) executing before pthread_cancel.

> which causes the throw to execute, and results in an abort
> (seems to want to act like an uncaught exception propagated out).  If you
> comment out the throw, f2 will sometimes continue to construct additional
> objects past 50. I have also noticed that sometimes a bunch of the Y objects
> get destructed, but then the program suddenly summarily exits.

I think that's because f2(50) leaves cancellation enabled and writing to cout
is a cancellation point, so the exit happens when some ~Y destructor coincides
with thread2 calling pthread_cancel.

> I also tried
> setting the cancellation type to asynchronous, but that doesn't make any
> difference - sometimes it works, sometimes it don't. Its very unpredictable.

Yes, race conditions tend to have unpredictable results.

If I change the condition in f2 to (i >= 50) and disable cancellation again
after the call to pthread_testcancel then I get more predictable behaviour,
because that ensures that the only cancellation points are the calls to
pthread_testcancel in f2, which still occur in f2(51), f2(52) etc. i.e.
cancellation still occurs at the intended place even if f2(50) happens before
the call to pthread_cancel.   That seems to validate my theory that the cancel
happens after f2(50), and so takes effect at the first cancellation point after
the cancellation request.

I don't think there's a gcc or glibc bug here, just non-portable code with
indeterminate behaviour.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479