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

[New pcre2 version] CLCStudent: Reverted 1 edit by 109.118.120.187 (talk) to last revision by Cnwilliams #25

Closed
github-actions bot opened this issue Feb 10, 2021 · 0 comments

Comments

@github-actions
Copy link

Reverted 1 edit by 109.118.120.187 ( talk) to last revision by Cnwilliams

← Previous revisionRevision as of 14:38, 4 December 2020Line 1:Line 1:−

{{short description|Software

{{short description|Software library for interpreting regular expressions}}

{{Infobox software

| name = Perl Compatible Regular Expressions

| logo =

| author = [[Philip Hazel]]

| developer =

| released =

| latest_release_version = PCRE 8.44 and PCRE2 10.35

| latest_release_date = {{start date and age|2020|5|9}}

| latest_release_date = {{start date and age|2020|5|9}}

| latest_preview_version =

| latest_preview_version =

Line 5:Line 12:

| programming language = [[C (programming language)|C]]

| programming language = [[C (programming language)|C]]

| operating_system = [[Cross-platform]]

| operating_system = [[Cross-platform]]

| genre = [[Pattern matching]] [[library (computing)|library]]

| genre [[library (computimore powerful and flexible than either of the [[regular expression#POSIX|POSIX regular expression]] flavors (BRE, ERE) and than that of many other regular-expression libraries.

| license = [[BSD licenses|BSD]]

| website = [https://www.pcre.org/ www.pcre.org]

}}

++

'''Perl Compatible Regular Expressions''' ('''PCRE''') is a [[library (computing)|library]] written in [[C (programming language)|C]], which implements a [[regular expression]] engine, inspired by the capabilities of the [[Perl|Perl programming language]]. [[Philip Hazel]] started writing PCRE in summer 1997 . PCRE's syntax is much more powerful and flexible than either of the [[regular expression#POSIX|POSIX regular expression]] flavors (BRE, ERE) and than that of many other regular-expression libraries.

While PCRE originally aimed at feature-equivalence with Perl, the two implementations are not fully equivalent. During the PCRE 7.x and Perl 5.9.x phase, the two projects have coordinated development, with features being ported between them in both directions.

While PCRE originally aimed at feature-equivalence with Perl, the two implementations are not fully equivalent. During the PCRE 7.x and Perl 5.9.x phase, the two projects have coordinated development, with features being ported between them in both directions.

Line 13:Line 25:

A number of prominent [[open-source software|open-source programs]], such as the [[Apache HTTP Server|Apache]] and [[Nginx]] HTTP servers, and the [[PHP]] and [[R (programming language)|R]] scripting languages, incorporate the PCRE library; proprietary software can do likewise, as the library is BSD-licensed. As of Perl 5.10, PCRE is also available as a replacement for Perl's default regular-expression engine through the re::engine::PCRE module.

A number of prominent [[open-source software|open-source programs]], such as the [[Apache HTTP Server|Apache]] and [[Nginx]] HTTP servers, and the [[PHP]] and [[R (programming language)|R]] scripting languages, incorporate the PCRE library; proprietary software can do likewise, as the library is BSD-licensed. As of Perl 5.10, PCRE is also available as a replacement for Perl's default regular-expression engine through the re::engine::PCRE module.

The library can be built on Unix, Windows, and several other environments. PCRE2 is distributed with a POSIX C wrapper , several test programs, and the utility program `pcre2grep` b

The library can be built on Unix, Windows, and several other environments. PCRE2 is distributed with a POSIX C wrapper , several test programs, and the utility program `pcre2grep` built in tandem with the library.

+++++

== Features ==

== Features ==

https://en.wikipedia.org/w/index.php?title=Perl_Compatible_Regular_Expressions&diff=992289898&oldid=prev

@dscho dscho closed this as completed Feb 10, 2021
dscho pushed a commit that referenced this issue Mar 8, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Apr 12, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jun 2, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jun 2, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jun 6, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jun 7, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Aug 24, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Nov 10, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Nov 16, 2021
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jan 15, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jan 15, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jan 18, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jan 19, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jan 19, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jan 20, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jan 25, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Feb 1, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue May 9, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue May 13, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jul 26, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Aug 18, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Sep 16, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Sep 22, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Sep 27, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Oct 3, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Oct 19, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Nov 23, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Nov 30, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Dec 6, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Dec 12, 2022
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jan 23, 2023
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Mar 17, 2023
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue May 20, 2023
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Jul 11, 2023
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Aug 8, 2023
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Aug 9, 2023
The virtual file system code incorrectly treated symlinks as directories
instead of regular files.  This meant symlinks were not included even if
they are listed in the list of files returned by the core.virtualFilesystem
hook proc.  Fixes #25

Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
dscho pushed a commit that referenced this issue Sep 13, 2024
It was recently reported that concurrent reads and writes may cause the
reftable backend to segfault. The root cause of this is that we do not
properly keep track of reftable readers across reloads.

Suppose that you have a reftable iterator and then decide to reload the
stack while iterating through the iterator. When the stack has been
rewritten since we have created the iterator, then we would end up
discarding a subset of readers that may still be in use by the iterator.
The consequence is that we now try to reference deallocated memory,
which of course segfaults.

One way to trigger this is in t5616, where some background maintenance
jobs have been leaking from one test into another. This leads to stack
traces like the following one:

  + git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin
  AddressSanitizer:DEADLYSIGNAL
  =================================================================
  ==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp
0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0)
  ==657994==The signal is caused by a READ memory access.
      #0 0x55f23e52ddf9 in get_var_int reftable/record.c:29
      #1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170
      #2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194
      #3 0x55f23e54e72e in block_iter_next reftable/block.c:398
      #4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240
      #5 0x55f23e5573dc in table_iter_next reftable/reader.c:355
      #6 0x55f23e5573dc in table_iter_next reftable/reader.c:339
      #7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69
      #8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123
      #9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172
      #10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175
      #11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464
      #12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13
      #13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452
      #14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623
      #15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659
      #16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133
      #17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432
      #18 0x55f23dba7764 in run_builtin git.c:484
      #19 0x55f23dba7764 in handle_builtin git.c:741
      #20 0x55f23dbab61e in run_argv git.c:805
      #21 0x55f23dbab61e in cmd_main git.c:1000
      #22 0x55f23dba4781 in main common-main.c:64
      #23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
      #24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360
      #25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27)

While it is somewhat awkward that the maintenance processes survive
tests in the first place, it is totally expected that reftables should
work alright with concurrent writers. Seemingly they don't.

The only underlying resource that we need to care about in this context
is the reftable reader, which is responsible for reading a single table
from disk. These readers get discarded immediately (unless reused) when
calling `reftable_stack_reload()`, which is wrong. We can only close
them once we know that there are no iterators using them anymore.

Prepare for a fix by converting the reftable readers to be refcounted.

Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant