Crashes in v3/dev/3.1-experimental branch

Hello, @zimmerle! I debugged crashes found when testing https://github.com/SpiderLabs/ModSecurity/pull/2374#issuecomment-665990756 a bit.
I found two trivial bugs, here are the patches for them:
diff --git a/src/rule_with_actions.cc b/src/rule_with_actions.cc
index 738b3d72..82e1bd6a 100644
--- a/src/rule_with_actions.cc
+++ b/src/rule_with_actions.cc
@@ -250,7 +250,7 @@ void RuleWithActions::executeActionsAfterFullMatch(Transaction *trans) const {
         }
     }
     for (auto &a : getMatchActionsPtr()) {
-        if (!dynamic_cast<ActionDisruptive *>(a) != NULL
+        if (dynamic_cast<ActionDisruptive *>(a) != NULL
                 && !(disruptiveAlreadyExecuted
                 && dynamic_cast<actions::Block *>(a))) {
             executeAction(trans, a, false);

diff --git a/src/rules_exceptions.cc b/src/rules_exceptions.cc
index aee9e8c0..8f0c6ef1 100644
--- a/src/rules_exceptions.cc
+++ b/src/rules_exceptions.cc
@@ -46,7 +46,7 @@ bool RulesExceptions::loadUpdateActionById(double id,
         }

         if (dynamic_cast<actions::transformations::Transformation *>(a.get())) {
-            actions::transformations::Transformation *t = dynamic_cast<actions::transformations::Transformation *>(a.get());
+            actions::transformations::Transformation *t = dynamic_cast<actions::transformations::Transformation *>(a.release());
             m_action_transformation_update_target_by_id.emplace(
                 std::pair<double,
                 std::unique_ptr<actions::transformations::Transformation>>(id, std::unique_ptr<actions::transformations::Transformation>(t))

And not-so-trivial UAFs which I was unable to decipher. "freed by" and "allocated by" look really wrong here.
=================================================================
==1494020==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000528f0 at pc 0x7ffff6fdcf37 bp 0x7fffffff79b0 sp 0x7fffffff79a0
READ of size 8 at 0x6160000528f0 thread T0
    #0 0x7ffff6fdcf36 in modsecurity::variables::Rule_DictElement::msg(modsecurity::Transaction*, modsecurity::RuleWithActions const*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*) (/usr/local/modsecurity/lib/libmodsecurity.so.3+0x285f36)
    #1 0x7ffff6fdd63b in non-virtual thunk to modsecurity::variables::Rule_DictElement::evaluate(modsecurity::Transaction*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*) (/usr/local/modsecurity/lib/libmodsecurity.so.3+0x28663b)
    #2 0x7ffff7140c82 in modsecurity::RunTimeString::evaluate[abi:cxx11](modsecurity::Transaction*) /home/wgh/ModSecurity-upstream/src/run_time_string.cc:58
    #3 0x7ffff721258d in modsecurity::actions::ActionWithRunTimeString::getEvaluatedRunTimeString[abi:cxx11](modsecurity::Transaction*) const ../src/actions/action_with_run_time_string.h:53
    #4 0x7ffff721258d in modsecurity::actions::SetVar::execute(modsecurity::Transaction*) const actions/set_var.cc:50
    #5 0x7ffff714f216 in modsecurity::RuleWithActions::executeActionsIndependentOfChainedRuleResult(modsecurity::Transaction*) const /home/wgh/ModSecurity-upstream/src/rule_with_actions.cc:207
    #6 0x7ffff717769c in modsecurity::RuleWithOperator::evaluate(modsecurity::Transaction*) const /home/wgh/ModSecurity-upstream/src/rule_with_operator.cc:341
    #7 0x7ffff711de3d in modsecurity::RulesSet::evaluate(int, modsecurity::Transaction*) /home/wgh/ModSecurity-upstream/src/rules_set.cc:300
    #8 0x7ffff70cfa30 in modsecurity::Transaction::processRequestBody() /home/wgh/ModSecurity-upstream/src/transaction.cc:985
    #9 0x55555555e209 in process_transaction /home/wgh/modsecurity-benchmark/benchmark.cc:103
    #10 0x55555555e209 in main /home/wgh/modsecurity-benchmark/benchmark.cc:194
    #11 0x7ffff69900b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #12 0x555555560a9d in _start (/home/wgh/modsecurity-benchmark/benchmark+0xca9d)

0x6160000528f0 is located 112 bytes inside of 601-byte region [0x616000052880,0x616000052ad9)
freed by thread T0 here:
    #0 0x7ffff769c8df in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x1108df)
    #1 0x7ffff7172c6a in __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long) /usr/include/c++/9/ext/new_allocator.h:128
    #2 0x7ffff7172c6a in std::allocator_traits<std::allocator<char> >::deallocate(std::allocator<char>&, char*, unsigned long) /usr/include/c++/9/bits/alloc_traits.h:470
    #3 0x7ffff7172c6a in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy(unsigned long) /usr/include/c++/9/bits/basic_string.h:237
    #4 0x7ffff7172c6a in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() /usr/include/c++/9/bits/basic_string.h:232
    #5 0x7ffff7172c6a in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() /usr/include/c++/9/bits/basic_string.h:658
    #6 0x7ffff7172c6a in modsecurity::RuleWithOperator::evaluate(modsecurity::Transaction*) const /home/wgh/ModSecurity-upstream/src/rule_with_operator.cc:251
    #7 0x7ffff711de3d in modsecurity::RulesSet::evaluate(int, modsecurity::Transaction*) /home/wgh/ModSecurity-upstream/src/rules_set.cc:300
    #8 0x7ffff70cfa30 in modsecurity::Transaction::processRequestBody() /home/wgh/ModSecurity-upstream/src/transaction.cc:985
    #9 0x55555555e209 in process_transaction /home/wgh/modsecurity-benchmark/benchmark.cc:103
    #10 0x55555555e209 in main /home/wgh/modsecurity-benchmark/benchmark.cc:194
    #11 0x7ffff69900b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

previously allocated by thread T0 here:
    #0 0x7ffff769b947 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10f947)
    #1 0x7ffff6cb8bbd in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x142bbd)

SUMMARY: AddressSanitizer: heap-use-after-free (/usr/local/modsecurity/lib/libmodsecurity.so.3+0x285f36) in modsecurity::variables::Rule_DictElement::msg(modsecurity::Transaction*, modsecurity::RuleWithActions const*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*)
Shadow bytes around the buggy address:
  0x0c2c800024c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2c800024d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2c800024e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2c800024f0: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c2c80002500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c2c80002510: fd fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd
  0x0c2c80002520: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2c80002530: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2c80002540: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2c80002550: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c2c80002560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==1494020==ABORTING

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff698e859 in __GI_abort () at abort.c:79
#2  0x00007ffff76b76a2 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
#3  0x00007ffff76c224c in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
#4  0x00007ffff76a38ec in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
#5  0x00007ffff76a3363 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
#6  0x00007ffff76a41ab in __asan_report_load8 () from /usr/lib/x86_64-linux-gnu/libasan.so.5
#7  0x00007ffff6fdcf37 in std::__shared_ptr<modsecurity::actions::Msg, (__gnu_cxx::_Lock_policy)2>::operator bool (this=0x6160000528f0) at ../src/variables/rule.h:136
#8  std::operator!=<modsecurity::actions::Msg>(std::shared_ptr<modsecurity::actions::Msg> const&, decltype(nullptr)) (__a=<error reading variable: Cannot access memory at address 0x3038253029657c40>)
    at /usr/include/c++/9/bits/shared_ptr.h:404
#9  modsecurity::RuleWithActions::hasMessageAction (this=0x616000052880) at ../src/rule_with_actions.h:426
#10 modsecurity::variables::Rule_DictElement::msg (t=<optimized out>, rule=0x616000052880, l=<optimized out>) at ../src/variables/rule.h:134
#11 0x00007ffff6fdd63c in non-virtual thunk to modsecurity::variables::Rule_DictElement::evaluate(modsecurity::Transaction*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*) ()
    at ../src/variables/rule.h:165
#12 0x00007ffff7140c83 in modsecurity::RunTimeString::evaluate[abi:cxx11](modsecurity::Transaction*) (this=<optimized out>, transaction=transaction@entry=0x6250005e8900) at /usr/include/c++/9/bits/shared_ptr_base.h:1309
#13 0x00007ffff721258e in modsecurity::actions::ActionWithRunTimeString::getEvaluatedRunTimeString[abi:cxx11](modsecurity::Transaction*) const (transaction=0x6250005e8900, this=0x60c00002eb40) at /usr/include/c++/9/bits/unique_ptr.h:721
#14 modsecurity::actions::SetVar::execute (this=0x60c00002eb40, t=<optimized out>) at actions/set_var.cc:50
#15 0x00007ffff714f217 in modsecurity::RuleWithActions::executeActionsIndependentOfChainedRuleResult (this=this@entry=0x616000105080, trans=trans@entry=0x6250005e8900) at rule_with_actions.cc:207
#16 0x00007ffff717769d in modsecurity::RuleWithOperator::evaluate (this=0x616000105080, trans=<optimized out>) at rule_with_operator.cc:341
#17 0x00007ffff711de3e in modsecurity::RulesSet::evaluate (this=<optimized out>, phase=phase@entry=3, t=t@entry=0x6250005e8900) at /usr/include/c++/9/bits/shared_ptr_base.h:1309
#18 0x00007ffff70cfa31 in modsecurity::Transaction::processRequestBody (this=<optimized out>) at transaction.cc:985
#19 0x000055555555e20a in process_transaction (it=0x7fffffffdb00, modsecTransaction=0x6250005e8900, j=...) at benchmark.cc:103
#20 main (argc=<optimized out>, argv=<optimized out>) at benchmark.cc:194

I think the problem might be due to incorrect use of smart pointers somewhere where the rules are parsed. For example, I found the following problematic fragment, but that wasn't enough to fix the problem.
void RuleWithActions::addDefaultAction(std::shared_ptr<actions::Action> a) {
// std::dynamic_pointer_cast<actions::Msg> should've been used here to avoid UAF
   } else if (dynamic_cast<actions::Msg *>(a.get())) {
        m_defaultActionMsg.reset(dynamic_cast<actions::Msg *>(a.get()));
// ...

Maybe addAction is also wrong, but it's hard to tell since the incoming argument is not a smart pointer.

Well noticed.
The idea is that 3.1 will be able to reload the rules in place, without the server to restart. For that, it was necessary to reduce the memory footprint of the RuleObject and adjacent. At a certain time, rules will be allocated twice in memory: (a) Adress the active requests; (b) Adress the new ones.  That new feature also makes it necessary to clean up the memory properly after a new rule set is un-load.
Having said that, in terms of actions (cited in this issue), we have different approaches: some stuff became a rule property (logging) and some are actions to be used in run time with parameters inherited from the parser. To exemplify: Instead to be an object: nolog, log, auditlog and noauditlog became a bit properties of the class Rule:
https://github.com/SpiderLabs/ModSecurity/blob/5824470768e73d438a5db03b7a6eb24d7c795097/src/rule_with_actions.h#L592-L595
Further, those will become a two-bit property, that will be queried with a bitwise operation:

Porporty
Value

noLog
00

log
01

noAuditLog
10

auditLog
11

The thing with run-time-actions, the ones that are classes, is that they belong to a rule. Still, they can also belong to a rule in a second (or nth) virtual host (a consequence of a merging). Atop of that, there are the DefaultActions, which we are aiming to pre-compute in rules load time -- avoid any but necessary processing at runtime.
The smart pointers have an important role in that architecture as we are offloading the responsibility to disposable the action object to C++. I will have a look to understand better what is going on and let you know.
Thanks for testing and reporting this ;) appreciated!

The dynamic_cast<ActionDisruptive *>(a) != NULL issue was already addressed on v3.1-experimental.

Might not be the same crash you mentioned in https://github.com/SpiderLabs/ModSecurity/pull/2374#issuecomment-671348276, but I likely related. To reproduce, use this string in benchmark.cc:
Commit b32182940d
char request_uri[] = "/foobar?message=%22AAAAAAAAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAAA%3DBBBBB%3BAAAAAAAAAAAAAA%3DBBBBB%3BloadAAAAAAAA%3DBBBBB%3BAAAAAAAAAAAAAAA%22"

(gdb) bt
#0  modsecurity::RuleWithActions::getMessage[abi:cxx11](modsecurity::Transaction*) const (this=this@entry=0x555556175e00, t=t@entry=0x5555565bb3e0)
    at rule_with_actions.cc:399
#1  0x00007ffff7e49494 in modsecurity::variables::Rule_DictElement::msg (t=0x5555565bb3e0, rule=0x555556175e00, l=0x7fffffffc720)
    at /usr/include/c++/9/bits/shared_ptr_base.h:1312
#2  0x00007ffff7e4970c in non-virtual thunk to modsecurity::variables::Rule_DictElement::evaluate(modsecurity::Transaction*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*) () at ../src/variables/rule.h:165
#3  0x00007ffff7ea79ae in modsecurity::RunTimeString::evaluate[abi:cxx11](modsecurity::Transaction*) (this=0x555556177050, transaction=transaction@entry=0x5555565bb3e0)
    at /usr/include/c++/9/bits/shared_ptr_base.h:1309
#4  0x00007ffff7edae66 in modsecurity::actions::ActionWithRunTimeString::getEvaluatedRunTimeString[abi:cxx11](modsecurity::Transaction*) const (
    transaction=0x5555565bb3e0, this=0x555556171e00) at /usr/include/c++/9/bits/unique_ptr.h:721
#5  modsecurity::actions::SetVar::execute (this=0x555556171e00, t=0x5555565bb3e0) at actions/set_var.cc:50
#6  0x00007ffff7eaaafc in modsecurity::RuleWithActions::executeActionsIndependentOfChainedRuleResult (this=this@entry=0x5555565a1970, trans=trans@entry=0x5555565bb3e0)
    at rule_with_actions.cc:207
#7  0x00007ffff7eb33dd in modsecurity::RuleWithOperator::evaluate (this=0x5555565a1970, trans=0x5555565bb3e0) at rule_with_operator.cc:340
#8  0x00007ffff7e9fb7f in modsecurity::RulesSet::evaluate (this=0x5555555aac80, phase=phase@entry=3, t=t@entry=0x5555565bb3e0)
    at /usr/include/c++/9/bits/shared_ptr_base.h:1309
#9  0x00007ffff7e8bbb5 in modsecurity::Transaction::processRequestBody (this=0x5555565bb3e0) at transaction.cc:985
#10 0x0000555555556f2c in main (argc=<optimized out>, argv=<optimized out>) at benchmark.cc:136

==95724==ERROR: AddressSanitizer: heap-use-after-free on address 0x61600006f6f0 at pc 0x7f6f3a19bf27 bp 0x7fffcb419890 sp 0x7fffcb419880
READ of size 8 at 0x61600006f6f0 thread T0
    #0 0x7f6f3a19bf26 in modsecurity::variables::Rule_DictElement::msg(modsecurity::Transaction*, modsecurity::RuleWithActions const*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*) (/home/wgh/ModSecurity-upstream/src/.libs/libmodsecurity.so.3+0x285f26)
    #1 0x7f6f3a19c62b in non-virtual thunk to modsecurity::variables::Rule_DictElement::evaluate(modsecurity::Transaction*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*) (/home/wgh/ModSecurity-upstream/src/.libs/libmodsecurity.so.3+0x28662b)
    #2 0x7f6f3a3015c2 in modsecurity::RunTimeString::evaluate[abi:cxx11](modsecurity::Transaction*) /home/wgh/ModSecurity-upstream/src/run_time_string.cc:58
    #3 0x7f6f3a3d41d1 in modsecurity::actions::ActionWithRunTimeString::getEvaluatedRunTimeString[abi:cxx11](modsecurity::Transaction*) const ../src/actions/action_with_run_time_string.h:53
    #4 0x7f6f3a3d41d1 in modsecurity::actions::SetVar::execute(modsecurity::Transaction*) const actions/set_var.cc:50
    #5 0x7f6f3a30fb56 in modsecurity::RuleWithActions::executeActionsIndependentOfChainedRuleResult(modsecurity::Transaction*) const /home/wgh/ModSecurity-upstream/src/rule_with_actions.cc:207
    #6 0x7f6f3a338662 in modsecurity::RuleWithOperator::evaluate(modsecurity::Transaction*) const /home/wgh/ModSecurity-upstream/src/rule_with_operator.cc:340
    #7 0x7f6f3a2de49f in modsecurity::RulesSet::evaluate(int, modsecurity::Transaction*) /home/wgh/ModSecurity-upstream/src/rules_set.cc:300
    #8 0x7f6f3a290092 in modsecurity::Transaction::processRequestBody() /home/wgh/ModSecurity-upstream/src/transaction.cc:985
    #9 0x56129356b4d7 in main /home/wgh/ModSecurity-upstream/test/benchmark/benchmark.cc:136
    #10 0x7f6f399bf0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #11 0x56129343d67d in _start (/home/wgh/ModSecurity-upstream/test/benchmark/.libs/benchmark+0xb67d)

0x61600006f6f0 is located 112 bytes inside of 576-byte region [0x61600006f680,0x61600006f8c0)
freed by thread T0 here:
    #0 0x56129352b3df in operator delete(void*) (/home/wgh/ModSecurity-upstream/test/benchmark/.libs/benchmark+0xf93df)
    #1 0x7f6f3a26259b in std::default_delete<modsecurity::RuleWithActions>::operator()(modsecurity::RuleWithActions*) const /usr/include/c++/9/bits/unique_ptr.h:81
    #2 0x7f6f3a26259b in std::_Sp_counted_deleter<modsecurity::RuleWithActions*, std::default_delete<modsecurity::RuleWithActions>, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() /usr/include/c++/9/bits/shared_ptr_base.h:471
    #3 0x7f6f3a254204 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/9/bits/shared_ptr_base.h:155
    #4 0x7f6f3a254204 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/9/bits/shared_ptr_base.h:730
    #5 0x7f6f3a254204 in std::__shared_ptr<modsecurity::Rule, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/9/bits/shared_ptr_base.h:1169
    #6 0x7f6f3a254204 in std::shared_ptr<modsecurity::Rule>::~shared_ptr() /usr/include/c++/9/bits/shared_ptr.h:103
    #7 0x7f6f3a254204 in void std::_Destroy<std::shared_ptr<modsecurity::Rule> >(std::shared_ptr<modsecurity::Rule>*) /usr/include/c++/9/bits/stl_construct.h:98
    #8 0x7f6f3a254204 in void std::_Destroy_aux<false>::__destroy<std::shared_ptr<modsecurity::Rule>*>(std::shared_ptr<modsecurity::Rule>*, std::shared_ptr<modsecurity::Rule>*) /usr/include/c++/9/bits/stl_construct.h:108
    #9 0x7f6f3a254204 in void std::_Destroy<std::shared_ptr<modsecurity::Rule>*>(std::shared_ptr<modsecurity::Rule>*, std::shared_ptr<modsecurity::Rule>*) /usr/include/c++/9/bits/stl_construct.h:137
    #10 0x7f6f3a254204 in void std::_Destroy<std::shared_ptr<modsecurity::Rule>*, std::shared_ptr<modsecurity::Rule> >(std::shared_ptr<modsecurity::Rule>*, std::shared_ptr<modsecurity::Rule>*, std::allocator<std::shared_ptr<modsecurity::Rule> >&) /usr/include/c++/9/bits/stl_construct.h:206
    #11 0x7f6f3a254204 in std::vector<std::shared_ptr<modsecurity::Rule>, std::allocator<std::shared_ptr<modsecurity::Rule> > >::~vector() /usr/include/c++/9/bits/stl_vector.h:677
    #12 0x7f6f3a254204 in modsecurity::Rules::~Rules() ../headers/modsecurity/rules.h:46
    #13 0x7f6f3a254204 in std::array<modsecurity::Rules, 7ul>::~array() /usr/include/c++/9/array:94
    #14 0x7f6f3a254204 in modsecurity::RulesSetPhases::~RulesSetPhases() ../headers/modsecurity/rules_set_phases.h:44
    #15 0x7f6f3a254204 in modsecurity::Parser::Driver::~Driver() parser/driver.cc:36
    #16 0x7f6f3a254ebe in modsecurity::Parser::Driver::~Driver() parser/driver.cc:42
    #17 0x7f6f3a2e8c0e in modsecurity::RulesSet::loadFromUri(char const*) /home/wgh/ModSecurity-upstream/src/rules_set.cc:102
    #18 0x56129356a41c in main /home/wgh/ModSecurity-upstream/test/benchmark/benchmark.cc:82
    #19 0x7f6f399bf0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

previously allocated by thread T0 here:
    #0 0x56129352a447 in operator new(unsigned long) (/home/wgh/ModSecurity-upstream/test/benchmark/.libs/benchmark+0xf8447)
    #1 0x7f6f3a0d8637 in yy::seclang_parser::parse() /home/wgh/ModSecurity-upstream/src/seclang-parser.yy:1096
    #2 0x7f6f3a26094b in modsecurity::Parser::Driver::parse(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) parser/driver.cc:210
    #3 0x7f6f3a261abb in modsecurity::Parser::Driver::parseFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) parser/driver.cc:254
    #4 0x7f6f3a2e8b49 in modsecurity::RulesSet::loadFromUri(char const*) /home/wgh/ModSecurity-upstream/src/rules_set.cc:95
    #5 0x56129356a41c in main /home/wgh/ModSecurity-upstream/test/benchmark/benchmark.cc:82
    #6 0x7f6f399bf0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

SUMMARY: AddressSanitizer: heap-use-after-free (/home/wgh/ModSecurity-upstream/src/.libs/libmodsecurity.so.3+0x285f26) in modsecurity::variables::Rule_DictElement::msg(modsecurity::Transaction*, modsecurity::RuleWithActions const*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*)

Perfect! I am going to investigate.
RunTimeStrings are strings that accept variables as macro expansions. Those variables sometimes need to have the knowledge of the Rule that it belongs (XML or RULE). In this case, a new variable instance needs to be created for every rule. That scenario became especially confused when applied to rule merging. I will try to create a new set of tests to stress the rule merging focusing on reproduce this kind of error. As collateral, this test suit will highlight if such errors appear as regression.

@WGH- ping. Can you assist me with some testing on that matter? I think we have already mitigated that issue +  a couple of changes for the benefit of performance && usability. It would be wonderful if I can count on you to test this again.

I think that it is no longer an issue in v3.1-experimetal. Therefore I am closing it.
The problem was related to a broken copy constructor for an Action that wasn't updating the reference to a new rule. Leading to an invalid memory access.

Still crashes for me, although in different place now.
(gdb) where
f#0  0x00007ffff7c7fee2 in __dynamic_cast () from /lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff7ebaf1e in modsecurity::RuleWithActions::executeTransformations (this=0x555556642510,
    trans=0x555564d64f70, in=..., results=std::__cxx11::list = {...}) at rule_with_actions.cc:386
#2  0x00007ffff7eb2c32 in modsecurity::RuleWithOperator::evaluate (this=<optimized out>, trans=<optimized out>)
    at rule_with_operator.cc:302
#3  0x00007ffff7ebd353 in modsecurity::RulesSet::evaluate (this=0x5555555bccd0, phase=<optimized out>,
    t=0x555564d64f70) at rules_set.cc:300
#4  0x00007ffff7ecd724 in modsecurity::Transaction::processRequestBody (this=0x555564d64f70) at transaction.cc:956
#5  0x0000555555559b14 in process_transaction (it=0x7fffffffe1c0, modsecTransaction=0x555564d64f70, j=...)
    at benchmark.cc:103
#6  main (argc=<optimized out>, argv=<optimized out>) at benchmark.cc:194
(gdb) frame 1
#1  0x00007ffff7ebaf1e in modsecurity::RuleWithActions::executeTransformations (this=0x555556642510,
    trans=0x555564d64f70, in=..., results=std::__cxx11::list = {...}) at rule_with_actions.cc:386
386	        if (dynamic_cast<actions::transformations::None *>(t)) {
(gdb) l
381	    // FIXME: It can't be something different from transformation. Sort this
382	    //        on rules compile time.
383	    auto range = trans->m_rules->m_exceptions.m_action_transformation_update_target_by_id.equal_range(m_ruleId);
384	    for (auto it = range.first; it != range.second; ++it) {
385	        Transformation *t = it->second.get();
386	        if (dynamic_cast<actions::transformations::None *>(t)) {
387	            none++;
388	        }
389	    }
390

8aa3e3439d697e70b09b029b85e8a83a6edb7bc4 is the first certainly bad commit, and 67b08dfe43633e63dfe6d1e386879519d634185f crashes due to apparently unrelated problem:
#0  modsecurity::RuleWithActions::getMessage[abi:cxx11](modsecurity::Transaction*) const (
    this=this@entry=0x5555557ae4c0, t=t@entry=0x555564ceca60) at rule_with_actions.cc:496
#1  0x00007ffff7e5b164 in modsecurity::variables::Rule_DictElement::msg (t=0x555564ceca60, rule=0x5555557ae4c0,
    l=0x7fffffffc710) at /usr/include/c++/9/bits/shared_ptr_base.h:1312
#2  0x00007ffff7e5b3dc in non-virtual thunk to modsecurity::variables::Rule_DictElement::evaluate(modsecurity::Transaction*, std::vector<modsecurity::VariableValue const*, std::allocator<modsecurity::VariableValue const*> >*) ()
    at ../src/variables/rule.h:165
#3  0x00007ffff7eb6414 in modsecurity::RunTimeString::evaluate[abi:cxx11](modsecurity::Transaction*) (
    this=0x5555557af760, transaction=transaction@entry=0x555564ceca60)
    at /usr/include/c++/9/bits/shared_ptr_base.h:1309
#4  0x00007ffff7ee4c21 in modsecurity::actions::ActionWithRunTimeString::getEvaluatedRunTimeString[abi:cxx11](modsecurity::Transaction*) const (transaction=0x555564ceca60, this=0x5555557af6f0) at /usr/include/c++/9/bits/unique_ptr.h:721
#5  modsecurity::actions::SetVar::execute (this=0x5555557af6f0, rule=<optimized out>, t=0x555564ceca60)
    at actions/set_var.cc:50
#6  0x00007ffff7eb9e62 in modsecurity::RuleWithActions::executeActionsIndependentOfChainedRuleResult (
    this=this@entry=0x55555660f690, trans=trans@entry=0x555564ceca60) at rule_with_actions.cc:260
#7  0x00007ffff7ec19e7 in modsecurity::RuleWithOperator::evaluate (this=0x55555660f690, trans=0x555564ceca60)
    at rule_with_operator.cc:340
#8  0x00007ffff7eae1d6 in modsecurity::RulesSet::evaluate (this=0x5555555bccd0, phase=phase@entry=3,
    t=t@entry=0x555564ceca60) at /usr/include/c++/9/bits/shared_ptr_base.h:1309
#9  0x00007ffff7e9cdc3 in modsecurity::Transaction::processRequestBody (this=0x555564ceca60) at transaction.cc:964
#10 0x0000555555559b4c in process_transaction (it=0x7fffffffe1c0, modsecTransaction=0x555564ceca60, j=...)
    at benchmark.cc:103
#11 main (argc=<optimized out>, argv=<optimized out>) at benchmark.cc:194

Thanks @WGH-, is this the benchmark utility for ModSec?

No, its my own private code. I'll try to give you either good ASAN diagnostic, or a simple test case, hopefully tomorrow UTCish.
On October 30, 2020 1:35:04 AM GMT+03:00, Felipe Zimmerle<EMAIL_ADDRESS>wrote:

Thanks @WGH-, is this the benchmark utility for ModSec?

No, it's my own private code. I'll try to give you either good ASAN diagnostic, or a simple test case, hopefully tomorrow UTCish.
…
On October 30, 2020 1:35:04 AM GMT+03:00, Felipe Zimmerle @.***> wrote: Thanks @WGH-, is this the benchmark utility for ModSec?

perfect! thank you. I am merging some other stuff that should not impact with those.

Making asan give proper diagnostics was harder than I expected. Turned out I have to

compile C++ library itself with asan, otherwise non-instrumented dynamic_cast implementation crashes without giving proper diagnostics,
increase quarantine memory size with.

==3085008==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060000f50c0 at pc 0x7ff1432b53fd bp 0x7ffdc1a1d630 sp 0x7ffdc1a1d628
READ of size 8 at 0x6060000f50c0 thread T0
    #0 0x7ff1432b53fc in __dynamic_cast /home/wgh/prefix_test/usr/src/debug/sys-libs/libcxxabi-11.0.0/libcxxabi/src/private_typeinfo.cpp:618:21
    #1 0x7ff1438a59f7 in modsecurity::RuleWithActions::executeTransformations(modsecurity::Transaction*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::list<modsecurity::TransformationResult, std::__1::allocator<modsecurity::TransformationResult> >&) const /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rule_with_actions.cc:386:13
    #2 0x7ff1438bc8e3 in modsecurity::RuleWithOperator::evaluate(modsecurity::Transaction*) const /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rule_with_operator.cc:302:13
    #3 0x7ff14388c9f0 in modsecurity::RulesSet::evaluate(int, modsecurity::Transaction*) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rules_set.cc:300:19
    #4 0x7ff143865eb0 in modsecurity::Transaction::processRequestBody() /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/transaction.cc:956:20
    #5 0x408280 in process_transaction(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long, unsigned long, double, std::__1::allocator, nlohmann::adl_serializer, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > > const&, modsecurity::Transaction*, modsecurity::ModSecurityIntervention_t*) /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:103:24
    #6 0x408280 in main /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:194:13
    #7 0x7ff142f1fe09 in __libc_start_main (/home/wgh/prefix_test/lib64/libc.so.6+0x23e09)
    #8 0x406879 in _start (/home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark+0x406879)

0x6060000f50c0 is located 0 bytes inside of 64-byte region [0x6060000f50c0,0x6060000f5100)
freed by thread T0 here:
    #0 0x7ff143d1bb0d in operator delete(void*) (/home/wgh/prefix_test/usr/lib/clang/11.0.0/lib/linux/libclang_rt.asan-x86_64.so+0xcdb0d)
    #1 0x7ff14390ebf5 in modsecurity::actions::transformations::None::~None() /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/../src/actions/transformations/none.h:34:7
    #2 0x7ff1437f0de4 in std::__1::default_delete<modsecurity::actions::Action>::operator()(modsecurity::actions::Action*) const /home/wgh/prefix_test/usr/include/c++/v1/memory:2262:5
    #3 0x7ff1437fadea in std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >::reset(modsecurity::actions::Action*) /home/wgh/prefix_test/usr/include/c++/v1/memory:2517:7
    #4 0x7ff1437bfe3a in std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >::~unique_ptr() /home/wgh/prefix_test/usr/include/c++/v1/memory:2471:19
    #5 0x7ff1437eec8b in std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > >::destroy(std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >*) /home/wgh/prefix_test/usr/include/c++/v1/memory:1811:92
    #6 0x7ff1437eec78 in void std::__1::allocator_traits<std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >::__destroy<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > >(std::__1::integral_constant<bool, true>, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > >&, std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >*) /home/wgh/prefix_test/usr/include/c++/v1/memory:1703:21
    #7 0x7ff1437eec68 in void std::__1::allocator_traits<std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >::destroy<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > >(std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > >&, std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >*) /home/wgh/prefix_test/usr/include/c++/v1/memory:1544:14
    #8 0x7ff1437eec16 in std::__1::__vector_base<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >::__destruct_at_end(std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >*) /home/wgh/prefix_test/usr/include/c++/v1/vector:428:9
    #9 0x7ff1437eeb8b in std::__1::__vector_base<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >::clear() /home/wgh/prefix_test/usr/include/c++/v1/vector:371:29
    #10 0x7ff1437ee9dc in std::__1::__vector_base<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >::~__vector_base() /home/wgh/prefix_test/usr/include/c++/v1/vector:465:9
    #11 0x7ff1437ee905 in std::__1::vector<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >::~vector() /home/wgh/prefix_test/usr/include/c++/v1/vector:557:5
    #12 0x7ff1437ee8c5 in std::__1::default_delete<std::__1::vector<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > > >::operator()(std::__1::vector<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >*) const /home/wgh/prefix_test/usr/include/c++/v1/memory:2262:5
    #13 0x7ff1437ee7ea in std::__1::unique_ptr<std::__1::vector<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >, std::__1::default_delete<std::__1::vector<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > > > >::reset(std::__1::vector<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >*) /home/wgh/prefix_test/usr/include/c++/v1/memory:2517:7
    #14 0x7ff1437a4dda in std::__1::unique_ptr<std::__1::vector<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > >, std::__1::default_delete<std::__1::vector<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> >, std::__1::allocator<std::__1::unique_ptr<modsecurity::actions::Action, std::__1::default_delete<modsecurity::actions::Action> > > > > >::~unique_ptr() /home/wgh/prefix_test/usr/include/c++/v1/memory:2471:19
    #15 0x7ff143798c09 in yy::seclang_parser::parse() /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/seclang-parser.yy:1515:13
    #16 0x7ff14384f4ca in modsecurity::Parser::Driver::parse(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/parser/driver.cc:213:22
    #17 0x7ff14384f904 in modsecurity::Parser::Driver::parseFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/parser/driver.cc:257:12
    #18 0x7ff143889725 in modsecurity::RulesSet::loadFromUri(char const*) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rules_set.cc:95:17
    #19 0x406faf in main /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:180:16
    #20 0x7ff142f1fe09 in __libc_start_main (/home/wgh/prefix_test/lib64/libc.so.6+0x23e09)

previously allocated by thread T0 here:
    #0 0x7ff143d1b2ad in operator new(unsigned long) (/home/wgh/prefix_test/usr/lib/clang/11.0.0/lib/linux/libclang_rt.asan-x86_64.so+0xcd2ad)
    #1 0x7ff1437924f7 in yy::seclang_parser::parse() /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/seclang-parser.yy:2928:9
    #2 0x7ff14384f4ca in modsecurity::Parser::Driver::parse(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/parser/driver.cc:213:22
    #3 0x7ff14384f904 in modsecurity::Parser::Driver::parseFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/parser/driver.cc:257:12
    #4 0x7ff143889725 in modsecurity::RulesSet::loadFromUri(char const*) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rules_set.cc:95:17
    #5 0x406faf in main /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:180:16
    #6 0x7ff142f1fe09 in __libc_start_main (/home/wgh/prefix_test/lib64/libc.so.6+0x23e09)

Thank you @WGH-. Your feedback is very important. Going to approach that with a different perspective.
Ideally (long-term-plan) we won't have t:none computation on runtime. Rather we want to have it pre-computed on load time. Only exception if the action was added in run-time. The issues that you are facing is maybe a collateral from a middle state. Let me finish that t:none pre-computation and I will ask you to test again.

It can be easily reproduced with test/benchmark/benchmark.cc and the following rule set:
SecRule ARGS "@rx foo" "id:1"
SecRuleUpdateActionById 1 "t:none,t:utf8toUnicode,t:urlDecodeUni"

This is the fix:
diff --git a/src/rules_exceptions.cc b/src/rules_exceptions.cc
index 97bbdc2e..07623e9c 100644
--- a/src/rules_exceptions.cc
+++ b/src/rules_exceptions.cc
@@ -46,7 +46,7 @@ bool RulesExceptions::loadUpdateActionById(RuleId id,
         }

         if (dynamic_cast<actions::transformations::Transformation *>(a.get())) {
-            actions::transformations::Transformation *t = dynamic_cast<actions::transformations::Transformation *>(a.get());
+            actions::transformations::Transformation *t = dynamic_cast<actions::transformations::Transformation *>(a.release());
             m_action_transformation_update_target_by_id.emplace(
                 std::pair<RuleId,
                 std::unique_ptr<actions::transformations::Transformation>>(id, std::unique_ptr<actions::transformations::Transformation>(t))

Hi @WGH- ,
I came to the same conclusion as you a few minutes ago.
The current code essentially results in two different unique_ptr smart pointers 'owning' the same object.

thank you guys 👍

Fixing that, I have a null pointer dereference crash now:
0x00007ffff71e7d0e in modsecurity::RuleWithActions::executeActionsAfterFullMatch(modsecurity::Transaction*) const::$_2::operator()(modsecurity::Transaction*, std::__1::shared_ptr<modsecurity::actions::ActionWithExecution> const&) const (this=<optimized out>, t=0x624000182100, a=...)
    at rule_with_actions.cc:322
322	        a->execute(t);

I debugged it a bit, and addGenericMatchAction(std::dynamic_pointer_cast<ActionWithExecution>(a)); line in RuleWithActions::RuleWithActions seems to insert a null pointer into the m_executeIfMatchActions; list.
Here's a rule set to reproduce it with test/benchmark/benchmark:
SecRule REQBODY_PROCESSOR "!@rx (?:URLENCODED|MULTIPART|XML|JSON)" \
    "id:901340,\
    ctl:forceRequestBodyVariable=On

Hi @WGH- ,
Thanks for calling attention to that additional problem.  I can reproduce it, and I think I see the underlying problem.

Just to note that this most recent issue also applies to ctl:auditEngine

Regarding the v3.1-experimental crashes caused by ctl:forceRequestBodyVariable and ctl:auditEngine ...
These have never been properly supported in v3, and yet in current v3 code, the standard '... is not supported ...' error behaviour is not triggered.  The crash in v3.1 is merely a more obvious symptom than failing silently.
The immediate plan is to have both of these actions trigger the standard '... is not supported ...' error behaviour (like sanitiseArg, and others currently do)

Both crashed are addressed by @martinhsv, under QA here - https://travis-ci.org/github/SpiderLabs/ModSecurity/builds/741862888

It no longer crashes in my benchmark :+1:
It seems to leak memory like crazy though, which is also reported by ASAN (to clarify, it certainly leaks without ASAN as well).
The commit I tested is 15fc0481f17d0527b54dca7987041cdc633c05e5

There's lots of leaks with slightly different stack traces, but I believe these are the three main types:

Direct leak of 58575456 byte(s) in 406774 object(s) allocated from:
    #0 0x7fef091032ad in operator new(unsigned long) (/home/wgh/prefix_test/usr/lib/clang/11.0.0/lib/linux/libclang_rt.asan-x86_64.so+0xcd2ad)
    #1 0x7fef08c2d4bb in modsecurity::TransactionRuleMessageManagement::messageNew() /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/transaction.cc:88:31
    #2 0x7fef08c2d303 in modsecurity::TransactionRuleMessageManagement::logMatchLastRuleOnTheChain(modsecurity::RuleWithActions const*) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/transaction.cc:83:9
    #3 0x7fef08c9170a in modsecurity::RuleWithOperator::evaluate(modsecurity::Transaction*) const /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rule_with_operator.cc:400:12
    #4 0x7fef08c60d30 in modsecurity::RulesSet::evaluate(int, modsecurity::Transaction*) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rules_set.cc:300:19
    #5 0x7fef08c3240d in modsecurity::Transaction::processRequestHeaders() /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/transaction.cc:593:20
    #6 0x407f47 in process_transaction(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long, unsigned long, double, std::__1::allocator, nlohmann::adl_serializer, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > > const&, modsecurity::Transaction*, modsecurity::ModSecurityIntervention_t*) /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:87:24
    #7 0x407f47 in main /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:194:13
    #8 0x7fef082e4e09 in __libc_start_main (/home/wgh/prefix_test/lib64/libc.so.6+0x23e09)

Direct leak of 9914352 byte(s) in 413098 object(s) allocated from:
    #0 0x7fef091032ad in operator new(unsigned long) (/home/wgh/prefix_test/usr/lib/clang/11.0.0/lib/linux/libclang_rt.asan-x86_64.so+0xcd2ad)
    #1 0x7fef08c8e507 in modsecurity::RuleWithOperator::updateMatchedVars(modsecurity::Transaction*, modsecurity::VariableValue const*, bpstd::basic_string_view<char, std::__1::char_traits<char> > const&) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rule_with_operator.cc:85:30
    #2 0x7fef08c91082 in modsecurity::RuleWithOperator::evaluate(modsecurity::Transaction*) const /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rule_with_operator.cc:357:21
    #3 0x7fef08c60d30 in modsecurity::RulesSet::evaluate(int, modsecurity::Transaction*) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rules_set.cc:300:19
    #4 0x7fef08c3240d in modsecurity::Transaction::processRequestHeaders() /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/transaction.cc:593:20
    #5 0x407f47 in process_transaction(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long, unsigned long, double, std::__1::allocator, nlohmann::adl_serializer, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > > const&, modsecurity::Transaction*, modsecurity::ModSecurityIntervention_t*) /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:87:24
    #6 0x407f47 in main /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:194:13
    #7 0x7fef082e4e09 in __libc_start_main (/home/wgh/prefix_test/lib64/libc.so.6+0x23e09)

Direct leak of 6208800 byte(s) in 258700 object(s) allocated from:
    #0 0x7fef091032ad in operator new(unsigned long) (/home/wgh/prefix_test/usr/lib/clang/11.0.0/lib/linux/libclang_rt.asan-x86_64.so+0xcd2ad)
    #1 0x7fef08ba3a05 in modsecurity::VariableValue::VariableValue(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const*) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/../headers/modsecurity/variable_value.h:101:17
    #2 0x7fef08ba391e in std::__1::__compressed_pair_elem<modsecurity::VariableValue, 1, false>::__compressed_pair_elem<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&, 0ul, 1ul>(std::__1::piecewise_construct_t, std::__1::tuple<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&>, std::__1::__tuple_indices<0ul, 1ul>) /home/wgh/prefix_test/usr/include/c++/v1/memory:2113:9
    #3 0x7fef08ba3318 in std::__1::__compressed_pair<std::__1::allocator<modsecurity::VariableValue>, modsecurity::VariableValue>::__compressed_pair<std::__1::allocator<modsecurity::VariableValue>&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&>(std::__1::piecewise_construct_t, std::__1::tuple<std::__1::allocator<modsecurity::VariableValue>&>, std::__1::tuple<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&>) /home/wgh/prefix_test/usr/include/c++/v1/memory:2197:9
    #4 0x7fef08ba2cc6 in std::__1::__shared_ptr_emplace<modsecurity::VariableValue, std::__1::allocator<modsecurity::VariableValue> >::__shared_ptr_emplace<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*>(std::__1::allocator<modsecurity::VariableValue>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&) /home/wgh/prefix_test/usr/include/c++/v1/memory:3470:16
    #5 0x7fef08ba0a6b in std::__1::enable_if<!(is_array<modsecurity::VariableValue>::value), std::__1::shared_ptr<modsecurity::VariableValue> >::type std::__1::make_shared<modsecurity::VariableValue, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*&&) /home/wgh/prefix_test/usr/include/c++/v1/memory:4291:26
    #6 0x7fef08ba0544 in modsecurity::variables::VariableModificatorCount::evaluate(modsecurity::Transaction const*, std::__1::vector<std::__1::shared_ptr<modsecurity::VariableValue const>, std::__1::allocator<std::__1::shared_ptr<modsecurity::VariableValue const> > >*) const /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/../src/variables/variable.h:776:22
    #7 0x7fef08c90abb in modsecurity::RuleWithOperator::evaluate(modsecurity::Transaction*) const /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rule_with_operator.cc:284:14
    #8 0x7fef08c60d30 in modsecurity::RulesSet::evaluate(int, modsecurity::Transaction*) /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/rules_set.cc:300:19
    #9 0x7fef08c3240d in modsecurity::Transaction::processRequestHeaders() /home/wgh/prefix_test/modsec/ModSecurity-upstream/src/transaction.cc:593:20
    #10 0x407f47 in process_transaction(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long, unsigned long, double, std::__1::allocator, nlohmann::adl_serializer, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > > const&, modsecurity::Transaction*, modsecurity::ModSecurityIntervention_t*) /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:87:24
    #11 0x407f47 in main /home/wgh/prefix_test/modsec/modsecurity-benchmark/benchmark.cc:194:13
    #12 0x7fef082e4e09 in __libc_start_main (/home/wgh/prefix_test/lib64/libc.so.6+0x23e09)

Thanks @WGH-  for raising those memory leaks.
I have created a pull request (https://github.com/SpiderLabs/ModSecurity/pull/2446) for the first of the three that you mention.

notice that there is a memory leak on the matched_vars as stated here: #2428

all issues reported here are now mitigated -- 587cbf39153fccb9cd129433609835fa83064bc4

You forgot to add some headers to pkginclude_HEADERS list. Namely, anchored_set_variable_match_vars.h, anchored_set_variable_match_vars_names.h, and anchored_variable_match_var_name.h.
The last leak is still not fixed. The first constructor of VariableValue doesn't free the pointer stored in m_value.
    explicit VariableValue(const std::string *collection,
        const std::string *value = nullptr)
        : m_origin(),
        m_value(new std::string(value != nullptr?*value:"")), // FIXME: no need for to copy here.
        m_valueHolder(nullptr),
        m_key(nullptr),
        m_keyHolder(nullptr),
        m_collection(new std::string(*collection)) // FIXME: no need for to copy here.
    { };

Thank you @WGH- going to look into those.

@WGH-

[x] VariableValue constructor was changed.
[X] anchored_set_variable_match_vars.h, anchored_set_variable_match_vars_names.h, and anchored_variable_match_var_name.h are now part of pkginclude_HEADERS.

New VariableValue constructor -
https://github.com/SpiderLabs/ModSecurity/blob/5f38e37f73f151db49e3f34981adc96d03633889/headers/modsecurity/variable_value.h#L98-L108
pkginclude_HEADERS -
https://github.com/SpiderLabs/ModSecurity/blob/5f38e37f73f151db49e3f34981adc96d03633889/src/Makefile.am#L37-L57
There are some others concerns being discussed on #2469. I will report here whenever we have a concrete position, meaning: testable branch.
Trying to have make check-valgrind as a manual action on GitHub workflows. The idea of having it on a branch is not pleasing GitHub.

[X] #2469 is closed.
[ ] #2381 under investigation.

@zimmerle hey, do you need ASAN memory leak output regarding rules loading? I believe I had quite a lot of reported leaks related to it as well. I didn't show them because per-transaction memory leaks were more concerning at that moment.

@WGH- It will be amazing if you manage to share those. We want to mitigate all those memory related issues. Even small leaks can be very annoying depending on the deployment. thanks!

Commit 81dcf2947d1d1fd757c2cf0d8a39be98605226bf. I didn't do any analysis, but if you  need assistance with debugging or fixing, please ping me.
modsec_asan.log

@WGH-,
Thank you for providing the asan output; I have changed the Makefiles.am a bit to make easier to use compilation flags via CXX_FLAGS, such as -fsanitize=address -fno-omit-frame-pointer (b7d616a40ce186e6879ec3a0d59247002ede7377) -
https://github.com/SpiderLabs/ModSecurity/blob/b345d1a5a94668e0289efcd65261f27012b9d462/src/Makefile.am#L334-L335
Remove all the leaks from the parser was an interesting task :100: ; In details -

Parser location is now a custom class. It holds a shared pointer with the file name; If the parser fails, the resource is deleted.
To follow the parser change, the Rule class now holds the file name in a shared pointer instead of a unique pointer. As a shared pointer we avoid duplication of the file name in memory, plus, it frees itself when not in use anymore.
Operator init also accepting the filename as a shared pointer.
Driver is treating m_location was privative. Now it holds a std::list<std::shared_ptryy::seclang_parser::location_type> instead of: std::list<yy::seclang_parser::location_type *>.
Fix: addSecRule on Driver() was changed from RuleWithAction to RuleWithOperator.
Minor changes on the regression and rules-check utility to force deletion of resources even when they fail.
Couple of virtual destructors were placed to force the shared pointer decrementing on shared variables.
Deleted constructors for copy were placed for the sake of readability.

All those changes are packed here: b345d1a5a94668e0289efcd65261f27012b9d462 and effectively solve anything related to #2381
An inclusion of a file that does not exist will lead to a leak, but, I don't want to hold that patch due to a very unlikely scenario with a minimal leak size. We can left that for the next cleanup.
I guess we are safe fro another round of tests ;) :rocket: :rocket: :rocket:

@WGH-,
Thank you for providing the asan output; I have changed the Makefiles.am a bit to make easier to use compilation flags via CXX_FLAGS, such as -fsanitize=address -fno-omit-frame-pointer (b7d616a40ce186e6879ec3a0d59247002ede7377) -
https://github.com/SpiderLabs/ModSecurity/blob/b345d1a5a94668e0289efcd65261f27012b9d462/src/Makefile.am#L334-L335
Remove all the leaks from the parser was an interesting task :100: ; In details -

Parser location is now a custom class. It holds a shared pointer with the file name; If the parser fails, the resource is deleted.
To follow the parser change, the Rule class now holds the file name in a shared pointer instead of a unique pointer. As a shared pointer we avoid duplication of the file name in memory, plus, it frees itself when not in use anymore.
Operator init also accepting the filename as a shared pointer.
Driver is treating m_location was privative. Now it holds a std::list<std::shared_ptryy::seclang_parser::location_type> instead of: std::list<yy::seclang_parser::location_type *>.
Fix: addSecRule on Driver() was changed from RuleWithAction to RuleWithOperator.
Minor changes on the regression and rules-check utility to force deletion of resources even when they fail.
Couple of virtual destructors were placed to force the shared pointer decrementing on shared variables.
Deleted constructors for copy were placed for the sake of readability.

All those changes are packed here: b345d1a5a94668e0289efcd65261f27012b9d462 and effectively solve anything related to #2381
An inclusion of a file that does not exist will lead to a leak, but, I don't want to hold that patch due to a very unlikely scenario with a minimal leak size. We can left that for the next cleanup.
I guess we are safe fro another round of tests ;) :rocket: :rocket: :rocket:

Yep, no leaks! 👍🏻

Thank you for providing the asan output; I have changed the Makefiles.am a bit to make easier to use compilation flags via CXX_FLAGS, such as -fsanitize=address -fno-omit-frame-pointer

Interesting, because I didn't have any problems with enabling sanitizers. Well, caused by ModSecurity build scripts, at least :)

Yep, no leaks! 👍🏻

Thank you for providing the asan output; I have changed the Makefiles.am a bit to make easier to use compilation flags via CXX_FLAGS, such as -fsanitize=address -fno-omit-frame-pointer

Interesting, because I didn't have any problems with enabling sanitizers. Well, caused by ModSecurity build scripts, at least :)

Yep, no leaks! 👍🏻

Good to hear :star_struck: :nerd_face: :star_struck: :nerd_face: :star_struck:

Interesting, because I didn't have any problems with enabling sanitizers. Well, caused by ModSecurity build scripts, at least :)

I will try to have the leak check on our QA as well ;) 💯 :sunglasses:

Yep, no leaks! 👍🏻

Good to hear :star_struck: :nerd_face: :star_struck: :nerd_face: :star_struck:

Interesting, because I didn't have any problems with enabling sanitizers. Well, caused by ModSecurity build scripts, at least :)

I will try to have the leak check on our QA as well ;) 💯 :sunglasses:


Account for multple minutes

Overview
This branch is one of two changes needed to resolve #16. In order to associate one meeting with multiple minutes, we're now saving all minutes documents found under each event.

Connects: #16
Related councilmatic PR: https://github.com/Metro-Records/la-metro-councilmatic/pull/1154

Demo

Notes
This should most likely be merged in after the corresponding pr in the councilmatic repo since this would introduce a template bug in councilmatic if merged in beforehand..
Testing Instructions
** Note: this PR will need to be tested locally, since it involves tandem changes with councilmatic. Also, these instructions should be performed in the councilmatic container unless otherwise stated.

Pull down this branch, and check the updated README to get this working with the corresponding councilmatic branch.
Make the described changes in councilmatic and build the container.
Run an events scrape large enough to capture an event with multiple meeting minutes

I ran the following command to make sure I got the event described in the issue: docker-compose run --rm scrapers pupa update lametro events window=180 --rpm=0. This will take several minutes.

Find a meeting with multiple minutes

I used the meeting described in the issue.
Confirm that the event has multiple minutes files.

@antidipyramid @hancush I believe what we've got here now should satisfy the two points brought up in this comment on the issue. Lmk if I've missed or misunderstood anything!


Seems this project is not not maintained any more, any alternative for it?

Seems this project is not not maintained any more, any alternative for it?

+1

Hey all,
The reason this project hasn't been maintained recently is conflicting approaches to icons. I no longer believe that an icon font is the best approach for using icons with Google Maps, due to the loading of all icons as part of the font. Icon fonts seem to be more of a developer utility that do not benefit the end user.
The alternative is using SVGs as icons directly in the Google Maps marker object. Google has launched Material Design Icons and there is a growing community providing better source SVG icons with standardised base sizes.
I don't have the time to create the depth of icons available in these projects, and I believe that these are better icons to be used on maps regardless because of their better rendering at smaller sizes.
I welcome any feedback as to the future of Map Icons, I have been humbled by the community's adoption of a small side project and look forward to how you see Map Icons going forward.

You could start by adding this notice to the readme and website.

@aristidesfl I've updated the README.

So there is no easy way of achieving the same styles without having to fiddle manually with svg path?

@aristidesfl Not sure what you mean. There are multiple solutions for using SVGs with Javascript. The concern is loading a entire font file when only a select few icons are actually being used, not the best case for a user's data. The icon font will remain as is for use in your projects as you require.

I mean that this project provides the combination of a markers with icons. Can you name one other solution you would recommend instead?

@aristidesfl The markers are just SVG path notation and are supported by vanilla Google Maps, easily customisable with any vector app. Icons can be used as is (icon font) or you could bring in any SVG icon and include that in the marker object in the custom label.
I am stating that I will not be creating new icons going forward. I am open to including a utility for the use of any SVGs with Google Maps Markers using the custom label class created for Map Icons.

Hi @scottdejonge thanks for this great project. I love the fact that the icons are named according to google place type names, it makes dynamic usage possible.
Can I have your permission to make a PR with your icons to https://materialdesignicons.com/? That would allow these icons being used as SVG icons and directly importable through libraries like https://github.com/conundrumer/material-ui-mdi


Scrape all archive of KBR newspaper

Description
KBR has a large archive of newspapers in East Circassian language
The newspaper is being published since 2007 in pdf format.
Difficulties
There is no archive folder to download all the pdf files at once.
Solution

Contact the newspaper in the hope to provide us with a link to an archive.
Web scraping the pdf files from the website

Once all the newspaper has been acquired:

if this is done with web scraping, then the code to scrape the newspapers from the website should be added to ./src/extraction/kbd/ap
The pdf files should be added to ./data/raw/kbd/ap

#110


Changes design for common popup

Description
Fixes #1580
Notes (out of scope, known isues, hints for reviewing code, ...)  (optional)
...
Test cases

[ ] Case 1:

Given I am the usual user
When I go to this page
And I click on leave group button
Then I see changed design for popup

[ ] Case 2:

Given I am the usual user
When I go to this page
And I select first row
And I click on delete button
Then I see changed design for popup

[ ] Case 3:

Given I am the usual user
When I go to this page
And I click on "Sub-groups" tab
And I select first row
Then I click on delete button
Then I see changed design for popup

The link of "case 3" is wrong.

Is the default selection (with its blue contour) on purpose?

By default blue, but it was red in prev version as well, kind very danger operation I think

I meant: do we want a default selection? I am not sure that is good idea (in terms on design at least, it is not great ;-))

Is the default selection (with its blue contour) on purpose?

By default blue, but it was red in prev version as well, kind very danger operation I think

I meant: do we want a default selection? I am not sure that is good idea (in terms on design at least, it is not great ;-))

Ah, you mean focus state, okay I'll remove it then

Is the default selection (with its blue contour) on purpose?
At the end, the button borders are not sharp. Is there a way to improve that? (I think you've already fixed that somewhere else)

I've removed focus border. Do you still have second effect? I can't reproduce it

Is it on purpose that the arrow is blue while the popup in white?

Is it on purpose that the arrow is blue while the popup in white?

Changed to white


Fix migration_type default value

The default value for migration_type was set as timestamp, but all documentation says that is sequential. So, there was some people that was unaccustomed with this problem than they not find where is wrong.

I don't see the documentation saying that sequential is the default ...

I'm so sorry.  Mabe I thought that because CI2, I dont'n know. Then I just read first part of migration_type comments and assumed sequential as default.
|   'sequential' = Default migration naming (001_add_blog.php)
|   'timestamp'  = Timestamp migration naming<PHONE_NUMBER>4401_add_blog.php)
|                  Use timestamp format YYYYMMDDHHIISS.
Agains, sorry about this!


Add Gtk.Window::fullscreened

This adds the fullscreened property to Window. It's implemented using gtk_window_fullscren and gtk_window_unfullscreen.

Looks good so far. Let me know when this is ready for review.

After trying it in C++ and getting the same exact bug I was trying to debug (fullscreening momentarily and then returning to normal), I think it's a problem with how I'm using it.

Looks good!


Update plugins-list-en.md

Cant merge this patch because some of this code was already merged by prev patch


SPIKE - Unreliability of sync functionality, monitor - all repo's (Murali, Colin 8 sp's)

https://docs.google.com/spreadsheets/d/1Mu6LMfSxnSquEcwA2AKRyYLRlTqfi5Vz4MCa585wyec/edit?usp=sharing
https://app.diagrams.net/#G1vNM857gaWonKK2kXvVIoCsH4OxqhWCaz


Add click and scrollIntoView abstractions

It would be nice to abstract the click and scrollIntoView calls a little, so that code such as
(() => browser.executeScript('arguments[0].scrollIntoView();', this.locatorButton.webMail))
(() => browser.executeScript('arguments[0].click();', this.locatorButton.webMail))

could be rewritten as
(() => browser.scrollIntoView(this.locatorButton.webMail))
(() => browser.click(this.locatorButton.webMail))

If there's interest in and support for this, I'd be happy to contribute more (unit tests, etc.), if needed, to bring this to completion.

I signed it!

@simonua Remember scrollIntoView can have an optional parameter to align it to top or not, it should be on your abstraction too as it is very useful to use that parameter 👍

Good point, @Pablodotnet. I pushed an update. I'm thinking this may cover:

That's perfect! Hope this pull request get merge soon 💯

@qiyigg, I merged upstream/master into my master and the CLA dropped out. Could you please advise what should be done? Also, is there merit to this PR, please?

To be honest, I didn't get it. Is an enhancement of ElementFinder.scrollIntoView() better?
Moreover, I don't think browser.click() is better than ElementFinder.click(), it looks like an anti-protractor design for me.

@simonua in general, you shouldn't use any "merge" command. You should use "rebase" instead.
I guess you merged other's comment into your comment and now it is contributed by two people and CLA doesn't like it.
For this PR itself. I don't fully understand the purpose of doing so.
what's the purpose of using this:
(() => browser.executeScript('arguments[0].click();', this.locatorButton.webMail))
rather than:
this.locatorButton.webMail.click()
Usually we use browser.executeScript when we want to get the "return value"

proposed browser.click()
As my understanding, your intention is to click some DOM element which is not clickable by define of WebDriver protocol. I remembered there was some discussion when Selenium decided move to WebDriver around the same issue. Your proposal is the way Selenium 1.0 (Selenium RC) handle clicking, and the major argument at that time was WebDriver no longer allow click invisible element. From e2e testing perspective, I strongly support WebDriver way, if user cannot see the element in browser, there is no reason your test script should click it.

proposed browser.scrollIntoView()
In WebDriver protocol, the interactive with element such as click and sendKeys will scroll into view first. That eliminates the majority usage of your browser.scrollIntoView. Actually, in Selenium, there are already tons of code to make sure the WebDriver protocol got implemented right, for example
https://github.com/SeleniumHQ/selenium/blob/74e584d12ba31bb2e1b61b17a4751402c70c6da6/javascript/atoms/action.js#L601-L619
In my newer project, I use scroll fewer and fewer actually.
Even you still want to introduce that function, I will suggest that put it into ElementFinder. I feel that

this.locatorButton.webMail.scrollIntoView()

is better than
browser.scrollIntoView(this.locatorButton.webMail)

How do you think?

@qiyigg and @awarecan, thank you very much for your feedback. I'll dig into your suggestions a bit into my project to see if I still see as much validity for this PR. I appreciate you!

@awarecan

the interactive with element such as click and sendKeys will scroll into view first. That eliminates the majority usage of your browser.scrollIntoView.

I can't agree with this, personally I struggle with a lot of situations where the test failed because it says "element not visible" or "other element will receive click" and I need to scroll to them using scrollIntoView, that automatic scroll you say fails a lot of times.

@Pablodotnet, I've had similar experiences, which motivated me to create the abstraction.

I don't think I am opposed to putting it with ElementFinder. That would still appear to be a semantic way, just a different angle. Would that change gain support?


Missing variants in Multi-period DASH VOD with mixed codecs

Have you read the FAQ and checked for duplicate open issues?
yes
If the problem is related to FairPlay, have you read the tutorial?

n/a
What version of Shaka Player are you using?

4.9.4 and main
Can you reproduce the issue with our latest release version?
yes
Can you reproduce the issue with the latest code from main?
yes
Are you using the demo app or your own custom app?
custom
If custom app, can you reproduce the issue using our demo app?
yes
What browser and OS are you using?
LG TV WebOS / Chrome 87 (reproducible with other HEVC supported devices).
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
LG UQ7590PUB 03.34.00
What are the manifest and license server URIs?

Can send via email.
What configuration are you using?  What is the output of player.getConfiguration()?

preferredVideoCodecs = ['hvc'];
preferredAudioCodecs = ['mp4a'];
What did you do?

Configure the player with preferredVideoCodecs = ['hvc'];.

Play a DAI DASH VOD manifest with 2 pre-roll periods and 1 content period.

All periods have HEVC representations, but the pre-roll HEVC representations use the hev format and the content period uses the hvc format. For example:
Pre-roll representation
<Representation width="1280" height="720" frameRate="24000/1001" mimeType="video/mp4" codecs="hev1.2.4.L93.90" id="6" bandwidth="1998000">
Content representation
<Representation width="1280" height="720" sar="1:1" mimeType="video/mp4" codecs="hvc1.2.4.L93.90" id="14" bandwidth="2585563">

The content period has total of 8 hvc representations, with resolution heights of 240, 360, 544, 720, 1080, 1440, 2160 @ 10mb, 2160 @ 17mb.

What did you expect to happen?
I would expect the player to create 8 video variants, one for each hvc representation in the manifest.
What actually happened?

The player only creates 3 video variants, which include the 240, 544, and 2160 @ 17mb heights.

When setting preferredVideoCodecs = ['hev']; (instead of  hvc) with the same manifest, 17 video variants are created. 11 for the hev1.2 profile representations and 6 for the hev1.1 representations. Since period combining matches hev and hvc, I would expect preferredVideoCodecs = ['hvc'] to provide something closer to the preferredVideoCodecs = ['hev'] output.

Are you planning send a PR to fix it?
yes

Just to note, for DVHE codec, mixed with DAI HEV codec for ads, you must set preferredVideoCodec to "dvhe" to get the proper bitrate ladder and selection of desired codec.   As Will has pointed out above, this was not the case for DAI content when we are targeting HVC instead of DVHE.

@willdharris  you continue working on this?


Include investment transactions for csv export

Fixes #383, mimicking behavior for get_transactions_json: https://github.com/mintapi/mintapi/blob/1ea57748ff891d55ba1e7275a60d1214a67622c5/mintapi/api.py#L429

Thanks for your contribution! Requesting a review from @burkematthew as I believe he is recently familiar with this area of code, but please correct me if I'm wrong :)

@mrooney yes I'll review tomorrow and leave feedback!

@brikeohane just sending a follow-up about the above comment.  Thanks!

Bump @brikeohane


feat(api): releases from DevDay; assistants, multimodality, tools, dall-e-3, tts, and more

Includes a version bump to v1.1.0

This may not be inappropriate place to post question, though...
import openai
client = openai.Client(api_key="[REDACTED]")
assistant = client.assistants.create(
     name="Math Tutor",
     instructions="You are a personal math tutor. Write and run code to answer math questions.",
     tools=[{"type": "code_interpreter"}],
     model="gpt-4-1106-preview"
)

NotFoundError: Error code: 404 - {'error': {'message': 'Invalid URL (POST /v1/assistants)', 'type': 'invalid_request_error', 'param': None, 'code': None}}

I tried with pip install -U git+https://github.com/openai/openai-python.git@637556b8c03d24cb63df97d019c72823e2b04f63, please let me know if I'm doing something wrongly.

This may be inappropriate place to post question, though... Just tried to use beta.assistants API along with this pull request, following guides available on the pages like ASSISTANTS - Tools - Code Interpreter
import openai
client = openai.Client(api_key="[REDACTED]")
assistant = client.beta.assistants.create(
     name="Math Tutor",
     instructions="You are a personal math tutor. Write and run code to answer math questions.",
     tools=[{"type": "code_interpreter"}],
     model="gpt-4-1106-preview"
)

NotFoundError: Error code: 404 - {'error': {'message': 'Invalid URL (POST /v1/assistants)', 'type': 'invalid_request_error', 'param': None, 'code': None}}

I tried with pip install -U git+https://github.com/openai/openai-python.git@637556b8c03d24cb63df97d019c72823e2b04f63, please let me know if I'm doing something wrongly.
(Maybe I'm just trying it too early?)
(Updated: Ah, I just read "We'll begin rolling out new features to OpenAI customers starting at 1pm PT today." somewhere on Discord. I'll try it again one hour later. Sorry!)

I'm still getting this error. Using v1.1.0

There are several retreival instead of retrieval, FYI!

Thanks @barrenechea! Looking into it.

Just FYI, openai-node seems to have similar issue(retreival instead of retrieval). https://github.com/openai/openai-node/blob/d4d46873ce3bf9193c8328cc019057fbb124f783/src/resources/beta/assistants/assistants.ts#L158

Yes both the Node SDK and the Python SDK are generated from the same source, the OpenAI openapi spec. Fixes coming to both shortly.


enhancement: deleting chat should not scroll back to top

Hi,
When deleting the chats i used to investigate the bugs I found earlier today I noticed that deleting messages was a bit annoying because it automatically scrolls back to the top. Is it possible to avoid this by remembering the relative scroll level?

It's not possible.


Transparency in PlotPosteriorComparison

FaceAlpha is managed in a different way starting Matlab R2014b
This checks the version and uses the appropriate way
Also: PlotPosteriorComparison can now take an optional input argument to plot condition-labels instead of numbers.

Hi, thanks for the contribution! I have one question for you:
On lines 15 to 20, you renamed PlotPosteriorComparison to PlotPosteriorComparisonWanja, which I think will break existing code that uses the original name. Any reason for the renaming?

Hi,
No! That was just a leftover from testing. Sorry for the mess, I pushed a new version.
I also adjusted ColorWorkingMemoryExperiment.m, which should fix #29 .


Implementation of option for UASTs processing with algorithms

Codecov Report

Merging #32 (c706f9a) into master (5169d98) will decrease coverage by 0.20%.
The diff coverage is 57.21%.

@@             Coverage Diff              @@
##             master      #32      +/-   ##
============================================
- Coverage     47.63%   47.43%   -0.21%
- Complexity     3881     3916      +35
============================================
  Files          1435     1448      +13
  Lines         20785    21068     +283
  Branches       3875     3921      +46
============================================
+ Hits           9901     9993      +92
- Misses         8783     8948     +165
- Partials       2101     2127      +26

Impacted Files
Coverage Δ

...c/main/java/org/uast/uast/algorithms/Carrying.java
0.00% <0.00%> (ø)

...c/main/java/org/uast/uast/algorithms/Greening.java
0.00% <0.00%> (ø)

...org/uast/uast/generated/tree/java/JavaAdapter.java
85.71% <ø> (ø)

...ast/uast/generated/tree/java/rules/Matcher243.java
50.00% <ø> (ø)

...ast/uast/generated/tree/java/rules/Matcher244.java
18.18% <0.00%> (-65.16%)
:arrow_down:

...ast/uast/generated/tree/java/rules/Matcher246.java
50.00% <ø> (ø)

...ast/uast/generated/tree/java/rules/Matcher253.java
33.33% <ø> (-16.67%)
:arrow_down:

...ast/uast/generated/tree/java/rules/Matcher254.java
93.33% <ø> (-2.50%)
:arrow_down:

...ast/uast/generated/tree/java/rules/Matcher256.java
94.44% <ø> (-1.86%)
:arrow_down:

...g/uast/uast/generated/tree/java/rules/Rule140.java
12.76% <0.00%> (-76.82%)
:arrow_down:

... and 47 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


#1686 Candidate details

What's included?
The Candidate Details screen is linked to from some places in the system but not others. Some Candidate names are a link to the profile and we would like to make all link to the profile and open in a separate tab.

[x] Tasks - Independent Assessments - the candidate name is a link and opens the candidate details screen but this needs to open in a new tab.
[x] Tasks - Character checks - Make the Name link to the candidate details and open in a new tab
[x] Tasks - Selection day - Candidates tab make the candidates details open in a new tab
[x] Stages - Make the candidates details open in a new tab
[x] Applications - Make the Name link to the candidate details and open in a new tab

Who should test?
✅ Product owner
✅ Developers
✅ UTG
How to test?
Click on a candidate name link on Character checks, Selection day, Stages, Applications and see if it opens candidate details in a new tab
Risk - how likely is this to impact other areas?
🟢 No risk - this is a self-contained piece of work
Additional context
Include screen grabs, video demo, notes etc.
https://user-images.githubusercontent.com/79906532/180766632-9066f5bb-6ffb-49aa-af92-2a4ecbe570f3.mov
Related permissions

No permission changes required

PREVIEW:DEVELOP
can be OFF, DEVELOP or STAGING

@HalcyonJAC @JeremykJAC  - In UT teams are expecting/asked for the following:

[ ] All candidate reference numbers to open into a new tab - Currently, when you click the reference on the platform it loads a new page on the same page

[ ] Panel packs page - Candidates' names don't open in a new tab when they want to view their application - reference and their name

[ ] On Candidates' profiles users wanted their applications to open in a new tab on this page


Add support for F# template

Hi Team,
Thanks for the wonderful product!
I was wondering whether the azure-nextgen is stable enough to add support for the F# template.
As of today, I think the only C# is available.
$ pulumi new azure-nextgen-fsharp
error: template 'azure-nextgen-fsharp' not found

Did you mean this?
        azure-nextgen-csharp

Yes, we should definitely do this!


chore(all): update cdk version

periodic task

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 95738fd04531aaa7d340713ccb4e3ca50c12f4eb
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 725b5d58047b336c92ec8aa4c924425c51393d2f
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 81f4e875f637a43131ff981851c97dfc88e45b94
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Start over


Incorrect IoC file name?

Thanks for providing this data to the general public.
I believe that the file /2023/12/17-12-2923 should actually be called /2023/12/17-12-2023.

Thanks for letting me know.
Fixed it.


Proposal: Physical storage adapter

Would this be an implementation that uses System.IO.File and such?

@drusellers Apologies, didn't see this. Yes it will be.

@drusellers It's available in v3.2.0 if you're wanting to use it :+1:


LIBITD-1549. Initial implementation of "batch_stats"

Added "batch_stats" command to CLI, which generates statistics about
a batch or batches.
https://issues.umd.edu/browse/LIBITD-1549

tests passed and verified working as expected


Add tests for @breeffy/icons package

Original tests from react-native-fontawesome were successfully passed.

All tests were successfully passed.


Ribbon: Remove tab "twinBasic Test"

Remove the code for the tab "twinBasic Test".
This is a leftover from the template and is no longer needed.

Remove also associated code.

Published with release <IP_ADDRESS>


What is the default Content-Type when response.body is set to a string?

In the docs I read:

response.body=
Set response body to ...
String
The Content-Type is defaulted to text/html or text/plain ...

But which is it? text/html or text/plain? Under which circumstances? How do I configure it?

https://github.com/koajs/koa/blob/65f9c939e173ff2fab82ee9229a2213690959426/lib/response.js#L158
This checks:

Is there a Content-Type set?
If not: is the body a string?
If so: is there whitespace followed by <?
If so: set to HTML, else plain text.

Followed by checks in case the body is a Buffer or Stream instance.

Asked and answered, but if you disagree please reopen this ticket (or create a new one).


⚠ ClamAV has degraded performance

In 4fe6ab9, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 70 ms

Resolved: ClamAV performance has improved in 5caef19.


Enforce consistent constraint names in Python, to avoid a Mac App crash.

The following code modified from the tutorial results in a "hard crash" on Mac OSX.
container.constrain(button.LEFT == container.LEADING + 50)  # Inconsistent naming

And this is the gist of the error:
2015-11-09 22:42:58.534 Python[34679:193286] An uncaught exception was raised
2015-11-09 22:42:58.534 Python[34679:193286] *** +[NSLayoutConstraint constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant:]: A constraint cannot be made between a leading/trailing attribute and a right/left attribute. Use leading/trailing for both or neither.

So I wondered if it would be possible to catch the names in python code and throw an exception there instead, so that the back-end doesn't crash.

Thanks for the report. AFAICT, it should be possible.

Toga has moved away from constraint-based layout, so this is no longer an issue.


Update All Releases Page to include links to Source and Docs

Right now, this page https://azure.github.io/azure-sdk/releases/latest/all/index.html and all other "all" pages, don't have links to source and docs.  We have a customer request to add source and docs links there.
This would be good to include from the perspective of an Azure developer, they want to find packages, source, and docs for all SDKs, no just the new ones.
This will be a manual task and can be pulled from the SDK inventory work that we have done.
Tasks:

[x] 1. Merge both "all" and "latest" into a single csv file solution and type each item with Data, Mgmt, or blank. @weshaggard

[ ] 2. Manually update the "non New" SDKs with links to source and docs pulled from SDK Inventory. @tzhanl

azsdke2e

Task 1 done with https://github.com/Azure/azure-sdk/pull/1591.

This is complete.


Localization and internationalization in android

Article checklist
Attention
Our Peer Reviewer and Content Moderator teams do NOT provide any revisions services. All revisions and edits should be completed on your own forked repo (as to not take up room in the queue) in order for our team to review them all in a timely manner.
ANY ARTICLE SUBMITTED WITH GLARING ERRORS WILL BE IMMEDIATELY CLOSED.

As a rule of thumb - please be sure to only submit articles (pull requests) that are fully polished and ready to be published. Be sure to go through our resources documents for extra and 3rd party (vetted) resources to help improve overall technical writing.

Pre-submission checks

Please ensure that you have only one open topic suggestion (issue) + in-review article (linked pull request) at a time. This will ensure that we complete the review process in a timely manner from inception to publishing

If you have not already, please go over our Resources Page for more tips and tricks on how to improve your overall technical writing so reviews are swifter, increase the chance of a payout and provide more value to our readers.

For first-time contributors and for more details on our submission guidelines, see our Contributing Guidelines.

Formatting and structure checks

[x] Have you used the correct folder and file structure? - see Contribution Guidelines

[x] Is your article properly formatted in Markdown? - see Github Markdown guide

[x] Have you used our preferred heading structure? - H3 (###) and up

[x] Does your article follow any of the suggested structure formats? - see example formats

[x] Is your article over 750 words? - Tool: Wordcounter.net

[x] Is the article you are submitting an in-depth and unique article? Does it go beyond what is in the official docs and what is covered in other blog sites. See these articles as examples.

[x] Does your article provide enough value and detail about your topic? - Articles should be clear, accurate, and fully explained.

[x] Can your article be understood by beginners? - Assume the audience is smart but has no prior exposure to the common terminology in your article.

[x] Have you included a hero image that is 600x400 pixels, under 300KB in size, and have the copyright to use it? - Tools: Pixlr Image Editor for resizing and Unsplash for Creative Commons images

Grammar & plagiarism checks

[x] Have you spellchecked and grammar checked your article? - Tools: Write&Improve - ProWritingAid - Grammarly
[x] Please place your article through a 3rd party plagiarism checker. We suggest using Quetext, this tool is free and has a daily limit. We typically accept articles with 10% or less.
[x] Have you checked your article for readability? - Tool: Hemmingway
[x] Have you added sources for quotes and images that aren't yours?

Technical checks

[x] Are your code snippets properly formatted for syntax highlighting - see Syntax guide
[x] Have you checked your code runs correctly and you've highlighted all necessary dependencies for installation?
[x] Are the software programs and packages you're highlighting in your article up to date, using current versions and not deprecated?

Topic suggestion this closes

Remove the backticks and add the issue number below to link and close your Topic Suggestion (issue) when your article has been published (PR has been merged). See this video for more details.

This closes #5011

Finally, delete the article checklist notes in blockquotes and submit your PR. We look forward to reviewing your article.

Hello @BrianaNzivu i have made the requested changes
Thanks

Hey @nia-vee 👋 .
This article still has a lot of grammatical errors. Please cross-read it and use Grammarly to go through it to avoid closure of the closure of this PR.
Please note: Our Peer Reviewer and Content Moderator teams do NOT provide any revisions services. All revisions and edits should be completed on your own forked repo (as to not take up room in the queue) in order for our team to review them all in a timely manner.

Hey @nia-vee 👋🏾.
Everything OK?
Need some help?

Hello @BrianaNzivu Have sent a message on slack.
Thanks in advance and am looking forward to get some help..

Tech review done.

Plagiarism check done

Hello @WanjaMIKE have given the clear definition
Thank you.

Hello? @WanjaMIKE
Kindly don't remove the link i have fixed it i think i had included the URl wrongly but i have check on it is now working.
Thank you

@nia-vee Kindly, take note of the edits to improve in your future submission.

Merged #5554 into master


[WIP] Upgrade to netcoreapp3.1

:x: Build AElf <IP_ADDRESS>55 failed (commit https://github.com/AElfProject/AElf/commit/e146bdfe7a by @rosona)

:white_check_mark: Build AElf <IP_ADDRESS>56 completed (commit https://github.com/AElfProject/AElf/commit/648298396b by @rosona)

:white_check_mark: Build AElf <IP_ADDRESS>72 completed (commit https://github.com/AElfProject/AElf/commit/abb0687b45 by @xiangxingxing)

:x: Build AElf <IP_ADDRESS>07 failed (commit https://github.com/AElfProject/AElf/commit/05fd5d52bb by @xiangxingxing)


refactor: add various comments throughout the code, change argument/type names to more descriptive, add explicit types

just various comments while I was learning a code
I think non-ideal comment is better than no comments at all

answer on https://github.com/purescript-halogen/purescript-halogen-vdom/pull/38#issuecomment-629367556
ok, I agree that it's not good to change the name of arguments on this stage
but what about:

adding types
adding comments
adding data STObject' which is like STObject but without region argument (allows to add types to some function, before it complained about escaped scolems)

I have noticed @thomashoneyman mentioned that during halogen v5 refactoring the
The type variables have been renamed to full words in the component / query / etc. type signatures. Maybe this will help, maybe not - feedback is welcome and appreciated!

maybe longer type variables are not so bad idea

also, halogen is using long arrows everywhere ->, halogen-vdom is using utf8 arrows everywhere →


now the cloud can be resized

Hi this pull request is to allow for dynamic width and height parameters.
See demo page - now you can change the container dimensions and jqcloud will refresh

You don't need to destroy and rebuild.
jQCloud already has a dynamic size mode http://mistic100.github.io/jQCloud/demo.html#autosize
Try to use it.

Hi thanks for the hint

autoResize=true didn't work for me. I had to modify this directive and add a listener for the window resize event which does:
var words = [];           $.extend(words,$scope.words);           $elem.jQCloud('destroy');           $elem.jQCloud('initialize');           $elem.jQCloud('update', words);

well it works...
on the example file :
  <style>
    html, body { width: 100%; height: 100% }
    #cloud { width: 50%; height: 80% }
  </style>

  <jqcloud words="words" id="cloud" colors="{{colors}}" steps="7" font-size="{from:0.09, to:0.04}" auto-resize="true"></jqcloud>

it's related to #9 I think

In my page this did not work. I'm not sure if its related to a more complicated parent structure (it is placed inside a boostrap grid cell) under other div's which are all sized based on percentage.
I also had issues at first even getting this to render at all. If hight was set statically, I got something to show but it was much smaller than the Div. With a non-static hight it rendered nothing. The issue was related to the word cloud being in a tab, but I've used a delay and ng-if to force a delay in the construction and it renders correct but resize still did not work.
Anyway, I have a resize fix in my fork that listens to the resize event borrowing from a strategy I've seen in other directives. It works for me but not sure if you want to consider it as a PR. For now this is only useable for me on my fork. Otherwise great component!

I updated the example


Installation

I did the following:

Added gem 'simplemde-rails' to Gemfile
Executed bundle install
Executed rails g simplemde:install
Included the assets with //= require simplemde.min and @import "simplemde.min"; and checked to make sure they were there.
Added var simplemde = new SimpleMDE(); to my JS and made sure it was there.

It doesn't seem to be working though—it doesn't change anything about textareas on any pages.
Is there anything else I need to do? I'm pretty new to Rails, so I greatly appreciate any help. 😁

@jrdnbwmn Would you mind sending me a copy of your fresh rails demo to me? My email: knh190 at hotmail.com


[Feature Request]: if we can support paste file or folder which copied from Desktop

VSCode Version: Code 1.8.1 (ee428b0eead68bf0fb99ab5fdc4439be227b6281, 2016-12-19T14:49:23.350Z)
OS Version: Windows_NT ia32 6.1.7601
Extensions:

Extension
Author
Version

html-snippets
abusaidm
0.0.18

vscode-html-css
ecmel
0.0.30

format-php
Kasik96
1.1.2

vscode-JS-CSS-HTML-formatter
lonefy
0.2.2

debugger-for-chrome
msjsdiag
2.4.1

Steps to Reproduce:

open vsc
copy file or folder from desktop
it can`t paste to vsc, it seems only support copy/paste from vsc to vsc
maybe this case is not a issue ? it`s from vsc design that only support copy/paste from vsc to vsc ?

Thank u.

Duplicates #17564


PULSAR installation documentation.

I am looking for how to install and use PULSAR for FIM monitoring ,
The repo has been changed three times from the looks to what it is now.   And from the look it looks like this has gone to the standalone app called hubble , but I don't see anyway to run, execute , or configure pulsar in hubble.
Here is the documentation , let me know which should I be following for this.
https://hubblestack.readthedocs.io/en/latest/contents/fim_pulsar.html
Has this not stepped away from Salt like Hubble has?  I am not sure.
Anyway , let me know please.
Thanks

If you're using our packages, you should have everything necessary. You just need to uncommend the pulsar.process schedule entry in the config..
By default, it will use our watch config from hubblestack_data. You can override that file or modify to suit your needs. Should "just work" though. Keep me posted if you run into any issues.


Allow non-anchor links to click through normally

Sometimes main nav links need to be clickable, instead of opening the subnav

:+1: do links always have an href?

I would assume so, If it's opening a subnav it'll be href='#formNav', I just want it to ignore normal links

:shipit:


Fix typo in symbol table size exceeded error message

This commit fixes a typo when reporting an error that the the symbols
table size has been exceeded.
This error was discovered during compaction of large blocks containing extremely long labels and was confusing to troubleshoot without looking at the codebase.
Signed-off-by: Filip Petkovski<EMAIL_ADDRESS>

Thanks!


If channel is already used analogWrite fails.

It would be nice to be able to assign a ledc channel to a pin.
I want to use pin 13 but Channel 0 and 2 are already occupied by another libraries and awGetChannel(13) returns -1.
Is there a workaround / solution?

Yes, by design analogWrite won't work on any pin that has been previously accessed (to avoid conflicts). However, you could try to free up pin 13 in setup ... first by using analogWrite(13, -1); then analogWrite(13, value);


add prekind part and pre counter <- allow skip kindversions from cmdline

Description
What does the PR do?
Adds prerelease part to bumpversion.
So if you want to go from:
running: bumpversion prekind (on  0.12.17) will result in: 0.12.17 → 0.12.17.dev1
running: bumpversion prekind (on 0.12.17.dev1) will result in: Bump version: 0.12.17.dev1 → 0.12.17.rc1
running: bumpversion prekind (on 0.12.17.rc1) will result in Error (since rc is the highest order)
running: bumpversion pre (on 0.12.17.rc1) will result in: Bump version: 0.12.17.rc1 → 0.12.17.rc2 [same for dev]
you can also go to new patch/minor/major from pre-realse version for example:
running: bumpversion minor (on 0.12.17.rc2) will result in: Bump version: 0.12.17.rc2 → 0.13.0
Testing
How was this PR tested?
Checklist

Include reference to internal ticket "Fixes WB-NNNN" (and github issue "Fixes #NNNN" if applicable)

LGTM. Side note: we might want to migrate to bump2version since bumpversion is not supported anymore... I did it for yea-wandb, so should be easy to port here: https://github.com/wandb/yea-wandb/pull/42/files

Yeah I was looking at that as well...


OPDS content could be better

The content on each ebook on the website is very detailed and interesting.. It would be nice if the blurb on the OPDS was as detailed, or indeed used the same text.

Invalid ticket, my ebook reader was not showing the content tag.