Skip to content
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.

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

Update bindgen requirement from =0.54.0 to =0.54.1 #11

Closed
wants to merge 1 commit into from

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Jul 14, 2020

Updates the requirements on bindgen to permit the latest version.

Changelog

Sourced from bindgen's changelog.

0.54.1

Released 2020/07/06.

Added

  • Added ParseCallbacks::func_macro to be able to process function-like macros. (#1792).

  • Allowed IntKind::Custom to represent paths instead of idents (#1800).

Changed

  • Generated comment now includes the bindgen version, and can be disabled (#1814).

  • Various documentation improvements.

Fixed

  • Typedefs for types with the same names as rust primitive types compiles (#1798).

  • Bindgen dependencies will now get rebuilt when various environment variables that affect bindgen change (#1809, #1813).

  • Various fixes to command_line_flags (#1816, #1819, #1821).

  • Functions that start with operator now get properly generated (#1817).

Thanks to all the awesome contributors that sent patches included in this release!

0.54.0

Released 2020/05/21.

Added

  • New command line flag to allow disabling untagged unions (#1789).

Changed

Fixed

  • Rust method wrappers are not emitted for blacklisted functions (#1775).
Commits
  • f94036f Release v0.54.1
  • 17b6ae8 main: Remove unused use statement.
  • d794a08 tests: Check that command_line_args round-trips.
  • 243359c lib: Trivially fix various command line arguments that are not properly round...
  • 51ff49a tests: Minor simplification of test harness.
  • eab1137 Introduce expectation test for operator names
  • d4c3d4c Refine test for C++ operators
  • a2fa624 lib: Fix msrv build.
  • d8968fb Properly shell quote flags in test output
  • 394648a Simplify multiple headers test
  • Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot dependabot bot added the deps About dependency management label Jul 14, 2020
@zombodb zombodb closed this Jul 14, 2020
@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Jul 14, 2020

OK, I won't notify you again about this release, but will get in touch when a new version is available.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

@dependabot dependabot bot deleted the dependabot/cargo/bindgen-eq-0.54.1 branch July 14, 2020 12:08
yrashk pushed a commit to yrashk/pgx that referenced this pull request Dec 7, 2022
Sasasu added a commit to Sasasu/pgrx that referenced this pull request Aug 17, 2023
this is because pgrx will overwrite the .so file in place.

dlopen will use mmap with MAP_PRIVATE. but if other process is modifing
the file.

dlopen will use MAP_PRIVATE to open the file and map a read-only memory
use mmap(2). usually this memory has copy-on-write. if others is modifing
the file. the previous mapped memory should not change.

but there is a undefined behavior, from man mmap(2):

```
MAP_PRIVATE: It is unspecified whether changes made to the file after the mmap()
call are visible in the mapped region.
```

what actually happens is that the read-only memory in postgresql is modified,
all pointers in the .TEXT segment is mashed up. the call stack looks like

```
 #0  0x0000000000731510 in ?? ()
 pgcentralfoundation#1  0x00007f7a94515132 in core::sync::atomic::AtomicUsize::store (self=0x7f7a95110318 <pgrx_pg_sys::submodules::thread_check::ACTIVE_THREAD::h60448dcb81097e92>, val=0, order=core::sync::atomic::Ordering::Relaxed) at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/sync/atomic.rs:2291
 pgcentralfoundation#2  0x00007f7a944f574b in pgrx_pg_sys::submodules::thread_check::init_active_thread::clear_in_child () at src/submodules/thread_check.rs:39
 pgcentralfoundation#3  0x00007f7a962f8a88 in __run_postfork_handlers (who=who@entry=atfork_run_child, do_locking=do_locking@entry=false, lastrun=lastrun@entry=2) at register-atfork.c:187
 pgcentralfoundation#4  0x00007f7a962df773 in __libc_fork () at fork.c:109
 pgcentralfoundation#5  0x00005555e66ad948 in fork_process () at fork_process.c:61
 pgcentralfoundation#6  0x00005555e66a5d48 in StartAutoVacWorker () at autovacuum.c:1543
 pgcentralfoundation#7  0x00005555e66c43f7 in StartAutovacuumWorker () at postmaster.c:6155
 pgcentralfoundation#8  0x00005555e66c3d21 in sigusr1_handler (postgres_signal_arg=10) at postmaster.c:5820
 pgcentralfoundation#9  <signal handler called>
 pgcentralfoundation#10 0x00007f7a9630eb84 in __GI___select (nfds=6, readfds=0x7ffc61c2fa40, writefds=0x0, exceptfds=0x0, timeout=0x7ffc61c2f9b0) at ../sysdeps/unix/sysv/linux/select.c:69
 pgcentralfoundation#11 0x00005555e66be343 in ServerLoop () at postmaster.c:1950
 pgcentralfoundation#12 0x00005555e66bdb0f in PostmasterMain (argc=5, argv=0x5555e8fb5490) at postmaster.c:1631
 pgcentralfoundation#13 0x00005555e6560e41 in main (argc=5, argv=0x5555e8fb5490) at main.c:240
```

the is `pgrx_pg_sys` try to run the postfork hook. but the variable `ACTIVE_THREAD`
and the code binary does not in the previous place.
Sasasu added a commit to Sasasu/pgrx that referenced this pull request Aug 17, 2023
this is because pgrx will overwrite the .so file in place.

dlopen will use mmap with MAP_PRIVATE. but if other process is modifing
the file.

dlopen will use MAP_PRIVATE to open the file and map a read-only memory
use mmap(2). usually this memory has copy-on-write. if others is modifing
the file. the previous mapped memory should not change.

but there is a undefined behavior, from man mmap(2):

```
MAP_PRIVATE: It is unspecified whether changes made to the file after the mmap()
call are visible in the mapped region.
```

what actually happens is that the read-only memory in postgresql is modified,
all pointers in the .TEXT segment is mashed up. the call stack looks like

```
 #0  0x0000000000731510 in ?? ()
 pgcentralfoundation#1  0x00007f7a94515132 in core::sync::atomic::AtomicUsize::store (self=0x7f7a95110318 <pgrx_pg_sys::submodules::thread_check::ACTIVE_THREAD::h60448dcb81097e92>, val=0, order=core::sync::atomic::Ordering::Relaxed) at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/sync/atomic.rs:2291
 pgcentralfoundation#2  0x00007f7a944f574b in pgrx_pg_sys::submodules::thread_check::init_active_thread::clear_in_child () at src/submodules/thread_check.rs:39
 pgcentralfoundation#3  0x00007f7a962f8a88 in __run_postfork_handlers (who=who@entry=atfork_run_child, do_locking=do_locking@entry=false, lastrun=lastrun@entry=2) at register-atfork.c:187
 pgcentralfoundation#4  0x00007f7a962df773 in __libc_fork () at fork.c:109
 pgcentralfoundation#5  0x00005555e66ad948 in fork_process () at fork_process.c:61
 pgcentralfoundation#6  0x00005555e66a5d48 in StartAutoVacWorker () at autovacuum.c:1543
 pgcentralfoundation#7  0x00005555e66c43f7 in StartAutovacuumWorker () at postmaster.c:6155
 pgcentralfoundation#8  0x00005555e66c3d21 in sigusr1_handler (postgres_signal_arg=10) at postmaster.c:5820
 pgcentralfoundation#9  <signal handler called>
 pgcentralfoundation#10 0x00007f7a9630eb84 in __GI___select (nfds=6, readfds=0x7ffc61c2fa40, writefds=0x0, exceptfds=0x0, timeout=0x7ffc61c2f9b0) at ../sysdeps/unix/sysv/linux/select.c:69
 pgcentralfoundation#11 0x00005555e66be343 in ServerLoop () at postmaster.c:1950
 pgcentralfoundation#12 0x00005555e66bdb0f in PostmasterMain (argc=5, argv=0x5555e8fb5490) at postmaster.c:1631
 pgcentralfoundation#13 0x00005555e6560e41 in main (argc=5, argv=0x5555e8fb5490) at main.c:240
```

the is `pgrx_pg_sys` try to run the postfork hook. but the variable `ACTIVE_THREAD`
and the code binary does not in the previous place.
Sasasu added a commit to Sasasu/pgrx that referenced this pull request Aug 17, 2023
this is because pgrx will overwrite the .so file in place.

dlopen will use mmap with MAP_PRIVATE. but if other process is modifying
the file.

dlopen will use MAP_PRIVATE to open the file and map a read-only memory
use mmap(2). usually this memory has copy-on-write. if others is modifying
the file. the previously mapped memory should not change.

but there is a undefined behavior, from man mmap(2):

```
MAP_PRIVATE: It is unspecified whether changes made to the file after the mmap()
call are visible in the mapped region.
```

what actually happens is that the read-only memory in postgresql is modified,
and all pointers in the .TEXT segment is mashed up. the call stack looks like

```
 #0  0x0000000000731510 in ?? ()
 pgcentralfoundation#1  0x00007f7a94515132 in core::sync::atomic::AtomicUsize::store (self=0x7f7a95110318 <pgrx_pg_sys::submodules::thread_check::ACTIVE_THREAD::h60448dcb81097e92>, val=0, order=core::sync::atomic::Ordering::Relaxed) at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/sync/atomic.rs:2291
 pgcentralfoundation#2  0x00007f7a944f574b in pgrx_pg_sys::submodules::thread_check::init_active_thread::clear_in_child () at src/submodules/thread_check.rs:39
 pgcentralfoundation#3  0x00007f7a962f8a88 in __run_postfork_handlers (who=who@entry=atfork_run_child, do_locking=do_locking@entry=false, lastrun=lastrun@entry=2) at register-atfork.c:187
 pgcentralfoundation#4  0x00007f7a962df773 in __libc_fork () at fork.c:109
 pgcentralfoundation#5  0x00005555e66ad948 in fork_process () at fork_process.c:61
 pgcentralfoundation#6  0x00005555e66a5d48 in StartAutoVacWorker () at autovacuum.c:1543
 pgcentralfoundation#7  0x00005555e66c43f7 in StartAutovacuumWorker () at postmaster.c:6155
 pgcentralfoundation#8  0x00005555e66c3d21 in sigusr1_handler (postgres_signal_arg=10) at postmaster.c:5820
 pgcentralfoundation#9  <signal handler called>
 pgcentralfoundation#10 0x00007f7a9630eb84 in __GI___select (nfds=6, readfds=0x7ffc61c2fa40, writefds=0x0, exceptfds=0x0, timeout=0x7ffc61c2f9b0) at ../sysdeps/unix/sysv/linux/select.c:69
 pgcentralfoundation#11 0x00005555e66be343 in ServerLoop () at postmaster.c:1950
 pgcentralfoundation#12 0x00005555e66bdb0f in PostmasterMain (argc=5, argv=0x5555e8fb5490) at postmaster.c:1631
 pgcentralfoundation#13 0x00005555e6560e41 in main (argc=5, argv=0x5555e8fb5490) at main.c:240
```

the is `pgrx_pg_sys` try to run the postfork hook. but the variable `ACTIVE_THREAD`
and the code binary does not in the previous place.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deps About dependency management
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant