Skip to content

Fixes #111 (pipe_buf::close doesn't close) #317

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
sehe wants to merge 1 commit into from
Closed

Fixes #111 (pipe_buf::close doesn't close) #317

sehe wants to merge 1 commit into from

Conversation

@sehe
Copy link

@sehe sehe commented Jun 10, 2023

In response to issue #111

This doesn't fundamentally change the behaviour, i.e. the destructor of basic_pipe (and by extension basic_opstream etc) will still throw when flushing to a peer that has closed.

However, it gives users of Boost Process a way to avoid this, by close()-ing the stream/buffer/pipe before the destructor runs and handling any exceptions there.

E.g.

bp::opstream _os;

~MySafeDtor() {
   try {
       _os.close();
   } catch(std::exception const& e) {
       // exception-safe logging here
   }

   assert(!_os.rdbuf()->is_open()); // without this patch, this assert fails, causing certain program termination later
}

@fanquake fanquake mentioned this pull request Nov 29, 2023
Merged
fanquake added a commit to bitcoin-core/gui that referenced this pull request Dec 13, 2023
@fanquake
Merge bitcoin/bitcoin#28967: build: disable external-signer for Windows
f0e8290 
308aec3 build: disable external-signer for Windows (fanquake)
3553731 ci: remove --enable-external-signer from win64 job (fanquake)

Pull request description:

  It's come to light that Boost ASIO (a Boost Process sub dep) has in some
  instances, been quietly  initialising our network stack on Windows (see
  PR bitcoin/bitcoin#28486 and discussion in bitcoin/bitcoin#28940).

  This has been shielding a bug in our own code, but the larger issue
  is that Boost Process/ASIO is running code before main, and doing things
  like setting up networking. This undermines our own assumptions about
  how our binary works, happens before we run any sanity checks,
  and before we call our own code to setup networking. Note that ASIO also
  calls WSAStartup with version `2.0`, whereas we call with `2.2`.

  It's also not clear why a feature like external signer would have a
  dependency that would be doing anything network/socket related,
  given it only exists to spawn a local process.

  See also the discussion in bitcoin/bitcoin#24907. Note that the maintaince of Boost Process in general,
  has not really improved. For example, rather than fixing bugs like boostorg/process#111,
  i.e, boostorg/process#317, the maintainer chooses to just wrap exception causing overflows
  in try-catch blocks: boostorg/process@0c42a58. These changes get merged in large,
  unreviewed PRs, i.e boostorg/process#319.

  This PR disables external-signer on Windows for now. If, in future, someone
  changes how Boost Process works, or replaces it entirely with some
  properly reviewed and maintained code, we could reenable this feature on
  Windows.

ACKs for top commit:
  hebasto:
    re-ACK 308aec3.
  TheCharlatan:
    ACK 308aec3

Tree-SHA512: 7405f7fc9833eeaacd6836c4e5b1c1a7845a40c1fdd55c1060152f8d8189e4777464fde650e11eb1539556a75dddf49667105987078b1457493ee772945da66e
klemens-morgenstern added a commit that referenced this pull request Oct 30, 2024
@klemens-morgenstern
Applying @sehe's patch.
12192d3 
closes #317
knst pushed a commit to knst/dash that referenced this pull request Nov 25, 2025
@fanquake @knst
Merge bitcoin#28967: build: disable external-signer for Windows
b881735 
308aec3 build: disable external-signer for Windows (fanquake)
3553731 ci: remove --enable-external-signer from win64 job (fanquake)

Pull request description:

  It's come to light that Boost ASIO (a Boost Process sub dep) has in some
  instances, been quietly  initialising our network stack on Windows (see
  PR bitcoin#28486 and discussion in bitcoin#28940).

  This has been shielding a bug in our own code, but the larger issue
  is that Boost Process/ASIO is running code before main, and doing things
  like setting up networking. This undermines our own assumptions about
  how our binary works, happens before we run any sanity checks,
  and before we call our own code to setup networking. Note that ASIO also
  calls WSAStartup with version `2.0`, whereas we call with `2.2`.

  It's also not clear why a feature like external signer would have a
  dependency that would be doing anything network/socket related,
  given it only exists to spawn a local process.

  See also the discussion in bitcoin#24907. Note that the maintaince of Boost Process in general,
  has not really improved. For example, rather than fixing bugs like boostorg/process#111,
  i.e, boostorg/process#317, the maintainer chooses to just wrap exception causing overflows
  in try-catch blocks: boostorg/process@0c42a58. These changes get merged in large,
  unreviewed PRs, i.e boostorg/process#319.

  This PR disables external-signer on Windows for now. If, in future, someone
  changes how Boost Process works, or replaces it entirely with some
  properly reviewed and maintained code, we could reenable this feature on
  Windows.

ACKs for top commit:
  hebasto:
    re-ACK 308aec3.
  TheCharlatan:
    ACK 308aec3

Tree-SHA512: 7405f7fc9833eeaacd6836c4e5b1c1a7845a40c1fdd55c1060152f8d8189e4777464fde650e11eb1539556a75dddf49667105987078b1457493ee772945da66e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@sehe