[Bug libstdc++/104495] New: call_once hangs in call after exceptional call

[Bug libstdc++/104495] New: call_once hangs in call after exceptional call

[f.heckenbach@fh-soft.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

            Bug ID: 104495
           Summary: call_once hangs in call after exceptional call
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: f.heckenbach@fh-soft.de
  Target Milestone: ---

% cat test.cpp
#include <iostream>
#include <thread>
#include <mutex>

std::once_flag flag2;

void may_throw_function(bool do_throw)
{
  if (do_throw) {
    std::cout << "throw: call_once will retry\n";
    throw std::exception();
  }
  std::cout << "Didn't throw, call_once will not attempt again\n";
}

void do_once(bool do_throw)
{
  try {
    std::call_once(flag2, may_throw_function, do_throw);
  }
  catch (...) {
  }
}

int main()
{
    do_once (true);
    do_once (false);
}
% g++ test.cpp -pthread
% ./a.out
throw: call_once will retry
[hangs]

This is a simplified version of the example from
https://en.cppreference.com/w/cpp/thread/call_once -- the full example also
hangs.

My actual use case is a bit different, but it seems any call after an exception
call hangs; that's all that seems relevant.

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=66146

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What target is this on?

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[f.heckenbach@fh-soft.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

--- Comment #2 from Frank Heckenbach <f.heckenbach@fh-soft.de> ---
% g++ -print-multiarch
x86_64-linux-gnu

Debian 11.2, Linux 5.10.0-9-amd64

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-02-10
             Status|UNCONFIRMED                 |WAITING

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
And with which glibc if on Linux. The glibc issue
(https://sourceware.org/bugzilla/show_bug.cgi?id=18435) was just fixed in 2.34
which was released only last year so your distro might have not picked it up
yet.

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[f.heckenbach@fh-soft.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

--- Comment #4 from Frank Heckenbach <f.heckenbach@fh-soft.de> ---
Indeed, it has 2.31.

2.34 is only just in Debian experimental, and apparently not available as a
backport.

Since I need my code to run on various systems and I can't realistically
compile a new glibc on them, this means I have to avoid std::once_flag until
2.34 is in widespread use, is that correct?

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[f.heckenbach@fh-soft.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

--- Comment #5 from Frank Heckenbach <f.heckenbach@fh-soft.de> ---
As I replacement, I'll use the following code. It's a simple double-checked
lock, probably not as efficient as the original, but seems to work.

Posted here as RFC and for anyone else who encounters the problem. Released
under CC0/public domain.

#include <mutex>
#include <atomic>
#include <functional>

class once_flag
{
  std::atomic <bool> a { };
  std::mutex m;
public:
  once_flag () = default;
  once_flag (once_flag &) = delete;
  friend void call_once (once_flag &o, auto &&f, auto && ... args)
  {
    if (!o.a)
      if (std::lock_guard g (o.m); !o.a)
        {
          std::invoke (std::forward <decltype (f)> (f), std::forward <decltype
(args)> (args) ...);
          o.a = true;
        }
  }
};

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|WAITING                     |RESOLVED

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is just a dup of PR 66146

*** This bug has been marked as a duplicate of bug 66146 ***

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[f.heckenbach@fh-soft.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

Frank Heckenbach <f.heckenbach@fh-soft.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|DUPLICATE                   |FIXED

--- Comment #7 from Frank Heckenbach <f.heckenbach@fh-soft.de> ---
Not quite the same:

- 66146 reports wrong output, not hanging
- 66146 says "amd64 has the correct behavior", this once fails on amd64

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
See PR 66146 comment 26, it affects all architectures, including x86_64.

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |DUPLICATE

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Please don't change the status to FIXED when nothing has been fixed. This is
GCC's bug tracker, and there is no fix in GCC.

This is a dup of 66146.

*** This bug has been marked as a duplicate of bug 66146 ***

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[f.heckenbach@fh-soft.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

--- Comment #10 from Frank Heckenbach <f.heckenbach@fh-soft.de> ---
If it was me, it wasn't intentional, sorry.

The select box on the web form defaults to "FIXED" for me even on reload (F5).
I had to click on the link to itself to get a clean form (set to "DUPLICATE").
Don't know if that's the expected behaviour, but it did apparently confuse me.

[Bug libstdc++/104495] call_once hangs in call after exceptional call

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
If you've entered any text or adjusted any dropdown selections while on the
page, then refreshing will preserve those changes.