Merge branch 'release/v3.1.2' into 'master'

Release/v3.1.2

See merge request in3/c/in3-core!409

.gitlab-ci.yml

@@ -23,6 +23,7 @@ workflow:
 # defines all the stages in the CI, this includes all stages defined inside the included yml files
 stages:
   - build
+  - integration
   - bindings
   - wasm
   - rust

.gitlab/issue_templates/new_issue.md

@@ -0,0 +1,44 @@
+## Summary
+
+(Summarize the bug encountered concisely)
+
+
+## Is there an open issue
+
+Please search if there are open issues (same or related) before creating a new one. 
+
+## What is the expected correct behavior?
+
+(What you should see instead)
+
+## What is the current bug behavior?
+
+(What actually happens)
+
+## Steps to reproduce
+
+(How one can reproduce the issue - this is very important)
+
+
+## Example Project
+
+(If possible or relevant, please create an example project here on [git.slock.it/in3/c](https://git.slock.it/in3/c) that exhibits the problematic behaviour, and link to it here in the bug report)
+
+
+## Relevant logs and/or screenshots
+
+(Paste any relevant logs - please use code blocks (```) to format console output,
+logs, and code as it's very hard to read otherwise.)
+
+## Is there a issue previously reported at sentry?
+
+Please check if the issue is happening at [incubed-core sentry](https://sentry.slock.it/organizations/slock-it/issues/?project=37)
+
+
+## Possible fixes
+
+(If you can, link to the line of code that might be responsible for the problem)
+
+/label ~bug ~reproduced ~needs-investigation
+/cc @project-manager
+/assign @qa-tester

.gitlab/merge_request_templates/new_merge_request.md

@@ -0,0 +1,54 @@
+## Merge request checklist
+
+Check if your MR fulfills the following requirements:
+
+- [ ] Tests for the changes have been added (for bug fixes / features)
+- [ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)
+- [ ] Build was run locally
+- [ ] Gitlab CI pipeline is green
+- [ ] Lint has passed locally and any fixes were made for failures
+- [ ] Format check clang-format, (ran [format_all.sh](https://git.slock.it/in3/c/in3-core/-/blob/develop/scripts/format_all.sh))
+- [ ] Check for private keys or login info and remove them
+- [ ] An example has been added or an existing one has been updated/reviewed if needed (bug fixes / new features / signature changes)
+- [ ] Ran all the examples in your local machine. (ci doesn't run them)
+- [ ] CHANGELOG.md has been updated. Add one if it does not have it. Add a line per MR
+- [ ] Code coverage badge was updated. Add one if it does not have it.
+
+
+## Merge request type
+
+Do not submit updates to dependencies unless it fixes an issue. also try to limit your pull request to one type, submit multiple pull requests if needed. 
+
+Check the type of change your MR introduces:
+- [ ] Bugfix
+- [ ] Feature
+- [ ] Code style update (formatting, renaming)
+- [ ] Refactoring (no functional changes, no api changes)
+- [ ] Build related changes
+- [ ] Documentation content changes
+
+
+## What is the current behavior?
+Describe the current behavior that you are modifying, or link to a relevant issue.
+
+Issue Number: N/A
+
+
+## What is the new behavior?
+Describe the behavior or changes that are being added by this MR.
+
+-
+-
+-
+
+## Does this introduce a breaking change?
+
+- [ ] Yes
+- [ ] No
+
+If this introduces a breaking change, please describe the impact and migration path for existing applications below.
+
+
+## Other information
+
+Any other information that is important to this MR such as screenshots of how the component looks before and after the change.

.vscode/launch.json

@@ -164,6 +164,13 @@
             "program": "${workspaceFolder}/build/test/test_recorder",
             "cwd": "${workspaceFolder}/build"
         },
+        {
+            "type": "lldb",
+            "request": "launch",
+            "name": "run request test",
+            "program": "${workspaceFolder}/build/test/test_request",
+            "cwd": "${workspaceFolder}/build"
+        },
         {
             "type": "lldb",
             "request": "launch",

c/ci-analyse.yml

@@ -33,7 +33,7 @@ clangcheck:
   extends: .only_full
   allow_failure: false
   tags:
-    - short-jobs
+    - long-jobs
   script:
     - mkdir _build
     - cd _build

c/ci.yml

@@ -267,17 +267,17 @@ examples_macos:
 
 
 integration_longrun:
-  stage: test
+  stage: integration
   extends: .only_release
   trigger:
     project: qa/long-run
     strategy: depend
     branch: develop
 
-integration_browsertest:
-  stage: test
+integration_browser:
+  stage: integration
   extends: .only_release
   trigger:
     project: in3/ts/browser-test
     strategy: depend
-    branch: 2-release-branch-test
+    branch: develop

c/src/cmd/in3/main.c

@@ -90,7 +90,7 @@
 void show_help(char* name) {
   recorder_print(0, "Usage: %s <options> method <params> ... \n\
 \n\
--c, -chain     the chain to use. (mainnet,kovan,tobalaba,goerli,local or any RPCURL)\n\
+-c, -chain     the chain to use. (mainnet,ewc,goerli,local or any RPCURL)\n\
 -a             max number of attempts before giving up (default 5)\n\
 -rc            number of request per try (default 1)\n\
 -ns            no stats if set requests will not be part of the official metrics and considered a service request\n\
@@ -359,7 +359,6 @@ bytes_t* get_std_in() {
 // convert the name to a chain_id
 uint64_t getchain_id(char* name) {
   if (strcmp(name, "mainnet") == 0) return CHAIN_ID_MAINNET;
-  if (strcmp(name, "kovan") == 0) return CHAIN_ID_KOVAN;
   if (strcmp(name, "goerli") == 0) return CHAIN_ID_GOERLI;
   if (strcmp(name, "ewc") == 0) return CHAIN_ID_EWC;
   if (strcmp(name, "ipfs") == 0) return CHAIN_ID_IPFS;

c/src/core/client/context.c

@@ -161,8 +161,9 @@ in3_ret_t ctx_set_error_intern(in3_ctx_t* ctx, char* message, in3_ret_t errnumbe
       dst = _malloc(l + 1);
       strcpy(dst, message);
     }
-    ctx->error           = dst;
-    error_log_ctx_t sctx = {.msg = message, .error = -errnumber};
+    ctx->error = dst;
+
+    error_log_ctx_t sctx = {.msg = message, .error = -errnumber, .ctx = ctx};
     in3_plugin_execute_first_or_none(ctx, PLGN_ACT_LOG_ERROR, &sctx);
 
     in3_log_trace("Intermediate error -> %s\n", message);

c/src/core/client/plugin.h

@@ -387,8 +387,9 @@ typedef struct {
 } in3_pay_sign_req_ctx_t;
 
 typedef struct {
-  char*    msg;   /**< the error message. */
-  uint16_t error; /**< error code. */
+  char*      msg;   /**< the error message. */
+  uint16_t   error; /**< error code. */
+  in3_ctx_t* ctx;   /**< ctx . */
 } error_log_ctx_t;
 
 #endif

c/src/core/util/data.c

@@ -184,6 +184,7 @@ int d_bytes_to(d_token_t* item, uint8_t* dst, const int max_size) {
         return 1;
       case T_INTEGER:
         val = item->len & 0xFFFFFFF;
+        l   = 0;
         if (max == -1) max = val & 0xFF000000 ? 4 : (val & 0xFF0000 ? 3 : (val & 0xFF00 ? 2 : 1));
         for (i = max < 3 ? max : 3; i >= 0; i--) {
           if (val & 0xFF << (i << 3)) {
@@ -198,6 +199,10 @@ int d_bytes_to(d_token_t* item, uint8_t* dst, const int max_size) {
             return l;
           }
         }
+        if (l == 0) {
+          memset(dst, 0, max);
+          return 1;
+        }
         break;
       default:
         break;

c/src/third-party/sentry-native/external/crashpad/third_party/lss/lss/README.md

@@ -0,0 +1,137 @@
+# Linux Syscall Support (LSS)
+
+Every so often, projects need to directly embed Linux system calls instead of
+calling the implementations in the system runtime library.
+
+This project provides a header file that can be included into your application
+whenever you need to make direct system calls.
+
+The goal is to provide an API that generally mirrors the standard C library
+while still making direct syscalls.  We try to hide some of the differences
+between arches when reasonably feasible.  e.g. Newer architectures no longer
+provide an `open` syscall, but do provide `openat`.  We will still expose a
+`sys_open` helper by default that calls into `openat` instead.
+
+We explicitly do not expose the raw syscall ABI including all of its historical
+warts to the user.  We want people to be able to easily make a syscall, not have
+to worry that on some arches size args are swapped or they are shifted.
+
+Please be sure to review the Caveats section below however.
+
+## How to include linux\_syscall\_support.h in your project
+
+You can either copy the file into your project, or preferably, you can set up
+Git submodules to automatically pull from our source repository.
+
+## Supported targets
+
+The following architectures/ABIs have been tested (at some point) and should
+generally work.  If you don't see your combo listed here, please double check
+the header itself as this list might be out of date.
+
+* x86 32-bit (i.e. i386, i486, i586, i686, Intel, AMD, etc...)
+* [x86_64 64-bit](https://en.wikipedia.org/wiki/X86-64) (i.e. x86-64, amd64, etc...)
+* [x32 32-bit](https://sites.google.com/site/x32abi/)
+* [ARM 32-bit](https://en.wikipedia.org/wiki/ARM_architecture) OABI
+* [ARM 32-bit](https://en.wikipedia.org/wiki/ARM_architecture) EABI (i.e. armv6, armv7, etc...)
+* AARCH64 64-bit (i.e. arm64, armv8, etc...)
+* PowerPC 32-bit (i.e. ppc, ppc32, etc...)
+* MIPS 32-bit o32 ABI
+* MIPS 32-bit n32 ABI
+* MIPS 64-bit n64 ABI
+
+## API
+
+By default, you can just add a `sys_` prefix to any function you want to call.
+So if you want to call `open(...)`, use `sys_open(...)` instead.
+
+### Knobs
+
+The linux\_syscall\_support.h header provides many knobs for you to control
+the exported API.  These are all documented in the top of the header in a big
+comment block, so refer to that instead.
+
+## Caveats
+
+### ABI differences
+
+Some functions that the standard C library exposes use a different ABI than
+what the Linux kernel uses.  Care must be taken when making syscalls directly
+that you use the right structure and flags.  e.g. Most C libraries define a
+`struct stat` (commonly in `sys/stat.h` or `bits/stat.h`) that is different
+from the `struct stat` the kernel uses (commonly in `asm/stat.h`).  If you use
+the wrong structure layout, then you can see errors like memory corruption or
+weird/shifted values.  If you plan on making syscalls directly, you should
+focus on headers that are available under the `linux/` and `asm/` namespaces.
+
+Note: LSS provides structs for most of these cases.  For `sys_stat()`, it
+provides `struct kernel_stat` for you to use.
+
+### Transparent backwards compatibility with older kernels
+
+While some C libraries (notably, glibc) take care to fallback to older syscalls
+when running on older kernels, there is no such support in LSS.  If you plan on
+trying to run on older kernels, you will need to handle errors yourself (e.g.
+`ENOSYS` when using a too new syscall).
+
+Remember that this can happen with new flag bits too.  e.g. The `O_CLOEXEC`
+flag was added to many syscalls, but if you try to run use it on older kernels,
+it will fail with `EINVAL`.  In that case, you must handle the fallback logic
+yourself.
+
+### Variable arguments (varargs)
+
+We do not support vararg type functions.  e.g. While the standard `open()`
+function can accept 2 or 3 arguments (with the mode field being optional),
+the `sys_open()` function always requires 3 arguments.
+
+## Bug reports & feature requests
+
+If you wish to report a problem or request a feature, please file them in our
+[bug tracker](https://bugs.chromium.org/p/linux-syscall-support/issues/).
+
+Please do not post patches to the tracker.  Instead, see below for how to send
+patches to us directly.
+
+While we welcome feature requests, please keep in mind that it is unlikely that
+anyone will find time to implement them for you.  Sending patches is strongly
+preferred and will often move things much faster.
+
+## Projects that use LSS
+
+* [Chromium](https://www.chromium.org/)
+* [Breakpad](https://chromium.googlesource.com/breakpad/breakpad)
+* [Native Client](https://developer.chrome.com/native-client), in nacl\_bootstrap.c
+
+## How to get an LSS change committed
+
+### Review
+
+You get your change reviewed, you can upload it to
+[Gerrit](https://chromium-review.googlesource.com/q/project:linux-syscall-support+status:open)
+using `git cl upload` from
+[Chromium's depot-tools](https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html).
+
+### Testing
+
+Tests are found in the [tests/](./tests/) subdirectory.  It does not (yet) offer
+100% coverage, but should grow over time.
+
+New commits that update/change/add syscall wrappers should include tests for
+them too.  Consult the [test documentation](./tests/README.md) for more details.
+
+To run, just run `make` inside the tests directory.  It will compile & execute
+the tests locally.
+
+There is some limited cross-compile coverage available if you run `make cross`.
+It only compiles things (does not execute at all).
+
+### Rolling into Chromium
+
+If you commit a change to LSS, please also commit a Chromium change to update
+`lss_revision` in
+[Chromium's DEPS](https://chromium.googlesource.com/chromium/src/+/master/DEPS)
+file.
+
+This ensures that the LSS change gets tested, so that people who commit later
+LSS changes don't run into problems with updating `lss_revision`.

c/src/third-party/sentry-native/external/crashpad/third_party/lss/lss/codereview.settings

@@ -0,0 +1,5 @@
+# This file is used by git cl to get repository specific information.
+CC_LIST: chromium-reviews@chromium.org,mseaborn@chromium.org
+CODE_REVIEW_SERVER: codereview.chromium.org
+GERRIT_HOST: True
+VIEW_VC: https://chromium.googlesource.com/linux-syscall-support/+/