Option to secure plesk-panel isn't shown

Hello,
actually the option to secure the plesk panel with the domain certificate isn't shown for me. I reinstalled the extension yesterday. Is there any settings which could prevent this?

You have to make sure you access Plesk via the same domain you are trying to secure.
If your Plesk you are trying to secure runs on https://plesk01.domain.com:8443 you need to access the Plesk panel through that url and create a domain/subdomain for plesk01.domain.com and then request a certificate for that domain/subdomain the option will show there.

Thank your for this information. Now it work.


Access Forbidden after logging in steam

Hi!
I'm not sure why this issue comes up after logging in. Should I somehow connect it with my database?
https://gyazo.com/db8289efa046db6ce272a2bc5d6b63ee

There are constantly issues with free hosting providers.
I don't think there is any problem with the libary. Please close this issue.
You can and should develop locally using a server suite like XAMPP or WiNGINX.
Free hosting is always very limited and should not be used for anything besides maybe a family/event website.


test: run fake upstream initialization from the dispatcher thread

//test/integration:tcp_proxy_odcds_integration_test was observed to fail as follows:
==================== Test output for //test/integration:tcp_proxy_odcds_integration_test:
[==========] Running 24 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 24 tests from IpVersionsClientType/TcpProxyOdcdsIntegrationTest
[ RUN      ] IpVersionsClientType/TcpProxyOdcdsIntegrationTest.SingleTcpClient/0
[2022-08-25 20:22:46.750][3969][critical][assert] [test/integration/fake_upstream.cc:832] assert failure: !dispatcher_->isThreadSafe().
[2022-08-25 20:22:46.752][3969][critical][backtrace] [./source/server/backtrace.h:104] Caught Aborted, suspect faulting address 0x6b00000f81
[2022-08-25 20:22:46.752][3969][critical][backtrace] [./source/server/backtrace.h:91] Backtrace (use tools/stack_decode.py to get line numbers):
[2022-08-25 20:22:46.752][3969][critical][backtrace] [./source/server/backtrace.h:92] Envoy version: 0/1.24.0-dev/test/DEBUG/BoringSSL
[2022-08-25 20:22:46.773][3969][critical][backtrace] [./source/server/backtrace.h:96] #0: Envoy::SignalAction::sigHandler() [0x4c46a78]->[0x2cf2a78] external/com_google_googletest/googlemock/include/gmock/gmock-spec-builders.h:1267
[2022-08-25 20:22:46.773][3969][critical][backtrace] [./source/server/backtrace.h:96] #1: __restore_rt [0x7ffbdaa79420]->[0x7ffbd8b25420] ??:0
[2022-08-25 20:22:46.802][3969][critical][backtrace] [./source/server/backtrace.h:96] #2: Envoy::FakeUpstream::assertPendingConnectionsEmpty() [0x245bf0b]->[0x507f0b] ??:0
[2022-08-25 20:22:46.846][3969][critical][backtrace] [./source/server/backtrace.h:96] #3: Envoy::(anonymous namespace)::TcpProxyOdcdsIntegrationTest_SingleTcpClient_Test::TestBody() [0x1f596cb]->[0x56cb] ??:0
[2022-08-25 20:22:46.877][3969][critical][backtrace] [./source/server/backtrace.h:96] #4: testing::internal::HandleSehExceptionsInMethodIfSupported<>() [0x588b61b]->[0x393761b] ??:0
[2022-08-25 20:22:46.924][3969][critical][backtrace] [./source/server/backtrace.h:96] #5: testing::internal::HandleExceptionsInMethodIfSupported<>() [0x587c2bd]->[0x39282bd] ??:0
[2022-08-25 20:22:46.966][3969][critical][backtrace] [./source/server/backtrace.h:96] #6: testing::Test::Run() [0x5864ba3]->[0x3910ba3] /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stl_vector.h:0
[2022-08-25 20:22:47.003][3969][critical][backtrace] [./source/server/backtrace.h:96] #7: testing::TestInfo::Run() [0x586576a]->[0x391176a] external/com_google_absl/absl/container/internal/raw_hash_set.h:1259
[2022-08-25 20:22:47.037][3969][critical][backtrace] [./source/server/backtrace.h:96] #8: testing::TestSuite::Run() [0x5865fbb]->[0x3911fbb] /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stl_algo.h:1925
[2022-08-25 20:22:47.089][3969][critical][backtrace] [./source/server/backtrace.h:96] #9: testing::internal::UnitTestImpl::RunAllTests() [0x5874a28]->[0x3920a28] envoy/registry/registry.h:509
[2022-08-25 20:22:47.114][3969][critical][backtrace] [./source/server/backtrace.h:96] #10: testing::internal::HandleSehExceptionsInMethodIfSupported<>() [0x588ddbb]->[0x3939dbb] envoy/registry/registry.h:0
[2022-08-25 20:22:47.160][3969][critical][backtrace] [./source/server/backtrace.h:96] #11: testing::internal::HandleExceptionsInMethodIfSupported<>() [0x587e683]->[0x392a683] /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/unique_ptr.h:154
[2022-08-25 20:22:47.191][3969][critical][backtrace] [./source/server/backtrace.h:96] #12: testing::UnitTest::Run() [0x5874568]->[0x3920568] envoy/registry/registry.h:508
[2022-08-25 20:22:47.237][3969][critical][backtrace] [./source/server/backtrace.h:96] #13: RUN_ALL_TESTS() [0x4878d51]->[0x2924d51] external/com_google_googletest/googlemock/include/gmock/gmock-spec-builders.h:1203
[2022-08-25 20:22:47.284][3969][critical][backtrace] [./source/server/backtrace.h:96] #14: Envoy::TestRunner::RunTests() [0x48783b1]->[0x29243b1] external/com_google_googletest/googlemock/include/gmock/gmock-actions.h:485
[2022-08-25 20:22:47.316][3969][critical][backtrace] [./source/server/backtrace.h:96] #15: main [0x4874c3a]->[0x2920c3a] external/com_google_googletest/googlemock/include/gmock/gmock-spec-builders.h:1181
[2022-08-25 20:22:47.316][3969][critical][backtrace] [./source/server/backtrace.h:96] #16: __libc_start_main [0x7ffbda897083]->[0x7ffbd8943083] ??:0
================================================================================

This is due to the race described by https://github.com/envoyproxy/envoy/issues/22855. Making sure the dispatcher thread is running before starting the test avoids this problem.
Signed-off-by: Benjamin Peterson<EMAIL_ADDRESS>
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/retest


Interactive performance is horrible after displaying a full screen image with viu

Environment
Windows build number: Microsoft Windows [Version 10.0.18362.239]
Windows Terminal version 0.3.2142.0
Testing using wsl 1.0,  Ubuntu 18.04.2 LTS
viu 0.2.1 https://crates.io/crates/viu

Steps to reproduce
Install viu, and display an image big enough to be full screen
cargo install viu
viu /mnt/c/.../image.jpg
type
Expected behavior
No performance drop
Actual behavior
Typing performance will be horrible until the image has been scrolled off the screen.  Bad enough that typing will have 1 second of lag.

Probably two issues here. One is #778, one is #1064. Also, we're probably reserializing the entire buffer over conpty again and again. Sometimes it happens.


Can you link IFTTT to the HueMulator

Love this software BTW it has allowed me to tie my X10 System and IR control into the amazon echo using a raspberry pi, with the built in IR stuff in the Raspberry and mochad/heyu.  Here in one example of what I am currently doing.
Alexa turn on Channel 7.  I have a bridge device called channelseven which in turn runs am http  command on the raspberry pi which then sends the correct IR commands to change to channel 7.  However the echo is a little touchy with some names like ESPN and BBC, so some commands like "Alexa turn on BBC" don't work.
Here is where I am going with this.
Would be nice to use IFTTT and have a single device called Channel.  So I could say "Alexa Trigger Channel 7 or trigger Channel BBC and then have the bridge pass the third word as a variable.
I guess the possibilities could be endless.  Anyway, not sure it's possible, just a thought.  Thanks again for all of your hard work on this project.

I have not looked into being an IFTTT channel and as every bridge is in someones network, I don't know if that would work.

So, if you want to be very unsecured, you could use this https://ifttt.com/maker. I would not take any responsibility in anyone exposing the bridge to the internet. Just a Bad, Bad, Bad idea....

I think I agree with you, but will look into it.  Thanks for the info.


(fluid-devtools)Bug-fix: Audience history doesn't refresh when disconnect container

Description

When the disconnect button is clicked, the audience history fails to display the disconnect record. This likely occurs due to a missing pull content message when a new disconnect record is received.

Sample
https://github.com/microsoft/FluidFramework/assets/114451900/c7eb69f0-d544-4655-bb48-1e75ad94a648

I'm not sure this is the right change. Our devtools are supposed to be a reflection of the Container API; they shouldn't be making any changes to Container behavior. If the Container's audience contents don't change when the it disconnects, then that is what we should probably display. If we do anything else, we are either lying about the Container state, or we are introducing system policy changes that don't exist when the devtools aren't running. Neither is probably a good idea.
A potential alternative approach would be to simply not display the audience view when the Container is disconnected. Or display a notice that since the Container is disconnected, audience information may not be reliable.
With the current behavior, the audience list gets corrected when the container reconnects, right?

Discussed during parking lot, I will just close this one as it's expected behavior. Thanks, team! I learned!


Offer using TTS for generating ring tones

Please, offer using TTS  on contact names for generating ring tones

Any reason why not to do this? Google TTS is even installed with GAPPS pico.


added OAHashMap type

What does OA stands for ?

@groud
OAHashMap = Osteoarthritis Open Addressing HashMap?

I think it might be better to just name it OpenAddressingHashMap and be explicit about it, unless it's meant to be used in hundreds of locations in the code and would really be too inconvenient to type.


Running, pause, idle notification

Prerequisites

[X] I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request
It could be useful to be possible to send notification when the bot is RUNNING, PAUSED and IDLE.
Also when it gets some errors.
Describe the Use Case
It could be useful to be possible to send notification when the bot is RUNNING, PAUSED and IDLE.
Also when it gets some errors.
Describe Preferred Solution
No response
Describe Alternatives
No response
Additional Information
No response

Added in the latest version


YARA newbie trying to understand use of data_base and offset

Hello, I'm a YARA newbie and trying to better understand the C internals. I found something a little confusing, and so I thought I'd ask here for further clarification:
Have been looking at the function yr_scan_verify_match() [1] which gets passed parameters data, data_size, data_base, and offset. Everything is pretty obvious except for data_base and offset. These appear to be not one, but two different 'offsets' into the bytes at pointer data of length data_size:
int yr_scan_verify_match(
    YR_SCAN_CONTEXT* context,
    YR_AC_MATCH* ac_match,
    const uint8_t* data,
    size_t data_size,
    uint64_t data_base,
    size_t offset)
{
...

The function also appears to use both offsets together in the following code [2]:
  if (STRING_IS_FIXED_OFFSET(string) &&
      string->fixed_offset != data_base + offset)
    return ERROR_SUCCESS;
...
}

And then later on data_base and offset are passed to e.g. _yr_scan_verify_literal_match() [3] which appears to ignore data_base and only use offset:
static int _yr_scan_verify_literal_match(
    YR_SCAN_CONTEXT* context,
    YR_AC_MATCH* ac_match,
    const uint8_t* data,
    size_t data_size,
    uint64_t data_base,
    size_t offset)
{
...
    if (STRING_IS_ASCII(string))
    {
      forward_matches = _yr_scan_icompare(
          data + offset,
          data_size - offset,
          string->string,
          string->length);
    }
...
}

At first glance this appears to be a bug, but the code seems to be working never-the-less because AFAICT data_base is always zero at run-time? Under which circumstances is data_base non-zero? If it's not a bug, then what's a good explanation for how data_base is intended to be used?
Thanks in advance!
[1] https://github.com/VirusTotal/yara/blob/master/libyara/scan.c#L883
[2] https://github.com/VirusTotal/yara/blob/master/libyara/scan.c#L906
[3] https://github.com/VirusTotal/yara/blob/master/libyara/scan.c#L778

It looks like the terms base and offset are mentioned here [1] together with the comment "While scanning a file [base] is usually zero":
  .. c:member:: int64_t base

    Base offset/address for the match. While scanning a file this field is
    usually zero, while scanning a process memory space this field is the
    virtual address of the memory block where the match was found.

  .. c:member:: int64_t offset

    Offset of the match relative to *base*.

But I also came across this comment in the docs [2]:
size_t base

Base offset/address for this block. If a file is being scanned this field contains the offset within the file where the block begins, if a process memory space is being scanned this contains the virtual address where the block begins.

...

In the case of files the first block will contain the beginning of the file. Actually, a single block will contain the whole file's content in most cases, but you can't rely on that while writing your code. For very big files YARA could eventually split the file into two or more blocks, and your module should be prepared to handle that.

Does this mean that base / data_base might be non-zero for larger files? FYI I looked into the source code but contrary to the documentation, it appears to always mmap() a complete file no matter how large it is, thus always providing a single block causing data_base to always be zero... So is this documentation wrong with regards to larger files?
[1] https://yara.readthedocs.io/en/stable/capi.html#data-structures
[2] https://yara.readthedocs.io/en/stable/writingmodules.html#accessing-the-scanned-data

In the current implementation base is always 0 when scanning a file, and the virtual address of the memory block when scanning a process memory. What the documentation is trying to say is that you must always be prepared for base being something different than zero. The real offset within the file (or the virtual address when scanning a process memory) is always base + offset.

So regarding the docs [1] and this statement regarding "a single block" versus "two or more blocks"...
In the case of files the first block will contain the beginning of the file. Actually, a
single block will contain the whole file's content in most cases, but you can't rely
on that while writing your code. For very big files YARA could eventually split the
file into two or more blocks, and your module should be prepared to handle that.

...I thought I would investigate that further so I created a branch of YARA here [2] which does the following:

Implements a special test mode which splits memory in blocks of a given size before scanning.
Tests running initially with single block mode, but then test_strings() is repeated using multiple blocks.
Lastly I added some test instrumentation to try and understand what is happened / going wrong.

The result is that either I am misunderstanding how YARA should work scanning memory as multiple blocks, or the current code might need tweaking to make it better because some of the tests fail if the memory is delivered as multiple blocks instead of a single block.
Here's how to duplicate my steps:
Building and compiling:
$ git clone --single-branch --branch test-base-and-offset https://github.com/simonhf/yara.git
$ cd yara/
$ git status
On branch test-base-and-offset
$ ./bootstrap.sh
$ YACC=bison ./configure # avoids POSIX Yacc warnings
$ time make -j `nproc`
real    0m4.935s

Testing without multiple blocks works as expected, and the second call to test_strings() just runs a bunch of tests again using single blocks, and all tests pass showing that my minimum changes are at least not messing up the existing tests:
$ rm test-rules.log ; time make check ; echo "test-rules.log:" ; cat test-rules.log
...
PASS: test-arena
PASS: test-alignment
PASS: test-atoms
PASS: test-api
PASS: test-rules
PASS: test-pe
PASS: test-elf
PASS: test-version
PASS: test-bitmask
PASS: test-math
PASS: test-stack
PASS: test-re-split
PASS: test-exception
...
test-rules.log:
+ test_boolean_operators() {}
+ test_comparison_operators() {}
+ test_arithmetic_operators() {}
+ test_bitwise_operators() {}
+ test_matches_operator() {}
+ test_syntax() {}
+ test_anonymous_strings() {}
+ test_strings() {}
+ test_wildcard_strings() {}
+ test_hex_strings() {}
+ test_count() {}
+ test_at() {}
+ test_in() {}
+ test_offset() {}
+ test_of() {}
+ test_for() {}
+ test_re() {}
+ test_filesize() {}
+ test_include_files() {}
+ test_comments() {}
+ test_modules() {}
+ test_integer_functions() {}
+ test_entrypoint() {}
+ test_global_rules() {}
+ test_tags() {}
+ test_process_scan() {}
+ test_hash_module() {}
+ test_time_module() {}
+ test_performance_warnings() {}
- // re-run the string tests but split the data into blocks of max 0 bytes (0 means single and unlimited block size and is the default)
+ test_strings() {}
PASS test-rules (exit status: 0)

Setting the block size to bigger than the biggest possible test block also causes the tests to pass, because again, only single blocks are being used, but this time we can see that I left in some instrumentation highlighting the first test which goes wrong when multiple blocks are used (please see further belew):
$ rm test-rules.log ; make check YR_TEST_MEM_BLOCK_SIZE=65536 ; echo "test-rules.log:" ; cat test-rules.log
...
PASS: test-arena
PASS: test-alignment
PASS: test-atoms
PASS: test-api
PASS: test-rules
PASS: test-pe
PASS: test-elf
PASS: test-version
PASS: test-bitmask
PASS: test-math
PASS: test-stack
PASS: test-re-split
PASS: test-exception
...
test-rules.log:
+ test_boolean_operators() {}
+ test_comparison_operators() {}
+ test_arithmetic_operators() {}
+ test_bitwise_operators() {}
+ test_matches_operator() {}
+ test_syntax() {}
+ test_anonymous_strings() {}
+ test_strings() {}
+ test_wildcard_strings() {}
+ test_hex_strings() {}
+ test_count() {}
+ test_at() {}
+ test_in() {}
+ test_offset() {}
+ test_of() {}
+ test_for() {}
+ test_re() {}
+ test_filesize() {}
+ test_include_files() {}
+ test_comments() {}
+ test_modules() {}
+ test_integer_functions() {}
+ test_entrypoint() {}
+ test_global_rules() {}
+ test_tags() {}
+ test_process_scan() {}
+ test_hash_module() {}
+ test_time_module() {}
+ test_performance_warnings() {}
- // re-run the string tests but split the data into blocks of max 65536 bytes (0 means single and unlimited block size and is the default)
+ test_strings() {}
- fixme: the next test below fails in different ways depending upon the mem block size used
- fixme: the last test after fails in different ways depending upon the mem block size used; skipping remaining tests which also fail
PASS test-rules (exit status: 0)

Running the tests with multiple blocks of maximum 1024 bytes causes at least one test to fail, however, instrumentation has not been enabled so we just see the test assert:
$ rm test-rules.log ; make check YR_TEST_MEM_BLOCK_SIZE=1024 ; echo "test-rules.log:" ; cat test-rules.log
...
PASS: test-arena
PASS: test-alignment
PASS: test-atoms
PASS: test-api
FAIL: test-rules
PASS: test-pe
PASS: test-elf
PASS: test-version
PASS: test-bitmask
PASS: test-math
PASS: test-stack
PASS: test-re-split
PASS: test-exception
...
test-rules.log:
+ test_boolean_operators() {}
+ test_comparison_operators() {}
+ test_arithmetic_operators() {}
+ test_bitwise_operators() {}
+ test_matches_operator() {}
+ test_syntax() {}
+ test_anonymous_strings() {}
+ test_strings() {}
+ test_wildcard_strings() {}
+ test_hex_strings() {}
+ test_count() {}
+ test_at() {}
+ test_in() {}
+ test_offset() {}
+ test_of() {}
+ test_for() {}
+ test_re() {}
+ test_filesize() {}
+ test_include_files() {}
+ test_comments() {}
+ test_modules() {}
+ test_integer_functions() {}
+ test_entrypoint() {}
+ test_global_rules() {}
+ test_tags() {}
+ test_process_scan() {}
+ test_hash_module() {}
+ test_time_module() {}
+ test_performance_warnings() {}
- // re-run the string tests but split the data into blocks of max 1024 bytes (0 means single and unlimited block size and is the default)
+ test_strings() {}
- fixme: the next test below fails in different ways depending upon the mem block size used
tests/test-rules.c:572: rule does not match contents of'tests/data/xor.out' (but should)
FAIL test-rules (exit status: 1)

Running the tests with multiple blocks of maximum 1024 bytes causes at least one test to fail, and, instrumentation has been enabled so we get to see what was happening:
$ rm test-rules.log ; make check YR_TEST_MEM_BLOCK_SIZE=1024 YR_TEST_VERBOSITY=1 ; echo "test-rules.log:" ; cat test-rules.log
...
PASS: test-arena
PASS: test-alignment
PASS: test-atoms
PASS: test-api
FAIL: test-rules
PASS: test-pe
PASS: test-elf
PASS: test-version
PASS: test-bitmask
PASS: test-math
PASS: test-stack
PASS: test-re-split
PASS: test-exception
...
test-rules.log:
+ test_boolean_operators() {}
+ test_comparison_operators() {}
+ test_arithmetic_operators() {}
+ test_bitwise_operators() {}
+ test_matches_operator() {}
+ test_syntax() {}
+ test_anonymous_strings() {}
+ test_strings() {}
+ test_wildcard_strings() {}
+ test_hex_strings() {}
+ test_count() {}
+ test_at() {}
+ test_in() {}
+ test_offset() {}
+ test_of() {}
+ test_for() {}
+ test_re() {}
+ test_filesize() {}
+ test_include_files() {}
+ test_comments() {}
+ test_modules() {}
+ test_integer_functions() {}
+ test_entrypoint() {}
+ test_global_rules() {}
+ test_tags() {}
+ test_process_scan() {}
+ test_hash_module() {}
+ test_time_module() {}
+ test_performance_warnings() {}
- // re-run the string tests but split the data into blocks of max 1024 bytes (0 means single and unlimited block size and is the default)
+ test_strings() {}
+ yr_rules_scan_mem(buffer=0x557698d2c0d8 buffer_size=1041) {} // yr_test_mem_block_size=1024
+ yr_scanner_create() {}
+ yr_scanner_scan_mem_blocks() {}
+ _yr_test_mem_block_size_get_first_block() {} // wrapping _yr_test_mem_block_size_get_next_block()
+ _yr_test_mem_block_size_get_next_block() {} // .base=0x0 of 0x411 or 1041 .size=1024
+ _yr_test_mem_block_size_fetch_block_data() {} = 0x557698d2c0d8 = 0x557698d2c0d8 + 0x0
+ _yr_scanner_scan_mem_block(block_data=0x557698d2c0d8 block->base=0x0 block->size=1024) {}
+ _yr_test_mem_block_size_get_next_block() {} // .base=0x400 of 0x411 or 1041 .size=17
+ _yr_test_mem_block_size_fetch_block_data() {} = 0x557698d2c4d8 = 0x557698d2c0d8 + 0x400
+ _yr_scanner_scan_mem_block(block_data=0x557698d2c4d8 block->base=0x400 block->size=17) {}
- match_table[state=1]=1 i=6 block_data=0x557698d2c4d8 block->base=0x400 // _yr_scanner_scan_mem_block()
+ yr_scan_verify_match(data=0x557698d2c4d8 data_size=17 data_base=0x400 offset=5)
+ _yr_scan_verify_literal_match(data=0x557698d2c4d8 data_size=17 data_base=0x400 offset=5) {}
+ _yr_scan_match_callback(match_data=0x557698d2c4dd match_length=0) { // match_offset=5 args->data=0x557698d2c4d8 args->string.length=1 args->data_base=0x400 args->data_size=17 args->forward_matches=1
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=0 += 1
} // _yr_scan_match_callback() = 0
+ _yr_test_mem_block_size_get_next_block() {} // .base=0x411 of 0x411 or 1041 .size=0 AKA block end
+ yr_scanner_destroy() {}
...
- fixme: the next test below fails in different ways depending upon the mem block size used
+ yr_rules_scan_mem(buffer=0x55efd0d36780 buffer_size=6383) {} // yr_test_mem_block_size=1024
+ yr_scanner_create() {}
+ yr_scanner_scan_mem_blocks() {}
+ _yr_test_mem_block_size_get_first_block() {} // wrapping _yr_test_mem_block_size_get_next_block()
+ _yr_test_mem_block_size_get_next_block() {} // .base=0x0 of 0x18ef or 6383 .size=1024
+ _yr_test_mem_block_size_fetch_block_data() {} = 0x55efd0d36780 = 0x55efd0d36780 + 0x0
+ _yr_scanner_scan_mem_block(block_data=0x55efd0d36780 block->base=0x0 block->size=1024) {}
- match_table[state=447]=0 i=1 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=313]=0 i=2 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=447]=0 i=3 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=475]=0 i=4 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=257]=0 i=5 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=595]=0 i=6 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=1112]=0 i=7 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=666]=256 i=8 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
+ yr_scan_verify_match(data=0x55efd0d36780 data_size=1024 data_base=0x0 offset=4)
+ _yr_scan_verify_literal_match(data=0x55efd0d36780 data_size=1024 data_base=0x0 offset=4) {}
+ _yr_scan_xor_compare(data_size=1020 string_length=19) {} = 19
+ _yr_scan_match_callback(match_data=0x55efd0d36784 match_length=0) { // match_offset=4 args->data=0x55efd0d36780 args->string.length=19 args->data_base=0x0 args->data_size=1024 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=0 += 1
} // _yr_scan_match_callback() = 0
- match_table[state=475]=0 i=9 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=306]=0 i=10 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=302]=0 i=11 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=330]=0 i=12 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=319]=0 i=13 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=302]=0 i=14 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=318]=0 i=15 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=333]=0 i=16 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=475]=0 i=17 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=321]=0 i=18 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=318]=0 i=19 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=312]=0 i=20 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=312]=0 i=21 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=330]=0 i=22 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=282]=0 i=23 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=444]=0 i=24 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=447]=0 i=25 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=313]=0 i=26 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=449]=0 i=27 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=475]=0 i=28 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=258]=0 i=29 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=599]=0 i=30 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=1114]=0 i=31 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
- match_table[state=1178]=255 i=32 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
+ yr_scan_verify_match(data=0x55efd0d36780 data_size=1024 data_base=0x0 offset=28)
+ _yr_scan_verify_literal_match(data=0x55efd0d36780 data_size=1024 data_base=0x0 offset=28) {}
+ _yr_scan_xor_compare(data_size=996 string_length=19) {} = 19
+ _yr_scan_match_callback(match_data=0x55efd0d3679c match_length=0) { // match_offset=28 args->data=0x55efd0d36780 args->string.length=19 args->data_base=0x0 args->data_size=1024 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=1 += 1
} // _yr_scan_match_callback() = 0
- match_table[state=473]=0 i=33 block_data=0x55efd0d36780 block->base=0x0 // _yr_scanner_scan_mem_block()
...
- match_table[state=2047]=2 i=199 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
+ yr_scan_verify_match(data=0x5629b4644f80 data_size=239 data_base=0x1800 offset=195)
+ _yr_scan_verify_literal_match(data=0x5629b4644f80 data_size=239 data_base=0x1800 offset=195) {}
+ _yr_scan_xor_compare(data_size=44 string_length=19) {} = 19
+ _yr_scan_match_callback(match_data=0x5629b4645043 match_length=0) { // match_offset=195 args->data=0x5629b4644f80 args->string.length=19 args->data_base=0x1800 args->data_size=239 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=243 += 1
} // _yr_scan_match_callback() = 0
- match_table[state=516]=0 i=200 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=642]=0 i=201 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=641]=0 i=202 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=627]=0 i=203 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=638]=0 i=204 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=641]=0 i=205 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=578]=0 i=206 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=629]=0 i=207 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=516]=0 i=208 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=575]=0 i=209 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=578]=0 i=210 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=626]=0 i=211 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=626]=0 i=212 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=627]=0 i=213 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=644]=0 i=214 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=444]=0 i=215 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=447]=0 i=216 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=313]=0 i=217 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=300]=0 i=218 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=300]=0 i=219 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=475]=0 i=220 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=688]=0 i=221 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=1210]=0 i=222 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=1731]=0 i=223 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=2048]=1 i=224 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
+ yr_scan_verify_match(data=0x5629b4644f80 data_size=239 data_base=0x1800 offset=220)
+ _yr_scan_verify_literal_match(data=0x5629b4644f80 data_size=239 data_base=0x1800 offset=220) {}
+ _yr_scan_xor_compare(data_size=19 string_length=19) {} = 19
+ _yr_scan_match_callback(match_data=0x5629b464505c match_length=0) { // match_offset=220 args->data=0x5629b4644f80 args->string.length=19 args->data_base=0x1800 args->data_size=239 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=244 += 0
} // _yr_scan_match_callback() = 0
- match_table[state=517]=0 i=225 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=635]=0 i=226 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=636]=0 i=227 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=626]=0 i=228 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=637]=0 i=229 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=636]=0 i=230 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=577]=0 i=231 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=628]=0 i=232 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=517]=0 i=233 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=573]=0 i=234 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=577]=0 i=235 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=627]=0 i=236 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=627]=0 i=237 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=626]=0 i=238 block_data=0x5629b4644f80 block->base=0x1800 // _yr_scanner_scan_mem_block()
+ _yr_test_mem_block_size_get_next_block() {} // .base=0x18ef of 0x18ef or 6383 .size=0 AKA block end
+ yr_scanner_destroy() {}
tests/test-rules.c:572: rule does not match contents of'tests/data/xor.out' (but should)
FAIL test-rules (exit status: 1)

In this particular test in test_strings() which is failing then it's searching for a string and only passes if the string is found 256 times. However, the instrumentation shows that when the memory searched is made available to YARA in multiple blocks of maximum 1024 bytes then only 244 strings are found instead of 256 strings:
$ cat test-rules.log | egrep "count=" | tail -1
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=244 += 0

So how are the 256 - 244 = 12 string occurrences going missing? The test debug instrumentation shows there are two issues happening in the code:
Issue #1: A total of 6 strings are not detected because they straddle a block boundary. Here the instrumentation shows for the first missing string that the start of the 19 byte string is detected at an offset of 1014 bytes into the 1024 byte block, which only leaves only 10 bytes which is not enough to contain the 19 bytes string, and so the string is not detected:
$ cat test-rules.log | egrep --before-context=1 --after-context=0 "_yr_scan_xor_compare.+ = 0$"
+ _yr_scan_verify_literal_match(data=0x555e09573780 data_size=1024 data_base=0x0 offset=1014) {}
+ _yr_scan_xor_compare(data_size=10 string_length=19) {} = 0
--
+ _yr_scan_verify_literal_match(data=0x555e09573b80 data_size=1024 data_base=0x400 offset=1015) {}
+ _yr_scan_xor_compare(data_size=9 string_length=19) {} = 0
--
+ _yr_scan_verify_literal_match(data=0x555e09573f80 data_size=1024 data_base=0x800 offset=1016) {}
+ _yr_scan_xor_compare(data_size=8 string_length=19) {} = 0
--
+ _yr_scan_verify_literal_match(data=0x555e09574380 data_size=1024 data_base=0xc00 offset=1017) {}
+ _yr_scan_xor_compare(data_size=7 string_length=19) {} = 0
--
+ _yr_scan_verify_literal_match(data=0x555e09574780 data_size=1024 data_base=0x1000 offset=1018) {}
+ _yr_scan_xor_compare(data_size=6 string_length=19) {} = 0
--
+ _yr_scan_verify_literal_match(data=0x555e09574b80 data_size=1024 data_base=0x1400 offset=1019) {}
+ _yr_scan_xor_compare(data_size=5 string_length=19) {} = 0

Issue #2: A total of another 6 strings are not detected because after being found, the function _yr_scan_add_match_to_list() fails to add them to the list of finds, and the find count is not incremented:
$ cat test-rules.log | egrep --before-context=1 --after-context=0 "_yr_scan_add_match_to_list.+ 0$"
...
+ _yr_scan_match_callback(match_data=0x555e09573cd4 match_length=0) { // match_offset=340 args->data=0x555e09573b80 args->string.length=19 args->data_base=0x400 args->data_size=1024 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=54 += 0
--
+ _yr_scan_match_callback(match_data=0x555e095740bc match_length=0) { // match_offset=316 args->data=0x555e09573f80 args->string.length=19 args->data_base=0x800 args->data_size=1024 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=92 += 0
--
+ _yr_scan_match_callback(match_data=0x555e095744a4 match_length=0) { // match_offset=292 args->data=0x555e09574380 args->string.length=19 args->data_base=0xc00 args->data_size=1024 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=130 += 0
--
+ _yr_scan_match_callback(match_data=0x555e0957488c match_length=0) { // match_offset=268 args->data=0x555e09574780 args->string.length=19 args->data_base=0x1000 args->data_size=1024 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=168 += 0
--
+ _yr_scan_match_callback(match_data=0x555e09574c74 match_length=0) { // match_offset=244 args->data=0x555e09574b80 args->string.length=19 args->data_base=0x1400 args->data_size=1024 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=206 += 0
--
+ _yr_scan_match_callback(match_data=0x555e0957505c match_length=0) { // match_offset=220 args->data=0x555e09574f80 args->string.length=19 args->data_base=0x1800 args->data_size=239 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // matches_list->count=244 += 0

Why is the find count not incremented? Because _yr_scan_add_match_to_list() checks to see if the found string address is a duplicate of a previously found string address. Unfortunately, the string address recorded is the offset within a block, so if you have multiple blocks and a string is found in block A at offset 123 and a different string is found in block B at offset 123, then the different string will get ignored, as can be seen in the shorted code:
static int _yr_scan_add_match_to_list(
    YR_MATCH* match,
    YR_MATCHES* matches_list,
    int replace_if_exists)
{
...
  YR_MATCH* insertion_point = matches_list->tail;
...
  while (insertion_point != NULL)
  {
    if (match->offset == insertion_point->offset) // <-- offset in each block is not unique!
    {
...
      goto EARLY_OUT;
    }

    if (match->offset > insertion_point->offset)
      break;

    insertion_point = insertion_point->prev;
  }
...
  matches_list->count++;
...
  EARLY_OUT:;
  if (yr_test_verbosity)
    fprintf(stderr, "+ %s(replace_if_exists=%d) {} = %d // matches_list->count=%'u += %'u\n", __FUNCTION__, replace_if_exists, result, count_orig, matches_list->count - count_orig);
  return result;
}

Do you guys like the idea of leveraging the existing tests to check that everything is working for both cases; "a single block" and "two or more blocks"? If so, what would be a good way to get the existing code detecting strings which straddle two or more blocks? Or does it do that already somehow, but I just didn't use it properly?
[1] https://yara.readthedocs.io/en/stable/writingmodules.html#accessing-the-scanned-data
[2] https://github.com/simonhf/yara/tree/test-base-and-offset

Update: I believe I managed to fix the issue regarding offset collision in _yr_scan_add_match_to_list() when multiple memory blocks are used and this is commited to my YARA branch [1].
When re-running the regular YARA tests without the multiple memory block mode then everything still works:
$ rm test-rules.log ; make check YR_TEST_MEM_BLOCK_SIZE=0 YR_TEST_VERBOSITY=0 ; echo "test-rules.log:" ; cat test-rules.log
...
PASS: test-arena
PASS: test-alignment
PASS: test-atoms
PASS: test-api
PASS: test-rules
PASS: test-pe
PASS: test-elf
PASS: test-version
PASS: test-bitmask
PASS: test-math
PASS: test-stack
PASS: test-re-split
PASS: test-exception
...
test-rules.log:
+ test_boolean_operators() {}
+ test_comparison_operators() {}
+ test_arithmetic_operators() {}
+ test_bitwise_operators() {}
+ test_matches_operator() {}
+ test_syntax() {}
+ test_anonymous_strings() {}
+ test_strings() {}
+ test_wildcard_strings() {}
+ test_hex_strings() {}
+ test_count() {}
+ test_at() {}
+ test_in() {}
+ test_offset() {}
+ test_of() {}
+ test_for() {}
+ test_re() {}
+ test_filesize() {}
+ test_include_files() {}
+ test_comments() {}
+ test_modules() {}
+ test_integer_functions() {}
+ test_entrypoint() {}
+ test_global_rules() {}
+ test_tags() {}
+ test_process_scan() {}
+ test_hash_module() {}
+ test_time_module() {}
+ test_performance_warnings() {}
- // re-run the string tests but split the data into blocks of max 0 bytes (0 means single and unlimited block size and is the default)
+ test_strings() {}
PASS test-rules (exit status: 0)

When re-running the regular YARA tests with the multiple memory block mode then the number of missing matches decreases, as expected, from 12 to only 6; so now there are 249 matches found for the failing test instead of 244 in the last comment:
$ rm test-rules.log ; make check YR_TEST_MEM_BLOCK_SIZE=1024 YR_TEST_VERBOSITY=1 ; echo "test-rules.log:" ; cat test-rules.log
...
- match_table[state=2048]=1 i=224 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
+ yr_scan_verify_match(data=0x556661cdff80 data_size=239 data_base=0x1800 offset=220)
+ _yr_scan_verify_literal_match(data=0x556661cdff80 data_size=239 data_base=0x1800 offset=220) {}
+ _yr_scan_xor_compare(data_size=19 string_length=19) {} = 19
+ _yr_scan_match_callback(match_data=0x556661ce005c match_length=0) { // match_offset=220 args->data=0x556661cdff80 args->string.length=19 args->data_base=0x1800 args->data_size=239 args->forward_matches=19
+ _yr_scan_add_match_to_list(replace_if_exists=0) {} = 0 // match->base=0x1800 match->offset=220 matches_list->count=249 += 1
} // _yr_scan_match_callback() = 0
- match_table[state=517]=0 i=225 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=635]=0 i=226 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=636]=0 i=227 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=626]=0 i=228 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=637]=0 i=229 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=636]=0 i=230 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=577]=0 i=231 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=628]=0 i=232 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=517]=0 i=233 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=573]=0 i=234 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=577]=0 i=235 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=627]=0 i=236 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=627]=0 i=237 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
- match_table[state=626]=0 i=238 block_data=0x556661cdff80 block->base=0x1800 // _yr_scanner_scan_mem_block()
+ _yr_test_mem_block_size_get_next_block() {} // .base=0x18ef of 0x18ef or 6383 .size=0 AKA block end
+ yr_scanner_destroy() {}
tests/test-rules.c:572: rule does not match contents of'tests/data/xor.out' (but should)
FAIL test-rules (exit status: 1)

I'm guessing this bug had the potential to wrongly ignore a match when scanning multiple blocks of a process because processes currently can dish up multiple memory blocks to scan?
Now, I'm wondering how best to fix the remaining issue: How to detect matches straddling memory blocks? Any ideas?
[1] https://github.com/simonhf/yara/commit/7bbe51405e1b3775fe3cd338389f48149b585cc3

The collision in _yr_scan_add_match_to_list is actually a bug, two matches at the same offset but IN different blocks should be considered different matches, if you have a fix for that please send the PR and I'll be happy to merge it.
Regarding matches that span multiple blocks it is working as expected. Blocks are treated as completely independent pieces of data and YARA doesn't expect them to be contiguos. The blocks logic was designed with memory scan in mind, where each block is an area of virtual memory that are generally non-contiguos. So, you shouldn't use blocks in order to break a larger chunk of memory in pieces that you expect to be handled as a unit. If you do that, you should use blocks as large as possible and ideally with some overlap in order to mitigate this issue.

Thanks. Okay, sounds good.
I re-implemented my branch multiple block test code to work with 1,024 byte blocks with a 256 byte overlap and this got the above test to pass, and a bunch more tests after that. Using the test instrumentation, here we can see the YARA test on its 6,383 byte memory block which is divided up into 1,024 sized memory blocks but with a 256 byte overlap:

Base of the 1st block is 0x0 and length 1,024, i.e. no overlap.
Base of the 2nd block is 0x300 (768 = 1,024 - 256) and length 1,280 (1,024 + 256), i.e. 256 bytes overlap included from now on.
Base of the 7th and last block is 0x1700 (5,888 = (1,024 * 6) - 256) and length 495 (495 = 6,383 - (1,024 * 6) + 256).

$ cat test-rules.log | egrep _yr_test_mem_block_size_get_next_block | tail -8
+ _yr_test_mem_block_size_get_next_block() {} = 0x7ffd43da1000 // .base=(0x0 or 0) of (0x18ef or 6383) .size=1024, both including 0 block overlap (note: 1st block overlap always 0)
+ _yr_test_mem_block_size_get_next_block() {} = 0x7ffd43da1000 // .base=(0x300 or 768) of (0x18ef or 6383) .size=1280, both including 256 block overlap
+ _yr_test_mem_block_size_get_next_block() {} = 0x7ffd43da1000 // .base=(0x700 or 1792) of (0x18ef or 6383) .size=1280, both including 256 block overlap
+ _yr_test_mem_block_size_get_next_block() {} = 0x7ffd43da1000 // .base=(0xb00 or 2816) of (0x18ef or 6383) .size=1280, both including 256 block overlap
+ _yr_test_mem_block_size_get_next_block() {} = 0x7ffd43da1000 // .base=(0xf00 or 3840) of (0x18ef or 6383) .size=1280, both including 256 block overlap
+ _yr_test_mem_block_size_get_next_block() {} = 0x7ffd43da1000 // .base=(0x1300 or 4864) of (0x18ef or 6383) .size=1280, both including 256 block overlap
+ _yr_test_mem_block_size_get_next_block() {} = 0x7ffd43da1000 // .base=(0x1700 or 5888) of (0x18ef or 6383) .size=495, both including 256 block overlap
+ _yr_test_mem_block_size_get_next_block() {} = (nil) // .base=(0x1b00 or 6912) of (0x18ef or 6383) .size=1280, both including 256 block overlap

However, a later test is now failing and I'm investigating that. It doesn't seem to be failing because the 256 overlap is too small, so it might be another small bug. Will report what I find.
My intention is to fix any remaining issues and submit a PR fixing the first bug found, introduce testing for scanning of multiple blocks which works with all existing test_strings() tests, as well as fixing any remaining issues.

I managed to get test-rules.c running all tests both with and without multiple blocks, and both without error, and optional test debug instrumentation [1].
By default, YARA can be built and tested as usual and with the usual output, but test-rules is testing with and without multiple blocks under the covers, and test debug instrumentation is compiled out / away:
$ make clean ; make -j `nproc` check ; echo "test-rules.log:" ; cat test-rules.log
...
PASS: test-alignment
PASS: test-arena
PASS: test-atoms
PASS: test-version
PASS: test-bitmask
PASS: test-re-split
PASS: test-stack
PASS: test-math
PASS: test-api
PASS: test-elf
PASS: test-pe
PASS: test-exception
PASS: test-rules
...
test-rules.log:
PASS test-rules (exit status: 0)

It's also possible to build YARA with the test debug instrumentation compiled in but disabled at run-time:
$ make clean ; make -j `nproc` check CC="gcc -DYR_TEST_VERBOSITY=2" YR_TEST_VERBOSITY=0 ; echo "test-rules.log:" ; cat test-rules.log
...
PASS: test-alignment
PASS: test-arena
PASS: test-atoms
PASS: test-version
PASS: test-bitmask
PASS: test-re-split
PASS: test-stack
PASS: test-math
PASS: test-api
PASS: test-elf
PASS: test-pe
PASS: test-exception
PASS: test-rules
...
test-rules.log:
PASS test-rules (exit status: 0)

It's also possible to build YARA with the test debug instrumentation compiled in but enabled for verbosity level 1 at run-time, which shows some high level info about what is happening for test-rules:
Note: The number of first and next blocks is also counted and tested to ensure that the second pass of the rules is actually exercising multiple blocks. Below, the first pass of test rules uses 1,157 calls to first and next block, while the second pass uses 1,876 calls to first and next block.
$ make clean ; make -j `nproc` check CC="gcc -DYR_TEST_VERBOSITY=2" YR_TEST_VERBOSITY=1 ; echo "test-rules.log:" ; cat test-rules.log
...
PASS: test-alignment
PASS: test-arena
PASS: test-atoms
PASS: test-version
PASS: test-bitmask
PASS: test-re-split
PASS: test-stack
PASS: test-math
PASS: test-api
PASS: test-elf
PASS: test-pe
PASS: test-exception
PASS: test-rules
...
test-rules.log:
- // run all rule tests: pass 1: split data into blocks of max 0 bytes (0 means single / unlimited block size; default) with 0 bytes overlapping the previous block
+ test_boolean_operators() {}
+ test_comparison_operators() {}
+ test_arithmetic_operators() {}
+ test_bitwise_operators() {}
+ test_matches_operator() {}
+ test_syntax() {}
+ test_anonymous_strings() {}
+ test_strings() {}
+ test_wildcard_strings() {}
+ test_hex_strings() {}
+ test_count() {}
+ test_at() {}
+ test_in() {}
+ test_offset() {}
+ test_length() {}
+ test_of() {}
+ test_for() {}
+ test_re() {}
+ test_filesize() {}
+ test_include_files() {}
+ test_comments() {}
+ test_modules() {}
+ test_integer_functions() {}
+ test_entrypoint() {}
+ test_global_rules() {}
+ test_tags() {}
+ test_process_scan() {}
+ test_hash_module() {}
+ test_time_module() {}
+ test_performance_warnings() {}
- // yr_test_count_get_block=1157 is the number of times the above tests got a first or next block
- // run all rule tests: pass 2: split data into blocks of max 1024 bytes (0 means single / unlimited block size; default) with 256 bytes overlapping the previous block
+ test_boolean_operators() {}
+ test_comparison_operators() {}
+ test_arithmetic_operators() {}
+ test_bitwise_operators() {}
+ test_matches_operator() {}
+ test_syntax() {}
+ test_anonymous_strings() {}
+ test_strings() {}
+ test_wildcard_strings() {}
+ test_hex_strings() {}
+ test_count() {}
+ test_at() {}
+ test_in() {}
+ test_offset() {}
+ test_length() {}
+ test_of() {}
+ test_for() {}
+ test_re() {}
+ test_filesize() {}
+ test_include_files() {}
+ test_comments() {}
+ test_modules() {}
+ test_integer_functions() {}
+ test_entrypoint() {}
+ test_global_rules() {}
+ test_tags() {}
+ test_process_scan() {}
+ test_hash_module() {}
+ test_time_module() {}
+ test_performance_warnings() {}
- // yr_test_count_get_block=1876 is the number of times the above tests got a first or next block
PASS test-rules (exit status: 0)

It's also possible to build YARA with the test debug instrumentation compiled in but enabled for verbosity level 2 at run-time, which produces 190,118 lines of debug output:
$ make clean ; make -j `nproc` check CC="gcc -DYR_TEST_VERBOSITY=2" YR_TEST_VERBOSITY=2 ; echo "test-rules.log:" ; cat test-rules.log | tail -2 ; cat test-rules.log | wc -l
...
PASS: test-alignment
PASS: test-arena
PASS: test-atoms
PASS: test-version
PASS: test-bitmask
PASS: test-re-split
PASS: test-stack
PASS: test-math
PASS: test-api
PASS: test-elf
PASS: test-pe
PASS: test-exception
PASS: test-rules
...
test-rules.log:
- // yr_test_count_get_block=1876 is the number of times the above tests got a first or next block
PASS test-rules (exit status: 0)
190118

So this could be my PR unless there's some changes you'd like?
[1] https://github.com/simonhf/yara/commit/621ee3361b338a45bdc2ac3a7f010129cbf892f5

I've added a few comments in your branch. Basically I would want to separate all testing-related code from libyara's code. Global variables and functions that are used only for testing should not be declared anywhere in libyara, they should appear somewhere in the tests directory.

Thanks very much for adding the comments. I'll take a look... :-)

Based upon the comments then I made the following changes:

Move test globals and test get first/next/data block functions into tests/util.c.
Make yr_rules_scan_mem() indirect so it can be overridden at run time by tests.
Rename YR_TEST_FPRINTF() to YR_DEBUG_FPRINTF() because it straddles production and test code.
Build and run is as in my last comment, except YR_TEST_VERBOSITY is now YR_DEBUG_VERBOSITY.

Anymore comments to the code [1] before I submit the PR?
[1] https://github.com/simonhf/yara/commit/597990951cd23d5318c9cd882b04ed5a500969eb

Hmmm... pull request is passing Linux Travis build but not macOS because clang is throwing a spanner in the works, and I'm not sure why. Will have to meditate on this.


Fix missing spaces around link

Docs Build status updates of commit ed67c5d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-conceptual/azureadps-2.0-preview/install-adv2.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit ed67c5d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-conceptual/azureadps-2.0-preview/install-adv2.md
:bulb:Suggestion

Details

docs-conceptual/azureadps-2.0-preview/install-adv2.md

Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Load list of steps from cluster

Instead of using a remote catalog, just read the kamelets from the cluster, if a cluster is available.

https://github.com/KaotoIO/kaoto-backend/pull/83


Fix publisher

LGTM - I'll look into what's going wrong with the boilerplate check and handle that separately.


fix:#342 #340 :responsive cards and project bookmarkinh

created responsive cards and project bookmarking

@nidhi-badiger The web app crashes on /projects route. I will be closing this PR. Thankyou for your feature.


Create a RxJournal specific directory + clearCache only deletes .cq4

This commit limits the destructive potential of clearCache by

using the directory from the constructor as a base directory, and
creating a specific directory inside it for ChronicleQueue files
limiting the deletion done by clearCache to .cq4 files inside that
directory (just in case some other files have been created manually
there)

Fixes #2

Thx! Hope this is the first of many contributions you can make to this library ;)


browser.newPage() is blocked with puppeteer.connect()

Steps to reproduce
Tell us about your environment:

Puppeteer version: 0.13 + current master branch
Platform / OS version: Debian Stretch
Uses chrome headless from Docker

What steps will reproduce the problem?
/* eslint-disable no-console, filenames/match-regex, import/no-commonjs */

/**
 * @file Ensure that Chrome can properly start and close.
 */
const puppeteer = require('puppeteer');

const test = async () => {
  console.log('Testing if Chrome works');

  const browser = await puppeteer.connect({
    browserWSEndpoint: 'ws://<IP_ADDRESS>:9222/devtools/browser/36b65179-51a0-402b-9dd4-096c808a67c7'
  });
  console.log('Hello! 1');

  const page = await browser.newPage();
  console.log('Hello! 2');

  const navigationPromise = page.waitForNavigation();
  console.log('Hello! 3');

  await page.goto('http://perdu.com/');
  console.log('Hello! 4');

  await navigationPromise;
  console.log('Hello! 5');

  console.log(await page.content());
  console.log('Hello! 6');

  await browser.close();

  console.log('Chrome is working expected.');
};

test();

What is the expected result?
Like in 0.10.0
Testing if Chrome works
Hello! 1
Hello! 2
Hello! 3
Hello! 4
Hello! 5
<title>Vous Etes Perdu ?</title>
Perdu sur l'Internet ?

Pas de panique, on va vous aider

    * <----- vous êtes ici

Hello! 6
Chrome is working expected.

What happens instead?
Testing if Chrome works
Hello! 1

And the process is blocked...

+1 same issue with latest chrome stable (tried on latest canary chromium too) launched on headless, on Ubuntu 16.04. Note that it works fine with puppeteer 0.12.0.

I've got 0.13.0 on windows, It works fine for me.

I have tried with puppeteer 1.0.0-rc (Chromium r515411) on Windows 7 x64 and this code and the output is OK:

Label (click me):
'use strict';

const puppeteer = require('puppeteer');

(async function main() {
  try {
    const prelaunched = await puppeteer.launch();

    console.log('Testing if Chrome works');

    const browser = await puppeteer.connect({
      browserWSEndpoint: prelaunched.wsEndpoint(),
    });
    console.log('Hello! 1');

    const page = await browser.newPage();
    console.log('Hello! 2');

    const navigationPromise = page.waitForNavigation();
    console.log('Hello! 3');

    await page.goto('http://perdu.com/');
    console.log('Hello! 4');

    await navigationPromise;
    console.log('Hello! 5');

    console.log(await page.content());
    console.log('Hello! 6');

    await browser.close();

    console.log('Chrome is working expected.');
  } catch (err) {
    console.error(err);
  }
})();

I tried this with Puppeteer 0.13.0 on Windows 10 x64 and it works for me.

I have also been looking for a workaround to this behavior. I'm using puppeteer 0.13.0 on a Raspberry Pi (armhf) so I cannot use the x86_64 chromium that comes with puppeteer. In the puppeteer package.json for 0.13.0 it lists chromium revision 515411. I tried looking for that version of chromium but I am not sure how to find a chromium version by its revision number. Anyone have a tip? I tried installing several different recent versions from launchpad but so far nothing has resolved this newPage issue for me.

It fails too in Ubuntu 16.04 with:

Google Chrome 62.0.3202.94
Chromium 62.0.3202.94

Still happening, anyone have a workout other than reverting puppeteer version?

@miles-collier it works but only with chrome shipped in puppeteer.
I have a dirty script:
#!/bin/sh

HEADLESS="--headless"

if [ -n "$1" ];
then
	HEADLESS=""
fi

./node_modules/puppeteer/.local-chromium/linux-*/chrome-linux/chrome $HEADLESS --no-sandbox --no-first-run --no-default-browser-check --remote-debugging-port=9222 --disable-gpu --incognito --user-data-dir=$(mktemp -d  -t 'chrome-remote_data_dir-XXXXXXXXXXXXXXXXXXXXXx')

To be clear, reverting to 0.10.0 allows you guys to run require('puppeteer').launch().then(_=_.newPage()) ? For me no matter what version I use I get the same never resolving promise....

How can I try an older version of pptr? I would like to try out v1.2.0.

@yijiem you can install specific version using npm install<EMAIL_ADDRESS>


CI for Node

Waiting on tests
Great! Now that the testing framework is properly configured, we should get a response from it soon. This time, you'll practice reading the logs on your own. Just like before, you can follow along as GitHub Actions runs your job by going to the Actions tab or by clicking on "Details" in the merge box below.
When the tests finish, you'll see a red X ❌ or a green check mark ✔ in the merge box. At that point, you'll have access to logs for the build job and its associated steps.
Step 4: Read an Actions log
By looking at the logs, can you identify which tests failed? To find it, go to one of the failed builds and scrolling through the log. Look for a section that lists all the unit tests. We're looking for the name of the test with an "x".

⌨ Activity: Tell the bot which test is failing so we can fix it

Navigate to the log output
Identify a name of a failing test
Comment the name of the failing test here

I'll respond when you enter the name of at least one failing test. You can either copy and paste that portion of the log directly, or type the name of the test as a comment.

FAIL test/game.test.js
App
✕ Contains the compiled JavaScript (4 ms)


runtime: removing envoy.reloadable_features.allow_upstream_filters

Risk Level: Medium (lots of code sites)
Testing: n/a
Docs Changes: n/a
Release Notes: inline
Fixes https://github.com/envoyproxy/envoy/issues/26898

/retest


Add external className to UniversalLink for external link.

@iFlameing I will check this today.

@iFlameing @davisagli I've found out that the publicURL was not set in the Jest setup fixtures, I added it and updated all related tests, now http://localhost:3000 will be treated as internal (as it is in runtime).


coredump with "Address out of bounds at sds.h:87"

Hi, I've used hiredis 0.14 in my c++ program on centos. The machine info is
[xiejiancong@client-nlp-240-159 lib]$ cat /proc/version
Linux version 4.9.0 (root@l22-240-159) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Fri Jan 20 15:36:24 CST 2017
And the coredump stack is as following. Is anyone know what it is? I rebuilt the hiredis with noopt version.
(gdb) bt
#0  0x00007fb736a6a4d4 in sdslen (s=0x0) at sds.h:87
#1  0x00007fb736a6b442 in sdscatlen (s=0x0, t=0x1ade8fc0, len=190) at sds.c:377
#2  0x00007fb736a6a0b4 in redisAppendCommand (c=0x4c4dc0c,
cmd=0x1ade8fc0 "*9\r\n$4\r\nMGET\r\n$15\r\naee_10001-38608\r\n$15\r\naee_10001-38599\r\n$15\r\naee_10001-38612\r\n$15\r\naee_10001-38611\r\n$15\r\naee_10001-38486\r\n$15\r\naee_10001-38610\r\n$15\r\naee_10001-38609\r\n$15\r\naee_10001-38600\r\n", len=190)
at hiredis.c:896
#3  0x00007fb736a6a1c2 in redisvAppendCommand (c=0x4c4dc0c,
format=0x1ade8dd8 "MGET aee_10001-38608 aee_10001-38599 aee_10001-38612 aee_10001-38611 aee_10001-38486 aee_10001-38610 aee_10001-38609 aee_10001-38600 ", ap=0x7ffd34d4b670) at hiredis.c:928
#4  0x00007fb736a6a3ac in redisvCommand (c=0x4c4dc0c,
format=0x1ade8dd8 "MGET aee_10001-38608 aee_10001-38599 aee_10001-38612 aee_10001-38611 aee_10001-38486 aee_10001-38610 aee_10001-38609 aee_10001-38600 ", ap=0x7ffd34d4b670) at hiredis.c:989
#5  0x00007fb736a6a46b in redisCommand (c=0x4c4dc0c,
format=0x1ade8dd8 "MGET aee_10001-38608 aee_10001-38599 aee_10001-38612 aee_10001-38611 aee_10001-38486 aee_10001-38610 aee_10001-38609 aee_10001-38600 ") at hiredis.c:997
#6  0x0000000000541625 in index_service::CallData::EEScoreRetrieval (this=0x1ad8a5f0, biztypes=0x1ad8a5f0, bizids=0x1ad8a6e0,
number=8, prefix=0x591e87 "aee", indexitems=0x1ad8a9b0) at calldata.cpp:692
#7  0x0000000000542d53 in index_service::CallData::HandleRequest (this=0x1ad8a5f0, searcher=..., request=...,
items_ptr=0x1ade68f0, deviceid="E47167379FE87FDA15F9D664287C3B82D70E5AC4", itemdq_size=1000, msg_obj=...) at calldata.cpp:1002
#8  0x00000000005438af in index_service::CallData::Proceed (this=0x1ad8a5f0, searcher=...) at calldata.cpp:1112
#9  0x0000000000547d73 in index_service::IndexServerImpl::HandleEventLoop (this=0x7ffd34d4c7c0, searcher=...)
at index_server.cpp:209
#10 0x0000000000547ac1 in index_service::IndexServerImpl::Run (this=0x7ffd34d4c7c0) at index_server.cpp:172
#11 0x000000000054ae12 in main (argc=7, argv=0x7ffd34d4d578) at index_main.cpp:49

Your string is NULL:
// s = 0x0
#0 0x00007fb736a6a4d4 in sdslen (s=0x0) at sds.h:87
#1 0x00007fb736a6b442 in sdscatlen (s=0x0, t=0x1ade8fc0, len=190) at sds.c:377

Then sdslen attempts to do this:
unsigned char flags = s[-1];

Resulting in your bad access.
I don't know why your string is NULL but having seen this issue before I have a guess.  If you're trying to share multiple redisContext structs between threads it could cause an issue like that, and it's also possible for NULL to be returned in an OOM situation but hiredis typically handles that gracefully (by immediately aborting).
I'd try running my program under Valgrind or ASAN (clang's Address Sanitizer) and see if it gives you a hint.

@Jiancong Were you able to find the problem?  I'm going to close this issue because I don't think it's a bug in hiredis but I can help you track it down with more information.


rdfind: 1.3.4 → 1.3.5

Motivation for this change
Version bump
Contains bug fixes
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

$ ./result/bin/rdfind --version
This is rdfind version 1.3.5

$ ./result/bin/rdfind -n true ~
(DRYRUN MODE) Now scanning "/home/demo", found 17209 files.
(DRYRUN MODE) Now have 17209 files in total.
(DRYRUN MODE) Removed 0 files due to nonunique device and inode.
(DRYRUN MODE) Now removing files with zero size from list...removed 15 files
(DRYRUN MODE) Total size is 443763317 bytes or 423 MiB
(DRYRUN MODE) Now sorting on size:removed 2470 files due to unique sizes from list.14724 files left.
(DRYRUN MODE) Now eliminating candidates based on first bytes:removed 13304 files from list.1420 files left.
(DRYRUN MODE) Now eliminating candidates based on last bytes:removed 351 files from list.1069 files left.
(DRYRUN MODE) Now eliminating candidates based on md5 checksum:removed 115 files from list.954 files left.
(DRYRUN MODE) It seems like you have 954 files that are not unique
(DRYRUN MODE) Totally, 39 MiB can be reduced.
(DRYRUN MODE) Now making results file results.txt

Rebased to master in a66f1d6047cefd2ea0eb73a1e58d5f93f85e9b50. Thanks!


CI failures

There are a few test failures on master that I came across in  #33 and thought it was worth opening up a separate issue.
The test failures are due to a ChildProcessError.

        This can be run from any process.  Usually a child process will use
        the semaphore created by its parent.'''
        with self._lock:
            if self._pid is not None:
                # semaphore tracker was launched before, is it still running?
>               pid, status = os.waitpid(self._pid, os.WNOHANG)
E               ChildProcessError: [Errno 10] No child processes

../../miniconda/envs/quansight/lib/python3.6/multiprocessing/semaphore_tracker.py:46: ChildProcessError

Unfortunately I don't have much insight to share here.  This probably requires some investigation.

@TomAugspurger commented in #31 that it has something to do with a new xgboost update making it incompatible.


Argument to specify frequency source

Would be wonderful to be able to get frequencies for the different sources!

This would be nice, but one thing that makes wordfreq particularly useful and accessible is that it fits in a PyPI package. There isn't room to store 7 different frequencies per word, so I don't think this can be solved within the wordfreq package.
https://github.com/LuminosoInsight/exquisite-corpus contains the process that processes the data for each corpus, though in one case it relies on a data set that can't be distributed (Twitter). I would like to think about how to make the complete results of this build more accessible, even if it can't appear in wordfreq.


added cd writy in readme

@Nisarga-Developer Thank you so much 🙏

@Nisarga-Developer Thank you so much 🙏

You're welcome :)


OGC Preview web application

Discover, browse and export data from OGC service layers exposed by way of WMS/WFS service interfaces, with a special focus given to time-enabled data. Defaults to using an existing install of the GeoServer package in a previous pull request. Install settings can be provided to point app at an externally hosted GeoServer, as well.

@gisjedi sorry it took us that long but we're in the middle of a transition to a new version. Can I please ask you to re-submit this PR in ca. one week time once we've the new version of the Universe in place? If you've got any questions, happy to discuss it via http://chat.dcos.io


Getting this Error with any Mod I try to use

Every time I try using a function from a mod I get errors like this. This error was when I only had Autocollect mod in my mod folder. Game would crash if I went over a item. Another Example was when i tried the NPC avatar Map mod and the game would crash with a similar error.
ive tried completely redoing the adding mod process several times but have had no luck getting any mod to work
2:15 AM - <IP_ADDRESS>78 MODDED ST Save:Slot1_Autosave - Game Runtime: 00:00:27.6167219 - GP Y1S2D1 - 2:27pm - Logs:141
Current map is Willowdown Farm | Y1 | S2 | D1 | H14
Player is  at {X:5329 Y:2509 Width:128 Height:128}
Method TopDownEditor.TopDownMap.RemoveDynamicGameObject(TopDownEditor.ScriptableGameObject)' is inaccessible from method Fertilizer.Template.InventoryPatch.Postfix(TopDownEditor.PickupableObject,bool)'
at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_throw_method_access(intptr,intptr)
at Fertilizer.Template.InventoryPatch.Postfix (PickupableObject __instance, System.Boolean ___playerInPickupRange) [0x0002c] in :0
at (wrapper dynamic-method) PickupableObject.PickupableObject.Update_Patch1(PickupableObject)
at GameStatePlayGame.UpdateGameObjects () [0x00313] in :0
at GameStatePlayGame.Update (Microsoft.Xna.Framework.GameTime gameTime, MonoProtoFramework.BaseGame game) [0x00a35] in :0
at MonoProtoFramework.BaseGame.Update (Microsoft.Xna.Framework.GameTime gameTime) [0x005b2] in <98305055abd8475e8e791a39cb80d038>:0
at Microsoft.Xna.Framework.Game.DoUpdate (Microsoft.Xna.Framework.GameTime gameTime) [0x00019] in <115d97b957eb41cabade1b29d1e7edf4>:0
at Microsoft.Xna.Framework.Game.Tick () [0x00127] in <115d97b957eb41cabade1b29d1e7edf4>:0
at MonoGame.Framework.WinFormsGameWindow.TickOnIdle (System.Object sender, System.EventArgs e) [0x00014] in <115d97b957eb41cabade1b29d1e7edf4>:0
at System.Windows.Forms.Application+ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.FDoIdle (System.Int32 grfidlef) [0x0001a] in :0
at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop (System.IntPtr dwComponentID, System.Int32 reason, System.Int32 pvLoopData) [0x00243] in :0
at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner (System.Int32 reason, System.Windows.Forms.ApplicationContext context) [0x00282] in :0
at System.Windows.Forms.Application+ThreadContext.RunMessageLoop (System.Int32 reason, System.Windows.Forms.ApplicationContext context) [0x0001a] in :0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.Application+ThreadContext.RunMessageLoop(int,System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x0000d] in :0
at MonoGame.Framework.WinFormsGameWindow.RunLoop () [0x00011] in <115d97b957eb41cabade1b29d1e7edf4>:0
at MonoGame.Framework.WinFormsGamePlatform.RunLoop () [0x00000] in <115d97b957eb41cabade1b29d1e7edf4>:0
at Microsoft.Xna.Framework.Game.Run (Microsoft.Xna.Framework.GameRunBehavior runBehavior) [0x0008b] in <115d97b957eb41cabade1b29d1e7edf4>:0
at Microsoft.Xna.Framework.Game.Run () [0x0000c] in <115d97b957eb41cabade1b29d1e7edf4>:0
at Program.Main () [0x00037] in :0
Graphics device info: AMD Radeon Graphics (RADV VANGOGH)

What OS are you using? Mods do not really work on Linux/SteamDeck because Mono's runtime is too outdated.

Ah damn, that would explain it. Yeah I’m using a steam deck but I have kynseed running using proton instead of standard Linux
I also set up the fertiliser and got the pop up saying the game is patched so I thought it may of worked.

Yeah, doesn't really matter. Unless you're somehow managing to install and run it using a recent-ish mono/dotnet, there's not a lot that can be done. The game has much of the code internal'd, which mods bypass with a trick. This trick is convenient to use, but does not work with the mono that Steam uses on Linux.


fix(tablet): set rows grid to 0 if it's empty (e.g. no toc section)

on tablet, the screen is split into 4 grid areas: if there's no automatic TOC generated, which takes up the top right corner, and the content doesn't fill up the screen, the content ends up in the bottom left corner. If we add a minmax to the grid rows, with a min of 0 and a max of auto, it should sort itself out better.

After:

Before Reported by @zhming0:

Preview URL: https://f54a71181fe66bb4df3e9e5018b8ede93815833f--bk-docs-preview.netlify.app


indigo node: rename

Strat is now Indigo CLI.
Alice is now Indigo Node.
The generators need to adapt to these new names.
I did not fully E2E test the changes, but we'll fix issues as we use the generators (during deployment or before the next release).

This change is

Reviewed 42 of 42 files at r1.
Review status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @simonvadee)

Comments from Reviewable

Reviewed 42 of 42 files at r1.
Review status: :shipit: complete! all files reviewed, all discussions resolved

Comments from Reviewable


restocking simulater

Your checklist for this pull request
About your game
What is your game about?
restocking shelves
How to play your game?
wasd for player movement, ijkl for player2 movement, a+l for level reset

which of the two is the final version?

3134d1a

how to solve level 4?

I Need to upload commented version

how to solve level 4?

new version uploaded

but how do you solve level 4? I'm not getting past this level

but how do you solve level 4? I'm not getting past this level

What's your issue, can you not move the second character?

I just can't put all the boxes on the goals in this level:

I just can't put all the boxes on the goals in this level:

https://www.kapwing.com/videos/637e809a1ec3f200243bd10b

oh, ok, thanks!


Question about Readme

Hello,
I read the README. In the description about the "Realtime sound source localization and tracking", the third step said "upgrade your usb 4 mic array with i6_firmware.bin which includes 4 channels raw audio data." I wonder that the file "i6_firmware.bin" is referring to the file "6_channels_firmware.bin" in the master branch ? I can't download the file "i6_firmware.bin" by the URL on README.

Thank you so much. I try to use the file "6_channels_firmware.bin" to upgrade the firmware.

 My privacy has been violated my phone services stolen 9 phones broken from over heating or being thrown.  Oh believe me after being recorded my pics taken my privacy rights more than violated I didn't sign anything I didn't consent so before u change meeting me I'd suggest u repent. Im getting a lawyer & im coming after u & every person involved I've got diabetes so bad they took me off work to reduce stress while my husband & a whore chose to search on pinterest for foods that contain sulfa to which im deathly allergic.   Sad to think someone could hate me that much or make it look like my husband did it I no longer care who did if it all goes away if it doesn't im on the verge of a psychotic snap & my hubby's in prison till 2027.  Over 2 years & finally I can breathe and relax cuz if it don't get taken down


Additional visualizations from Eric

https://observablehq.com/@analyzer2004
https://twitter.com/analyzer2004/status/1397759058799599627?s=21

I would start with:
https://observablehq.com/@analyzer2004/waffle-chart?collection=@analyzer2004/business-data-storytelling

https://observablehq.com/@observablehq/state-of-dataviz-2021

https://observablehq.com/@analyzer2004/funnel-chart?collection=@analyzer2004/business-data-storytelling

https://observablehq.com/@analyzer2004/fancy-radial-bars?collection=@analyzer2004/business-data-storytelling

https://observablehq.com/@analyzer2004/3d-clustered-chart?collection=@analyzer2004/three-js


px4fmu-v4:SPI and init clean up

This is a clean up of the SPI chip select handling. It was very broken.

@scheiermanns, @pkocmoud would you please test this, and verify that all the sensors start.

Tested on Pixracer and Boschracer.


Do LocalForms make use of the same middleware as the rest of app

The Problem
I am trying to convert a working Form to a LocalForm and cannot get it to dispatch my submit action. This action is handled by redux-axios-middleware but when I run the same code in LocalForm it just doesnt get a promise back.
Steps to Reproduce
My onSubmit in both forms is
 handleSubmit (values) {

    this.formDispatch(actions.submit('subscribe', this.formDispatch(subscribeUser(values))))
    this.formDispatch(actions.reset('subscribe'))
  }

Note that the above works perfect with standard Form (using dispatch from props)
I load dispatch as in docs:
  getDispatch={(dispatch) => this.formDispatch = dispatch}

My subscriberUser is as follows:

eexport function subscribeUser (data) {
  return {
    type: 'SUBSCRIBE_FORM',
    payload: {
      options: {
     /   onSuccess: () => true
     / },
      request: {
        url: '/newsletter/subscribe',
        method: 'post',
        data: data
      }
    }
  }
}

Expected Behavior
I would expect dispatch(subscribeUser(values)) to return a promise which is what happens in <Form/> but in <LocalForm/> I just get the exact same object back untransformed as in:
console.log( this.formDispatch(subscribeUser(values)))
console.log( subscribeUser(values))
```
Both return the same action object.

I know that axios middleware watches actions and handles them to return a promise. I suspect that my LocalForm dispatch is not aware of this. Is this your assumption as well and can it be remedied?

They do not make use of the same middleware, as they use a separate internal Redux store instance (by design). In fact, in future versions (v2+) it's best to not even assume that <LocalForm> will use Redux at all.

Thanks David that helps. Perhaps a mention in the docs (if not already there - I may have missed it) would be useful.  It seems logical now that I think about it but I didn't think of it when I initially attempted my conversion.


GET /parse/users/me doesn't return token

Hi,
I am logging in an user with parse-server, then returning user.getSessionToken() to my client.
When using PFUser becomeInBackground providing token got from server, user successfully login, but [PFUser currentUser].sessionToken is null.
Could it be because of GET /parse/users/me doesn't return a sessionToken along with user ?
As seen with VERBOSE=1:
GET /parse/users/me { host: '...',
  accept: '*/*',
  'x-parse-session-token': 'r:27b08dbdcf8....',
  ...}
response: <A Parse user, without sessionToken, is this normal ?>

If that's normal, why my PFUser doesn't have sessionToken, which implies that it's not really logged (further request are sent without sessionToken) ?
Thanks

Yup, looks like a valid bug, we indeed don't send the session token back on /users/me, but we should to maintain compatibility with Parse.com and support all SDKs.
Fix is incoming.

Thanks @nlutsenko !
Why is it linked to compatibility with Parse.com ? It just prevents becomeInbackground to work correctly, doesn't it ?

SDKs expect certain things from Parse, and we are using Parse.com as a reference for things that exist in both locations (this might not be true in the future), so if Parse.com sends a token back on /login - this is what the SDKs would expect - meaning that we should maintain compatibility with both :P

Confirmed as fixed with #632 , thanks.


Change defaults (--keep, --older-than) and explain

Changes the defaults for the --keep and --older-than CLI options.
Explains the (default) values that are active when displaying results, which should make it easier to spot why in some cases there are unexpectedly few or many results.
Changes and aligns styling and wording on help screens.

Resolves: #22
Side Note: Next Release
After this PR is merged we should probably go about publishing a new release (and package it with the container-oc image). The latest release is more than a month ago, and there have been significant advancements in the meantime. :rocket:

Tests are failing, because we don't yet mock the namespace. When executed locally, all tests pass.

Tests are failing, because we don't yet mock the namespace. When executed locally, all tests pass.

The pipeline used to pass and now it doesn't. Why is that? I don' see any changes in the code that would impact the tests

Tests are failing, because we don't yet mock the namespace. When executed locally, all tests pass.

The pipeline used to pass and now it doesn't. Why is that? I don' see any changes in the code that would impact the tests

LOL The comment you quote explains it all. :rofl:
We could add the mocking of the Kubernetes namespace reference in this PR, too. That certainly makes sense. Do we have an example of how this is done in Go?

Tests are failing, because we don't yet mock the namespace. When executed locally, all tests pass.

The pipeline used to pass and now it doesn't. Why is that? I don' see any changes in the code that would impact the tests

The comment you quote explains it all. True, the changes that require the namespace value to be set are in an earlier commit (outside of the PR). Locally, ~/.kube/config is always present once you access a cluster.
We could add the mocking of the Kubernetes namespace reference in this PR, too. That certainly makes sense. Do we have an example of how this is done in Go?

That is the problem, as far as I know there's no mocking framework installed. I tried last time to add mocks but due to the way the code is written it makes it difficult to mock. There should be a research on how to implement that. I'm not sure if it's ok to pass this commit while the pipeline fails.

Affected code locations:

cmd/orphans_test.go – likely place that needs mocking of kubernetes.Namespace
cfg/types.go – actual call of kubernetes.Namespace()

@github Can you please fix your broken GitHub @Actions?  :bomb: :rocket: :face_with_head_bandage:

Closing this PR in favor of #27, since GitHub Actions has stopped to trigger, seemingly for GitHub infrastructure issues we're witnessing today.


Remove superceded personae tests

These were set up as an experiment in auto generating test personae.
They failed and should have been removed before now!

This looks great :+1: I'm not sure exactly about the reason, but deleting is the best, get it in!


Illegal interruption of a class constructor for CL_CI_CHECKVARIANT============CP

Hello,
after deserializing the demo package of https://github.com/SAP-samples/abap-platform-refscen-flight/tree/On-Premise-2020, several crash dumps of the same type are thrown and some objects are not activated.
Basic crash dump information:
Illegal interruption of a class constructor.
The current ABAP program "CL_CI_CHECKVARIANT============CP" had to be terminated because it found a statement that could not be executed.
During the class constructor flow for class "\CLASS=CL_CI_TEST_ROOT", a condition arose causing the class constructor to be left prematurely. This is not permitted because it results in an inconsistent state in the class.
Crash occurred in line 48 of function CREATE of class CL_CI_CHECKVARIANT.
I think this happens because /DMO/ is no registered namespace or because these objects are created by SAP and thus shouldn't/can't be checked by ATC.
Happened in abapGit v1.102 or v1.101 on NW 755.
Best Regards,

during deserialization? what is the stack trace? if I remember correctly, abapGit does not call any CI(code inspector) by default

Hi @larshp!
Yes, the objects were pulled from the mentioned Git repository and activated.
Active Calls/Events

No.   Ty.          Program                             Include                             Line
      Name

    1 EVENT        CL_CI_CHECKVARIANT============CP    CL_CI_CHECKVARIANT============CM002    48
      CREATE

Application Calls

Index Calls

    1 R=1 T=S S=<system_id> I=CL_CI_TESTS===================CP F=SCI_TESTS_VALIDATE C=100 U=<username>

I hope this helps, although it's quite less information. Do you refer to the ABAP Control Blocks (CONT) for this crash dump when you mean the stack trace?

if code inspector was run manually after abapGit deserialization, its really difficult to determine what is wrong and what/if to fix
need to be able to reproduce the error with a minimal example, providing the steps to reproduce
I personally do not have access to a S/4 2020 system that I can use for testing

and SAP has closed for issues in the repository, great

I asked my colleague: He didn't execute CI manually before or after abapGit deserialization. He just pulled the repository and then  the objects were automatically activated. Some objects were not successfully activated thus he activated them manually.

for the missing activation: suggest trying to reproduce the issue in a public repository, with minimal number of objects, and opening this as a separate issue

I think this was related to some coincident with a basis issues or something like that. I will close this for now as we can't reproduce or test this on our system right now. If this occurs again, I will reopen this issue and provide more details.


Fix Protractor tests for pattern fields

Fixes #516

Please make sure the below checklist is followed for Pull Requests.

[ ] Azure tests are green

[ ] Tests are added where necessary

[ ] Documentation is added/updated where necessary

[ ] Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

@kaidohallik : thanks so much for your help ! ❤


Only Showing One Project

Hi there. Great module! Love it! Only issue I'm having right now is that it is only displaying one project. I have copied over the project ID's (3 of 'em) but it will only show one. If I try each one individually, only one is displaying which is really weird. I know I'm copying the right project number: https://todoist.com/app#project%2F<this_number>%2Ffull
Any ideas on what could be wrong here? Thanks!

Hey,
I know this is a very old issue. Are you still having any problems?

All good now, thanks!


LDAP: support memberof attribute to synchronise groups

With https://github.com/opnsense/core/commit/1ddbb3bdbb2c895b4c224d39e16120d5db94bebf we are able to request user attributes after login, if the ldap (AD) server supports it, we can use this to synchronise groups after successful login.
In case of MS AD there's one small remark, the primary user group won't be reported (by default) in memberof. Use the authentication tester to test if your server supports the memberof attribute.

It seems I am unable to get nested groups which the user is member of.
As most Windows users follow AGDLP (Global group containing user, local group giving permission, global group added as member of local group) best practice this poses a problem.
Resolving nested groups should be possible using LDAP_MATCHING_RULE_IN_CHAIN (1.2.840.1135<IP_ADDRESS>1) in the search query.
For example:
To find all groups including nested which User1 is member of:
(member:1.2.840.1135<IP_ADDRESS>1:=CN=User1,OU=X,DC=domain,DC=com)
Or searching for all users including nested which are member of A Group:
(memberOf:1.2.840.1135<IP_ADDRESS>1:=CN=A Group,OU=Y,DC=domain,DC=com)
Could you please add a switch which allows selecting this behavior to include nested groups.

@ruffy91 this ticket is closed (we usually don't respond on closed tickets), feel free to open a new one with a feature request if there's something missing.I'm not sure you can easily return the nested attribute, you could try to fiddle a bit with the query settings and check the output in the tester tool.
The code responsible for reading the attributes is:
https://github.com/opnsense/core/blob/7218726f59c39cf6a76b0b2d09aa247d19f066c0/src/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php#L571-L586
If you can output the results in ldap_get_entries(), which also returns in the tester tool, it likely wouldn't be a huge issue to add the feature. A quick search online doesn't show a lot of functional examples.

The Cloud import button is missing after I added LDAP server (Zentyal, I can communicate with it):
Also I got this error, is it linked somehow?
[07-Oct-2019 16:24:01 Atlantic/Azores] PHP Warning:  implode(): Invalid arguments passed in /usr/local/www/system_authservers.php on line 249


heavy bugged on ubuntu 18.04

first of all not compatible with Berkeley DB 4.8.30
after compile with incompatible DBD and start with testnet the coind instant stopped on start.
next thing try´d with multiple ports to open rpc...didnt work
`2023-04-23 12:48:56
2023-04-23 12:48:56 Crionic Core version v<IP_ADDRESS>-c2ee1a8 (release build)
2023-04-23 12:48:56 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2023-04-23 12:48:56 Assuming ancestors of block 0000c4242ba924701e12487766fe9c141eb1ea9703c7e82ebedbd5b63ec28082 have valid signatures.
2023-04-23 12:48:56 Setting nMinimumChainWork=0000000000000000000000000000000000000000000000000000000000000000
2023-04-23 12:48:56 Using the 'sse4' SHA256 implementation
2023-04-23 12:48:56 Using RdRand as an additional entropy source
2023-04-23 12:48:56 Default data directory /bananajoe/.crionic
2023-04-23 12:48:56 Using data directory /bananajoe/.crionic/testnet4
2023-04-23 12:48:56 Using config file /bananajoe/.crionic/crionic.conf
2023-04-23 12:48:56 Using at most 12 automatic connections (1024 file descriptors available)
2023-04-23 12:48:56 Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2023-04-23 12:48:56 Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2023-04-23 12:48:56 Using 10 threads for script verification
2023-04-23 12:48:56 scheduler thread start
2023-04-23 12:48:56 libevent: getaddrinfo: address family for nodename not supported
2023-04-23 12:48:56 Binding RPC on address :: port 31556 failed.
2023-04-23 12:48:56 HTTP: creating work queue of depth 16
2023-04-23 12:48:56 Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcuser for rpcauth auth generation.
2023-04-23 12:48:56 HTTP: starting 8 worker threads
2023-04-23 12:48:56 Using wallet directory /root/.crionic/testnet4/wallets
2023-04-23 12:48:56 init message: Verifying wallet(s)...
2023-04-23 12:48:56 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2023-04-23 12:48:56 Using wallet wallet.dat
2023-04-23 12:48:56 CDBEnv::Open: LogDir=/root/.crionic/testnet4/wallets/database ErrorFile=/root/.crionic/testnet4/wallets/db.log
`

No more problems !!!!


mesa_hdf5_params.inc to be inlist file

Several parameters in mesa_hdf5_params.inc can have smart defaults (see _smart defaults for parameters _ issue). In order to override or set them manually it would be more convenient and in line with the other work flow in mesa to add an inlist for this? I do not know if additional inlists can be initiated for a run_star_extras - if not it may be a useful feature to be added to hooks.
So - question is: can the parameters set right now in compile time be set in an inlist instead?

Closing as duplicate of issue #3


Allow registered serializable types to be pointers.

Remove type constraint from RegisterSerializable[T] and instead check at runtime that either T or *T implements AutoMarshal.

PTAL


"Don't log M105 requests" out of order

I've switched on "Don't log M105 requests" but they still get logged.

It works. It removes all M105 commands send. It does not remove the temperature response., though. If you wan't to disable this, deselect ack.


THORN-2182: close response when mapping exception

Motivation
To keep the client working after a failure to parse response (for details, please take a look into the related THORN issue)
Modifications
DefaultExceptionMapper has been modified to close the response. Additionally, it buffers the response's entity so that the entity is still available (required by the TCK)
Result
The client is reusable after a failure.
NOTE a test for this changes is planned to be added to the Thorntail code: https://github.com/thorntail/thorntail/pull/1131 (due to difficulties setting up JSON parsing in testsuite here)

retest this please

I don't have permissions to merge this change

Try now

it worked :) thanks @kenfinnigan


Does it support *.html files, it does not

I added "grammarly.files.include": ["**/README.md", "**/readme.md", "**/*.txt", "**/*.html"]
But still it does not scan these files

Can confirm the behavior.
A possible workaround is to copy an HTML document into a Markdown file, and the extension will happily scan the text. Grammarly does a pretty good job of ignoring tags, such as <p> and <div>, though I have noticed some glitches when handling words immediately followed by HTML entities without spaces.

HTML files are not handled still, though adding html to grammarly.files.include as above does make the output prompt claim that create text checking session for  the file in question, so something is happening.

Given how long this Issue has been open (and given Grammarly is sunsetting the SDK), I have little hope to see this fixed, but FWIW, I'd like to grammar check html files with this extension, but it's not working.
Nonetheless, thank you @znck for sharing this brilliant work with the community all this time.


Enable borders in all labels

Enable borders in all labels

Please edit less file the run make generate-stylesheets

Before:

After:

Something's wrong here, you change only affects the .css file, but it should also be in .less.


🚀 Feature Request: access env in module's global scope

Describe the solution
Currently, pages functions (new syntax) receive the env in the onRequest method. It would help to get access to the env at the top level especially with support for top-level await. This would allow a worker to do init logic once before the request handler is called.

NodeJS compat has been recently added, which enables NodeJS's async local storage https://nodejs.org/api/async_context.html#class-asynclocalstorage. You can use this to pass objects around like in the global scope

This is a limitation/feature of the workers runtime when using module worker syntax (which Pages functions use under the hood). See https://developers.cloudflare.com/workers/learning/migrate-to-module-workers/#advantages-of-migrating, in particular:

Workers using ES modules format do not rely on any global bindings. This means the Workers runtime does not need to set up fresh execution contexts, making Workers safer and faster to run.