sublime3: open new link does not work

Description
Sublimetext does not open links in the browser selected as Default in the system. The bug reproduces for the package installation without plugins, see the steps to reproduce below. Also, the same bug appears when plugins to open something in a browser are installed, e.g.: "View in Broser", "Open URL", "Clickable URLs".
I have tested the flatpack version of Sublimetext on NixOS and Sublimetext on Debian. Both opens URLs correctly.
I have traced the system calls, execve is called to open links. I reproduced the same buggy  behavior in a python console pasting:
imports os
os.execve("/run/current-system/sw/bin/xdg-open", ["xdg-open", "https://nixos.org"], <environment variable from the Sublimetext console>)

Links are opened correctly using the default system environment:
imports os
os.execve("/run/current-system/sw/bin/xdg-open", ["xdg-open", "https://nixos.org"], os.environ)

To get the environment variable from the Sublimetext console:
Press Ctrl+~ to open the console:
import os
os.environ

Fix
The issue can be fixed in python console removing 'LD_PRELOAD' variable, it looks like it may be the source of the problem. I am kind of stuck here. Any help will be appreciated.
Environment
NixOS: 20.03pre196480.8b46dcb3db5 (Markhor) with default KDE
sublime3: sublimetext3-3211
Steps to reproduce

Create a new file with a text "https://nixos.org"
Right-click the text and select "open https://nixos.org" form the context menu
The link is not opened in the default browser, KIO client is opened instead.

Expected behavior
Link is opened in the default system browser
Additional context
Add any other context about the problem here.
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
sublime3

I never encountered this problem in GNOME. Strace also prints that it uses xdg-open. I tried changing the default web browser to Epiphany but it launched there correctly as well.
The LD_PRELOAD is suspicious. It appears that xdg-open just calls kde-open on KDE, no idea how that works internally. But libredirect caused some issues in the past so maybe it is somehow interacting.
Could you obtain output of running env LD_PRELOAD=… strace -f xdg-open "https://nixos.org"?

Thank you, I am not sure about what log you want to obtain, here are some details:
The output of env int the system console does not contain LD_PRELOAD, it is only in Sublimetext.
'PRELOAD': '/nix/store/najvrr9mppdrgjh529l79w8px36wn58z-gcc-8.3.0-lib/lib64/libgcc_s.so.1:/nix/store/b6fp8g085zyhq02vivdzdirb4mgp5ggi-openssl-1.1.1d/lib/libssl.so:/nix/store/5dn03xfw3wimm78nfpg67p1zj1025sbc-bzip2-<IP_ADDRESS>.1/lib/libbz2.so:/nix/store/gq60l1b9yv2b66m0d6g95anakr1bcbya-libredirect-0/lib/libredirect.so'

xdg-open from the system console works correctly, it opens the default browser. I thought that the bug was in the xdg-open NixOS implementation first, but xdg-open itself works correctly which made me think the bug is in the package.
The output from calling
strace -f xdg-open "https://nixos.org":
execve("/run/current-system/sw/bin/xdg-open", ["xdg-open", "https://nixos.org"], 0x7ffe188bdca0 /* 94 vars */) = 0
....
execve("/run/current-system/sw/bin/kde-open5", ["kde-open5", "https://nixos.org"], 0x2006008 /* 94 vars */) = 0

I meant to run strace on xdg-open with the LD_PRELOAD set. For example using:
env LD_PRELOAD=/nix/store/najvrr9mppdrgjh529l79w8px36wn58z-gcc-8.3.0-lib/lib64/libgcc_s.so.1:/nix/store/b6fp8g085zyhq02vivdzdirb4mgp5ggi-openssl-1.1.1d/lib/libssl.so:/nix/store/5dn03xfw3wimm78nfpg67p1zj1025sbc-bzip2-<IP_ADDRESS>.1/lib/libbz2.so:/nix/store/gq60l1b9yv2b66m0d6g95anakr1bcbya-libredirect-0/lib/libredirect.so strace -f xdg-open https://nixos.org

Or maybe even tracing kde-open5 directly.

xdg-open with LD_PRELOAD does not open site. Here is the trace:
execve("/run/current-system/sw/bin/xdg-open", ["xdg-open", "https://nixos.org"], 0x7ffec641e540 /* 94 vars */) = 0

execve("/run/current-system/sw/bin/kde-open5", ["kde-open5", "https://nixos.org"], 0x64c008 /* 94 vars */) = 0
...
execve("/nix/store/m3la2bcdhzd48h9x5g3mnz9s55c5ipw5-kde-cli-tools-5.16.5/bin/.kde-open5-wrapped", ["/run/current-system/sw/bin/kde-o"..., "https://nixos.org"], 0x15ea008 /* 93 vars */) = 0
...
access("https://nixos.org", F_OK) = -1 ENOENT (No such file or directory)
...
[pid  5178] sendmsg(9, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1P\0\0\0\36\0\0\0\200\0\0\0\1\1o\0\n\0\0\0/KLaunch"..., iov_len=144}, {iov_base="\21\0\0\0https://nixos.org\0\0\0003\0\0\0loca"..., iov_len=80}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 224

I have compared it with the trace without LD_PRELOAD, it contains the following string that the log upper does not have:
[pid 10749] execve("/run/current-system/sw/bin/chromium", ["/run/current-system/sw/bin/chrom"..., "https://nixos.org"], 0x10001c0 /* 93 vars */ <unfinished ...>

Are there any other differences? Could you try removing some entries from LD_PRELOAD to see which one of them is responsible? libredirect might be a good bet.

I'm testing this on Ubuntu.
xdg-open launches other programs which it finds in PATH. Those programs use their own dynamic linker, however LD_PRELOAD makes that dynamic linker to load different version of libc (I think) and just segfaults.
I'm not sure that that is the real reason of the issue, because I'm lacking detailed knowledge of how dynamic linker works.

IIRC libredirect is used to rewrite libc functions (like execve or fopen) that take file paths and rewrite those paths. For instance, /usr/bin/x is replaced by a proper store path.
I actually debugged this quite a bit while fixing another issue several months ago, so I may be able to take a closer look at the issue this weekend.
Regarding the Ubuntu issue: I'm not sure what might've gone wrong there, but I'd try to reproduce this as well :)

Running the command below was enough for me to reproduce the issue:
env LD_PRELOAD=/nix/store/gq60l1b9yv2b66m0d6g95anakr1bcbya-libredirect-0/lib/libredirect.so xdg-open https://nixos.org

The are errors in console when running this command, running "xdg-open https://nixos.org" does not cause this errors. The wierd thing that after running "xdg-open https://nixos.org" the version with preload starts to work until terminal is reopened and sometimes it works even after console is reloaded and resores its original behaviour only after system restart.
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.sycoca: ERROR writing database "/home/andrey/.cache/ksycoca5_en_4v8+t83XVDI1ahgMTvpVh_Z_UiM=" . Disk full?
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.sycoca: ERROR writing database "/home/andrey/.cache/ksycoca5_en_4v8+t83XVDI1ahgMTvpVh_Z_UiM=" . Disk full?
kf5.kservice.sycoca: No ksycoca database available! Tried running kbuildsycoca5 ?
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.sycoca: ERROR writing database "/home/andrey/.cache/ksycoca5_en_4v8+t83XVDI1ahgMTvpVh_Z_UiM=" . Disk full?
Could not open sycoca database, you must run kbuildsycoca first!
kf5.kservice.sycoca: No ksycoca database available! Tried running kbuildsycoca5 ?
kf5.kservice.services: KMimeTypeTrader: couldn't find service type "KParts/ReadOnlyPart"
Please ensure that the .desktop file for it is installed; then run kbuildsycoca5.
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.sycoca: ERROR writing database "/home/andrey/.cache/ksycoca5_en_4v8+t83XVDI1ahgMTvpVh_Z_UiM=" . Disk full?
kf5.kservice.sycoca: No ksycoca database available! Tried running kbuildsycoca5 ?
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.sycoca: ERROR writing database "/home/andrey/.cache/ksycoca5_en_4v8+t83XVDI1ahgMTvpVh_Z_UiM=" . Disk full?
Could not open sycoca database, you must run kbuildsycoca first!
kf5.kservice.sycoca: No ksycoca database available! Tried running kbuildsycoca5 ?
kf5.kservice.services: KMimeTypeTrader: couldn't find service type "Application"
Please ensure that the .desktop file for it is installed; then run kbuildsycoca5.
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.services: The desktop entry file "/run/current-system/sw/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/run/current-system/sw/share/applications/qemu.desktop"
kf5.kservice.sycoca: ERROR writing database "/home/andrey/.cache/ksycoca5_en_4v8+t83XVDI1ahgMTvpVh_Z_UiM=" . Disk full?
kf5.kservice.sycoca: No ksycoca database available! Tried running kbuildsycoca5 ?

I cannot grasp this libredirect stuff and find the good docs, looks llke it will be a long process for me.I Is this libredirect version specific to NixOS or is it configured?

Is this libredirect version specific to NixOS or is it configured?

The sources are in pkgs/build-support/libredirect. It's Nix-specific as we don't have store executables in /usr/bin (I'm not sure though how good it works on other distros with Nix installed)

@angordeyev would it be possible to create a minimal Nix expression for a VM to reproduce? As I don't encounter this issue either, this might be pretty helpful for debugging :)

I will prepare the expression and the virtual image. Probably my configuration causes the issue.

I will prepare the expression and the virtual image. Probably my configuration causes the issue.

Oh, I didn't even mean to blame your config :)
I'm just suspecting that the combination of several components causes the issue and in that case it's (most likely) still a NixOS bug.

I have some bash in configuration, and NixOS configuration is quite flexible so I suspected that it might have been the case, also the issue was not repeatable on other systems.
I was able to reproduce it on a fresh system.
You can download qcow2 KVM virtual machine image  or use the configuration below.
# Edit this configuration file to define what should be installed on
# your system.  Help is available in the configuration.nix(5) man page
# and in the NixOS manual (accessible by running ‘nixos-help’).

{ config, pkgs, ... }:

{
  imports =
    [ # Include the results of the hardware scan.
      ./hardware-configuration.nix
    ];

  nixpkgs.config.allowUnfree = true;

  services.spice-vdagentd.enable = true; # Does not effect the issue, copy paste support for VM

  # Use the GRUB 2 boot loader.
  boot.loader.grub.enable = true;
  boot.loader.grub.version = 2;
  # boot.loader.grub.efiSupport = true;
  # boot.loader.grub.efiInstallAsRemovable = true;
  # boot.loader.efi.efiSysMountPoint = "/boot/efi";
  # Define on which hard drive you want to install Grub.
  boot.loader.grub.device = "/dev/sda"; # or "nodev" for efi only

  networking.hostName = "nixos"; # Define your hostname.
  # networking.wireless.enable = true;  # Enables wireless support via wpa_supplicant.

  # The global useDHCP flag is deprecated, therefore explicitly set to false here.
  # Per-interface useDHCP will be mandatory in the future, so this generated config
  # replicates the default behaviour.
  networking.useDHCP = false;
  networking.interfaces.ens3.useDHCP = true;

  # Configure network proxy if necessary
  # networking.proxy.default = "http://user:password@proxy:port/";
  # networking.proxy.noProxy = "<IP_ADDRESS>,localhost,internal.domain";

  # Select internationalisation properties.
  # i18n = {
  #   consoleFont = "Lat2-Terminus16";
  #   consoleKeyMap = "us";
  #   defaultLocale = "en_US.UTF-8";
  # };

  # Set your time zone.
  # time.timeZone = "Europe/Amsterdam";

  # List packages installed in system profile. To search, run:
  # $ nix search wget
  environment.systemPackages = with pkgs; [
     sublime3
     spice-vdagent # Does not effect the issue, copy paste support for VM
  ];

  # Some programs need SUID wrappers, can be configured further or are
  # started in user sessions.
  # programs.mtr.enable = true;
  # programs.gnupg.agent = { enable = true; enableSSHSupport = true; };

  # List services that you want to enable:

  # Enable the OpenSSH daemon.
  # services.openssh.enable = true;

  # Open ports in the firewall.
  # networking.firewall.allowedTCPPorts = [ ... ];
  # networking.firewall.allowedUDPPorts = [ ... ];
  # Or disable the firewall altogether.
  # networking.firewall.enable = false;

  # Enable CUPS to print documents.
  # services.printing.enable = true;

  # Enable sound.
  # sound.enable = true;
  # hardware.pulseaudio.enable = true;

  # Enable the X11 windowing system.
  services.xserver.enable = true;
  services.xserver.layout = "us";
  services.xserver.xkbOptions = "eurosign:e";

  # Enable touchpad support.
  # services.xserver.libinput.enable = true;

  # Enable the KDE Desktop Environment.
  services.xserver.displayManager.sddm.enable = true;
  services.xserver.desktopManager.plasma5.enable = true;

  # Define a user account. Don't forget to set a password with ‘passwd’.
  users.users.jane = {
    isNormalUser = true;
    extraGroups = [ "wheel" ]; # Enable ‘sudo’ for the user.
  };

  # This value determines the NixOS release with which your system is to be
  # compatible, in order to avoid breaking some software such as database
  # servers. You should change this only after NixOS release notes say you
  # should.
  system.stateVersion = "19.09"; # Did you read the comment?

}

@angordeyev I wasn't able to load graphical interface in provided .qcow2 image for some reason (I tried both using QEMU and VirtualBox. QEMU shows just black screen on tty7. VirtualBox won't even switch to it). I couldn't login using tty1 either, because I don't know the password.

Sorry, the user is jane, the password is 123 both for jane and root.

This signature in libredirect is very suspicious. I think access should return int not int*:
https://github.com/NixOS/nixpkgs/blob/695a3d4254545968fc3015142c5299c0da5ca0a9/pkgs/build-support/libredirect/libredirect.c#L129
(Offtopic: @angordeyev I figured out black screen problem. I forgot to specify RAM for qemu and it was using 128Mb by default)

The wierd thing that after running "xdg-open https://nixos.org" the version with preload starts to work until terminal is reopened and sometimes it works even after terminal is restarted and restores its original incorrect behaviour only after system restart

That's because kbuildsycoca5 caches something in ~/.cache. Instead of system restart you can restore incorrect behavior by running rm ~/.cache/ksycoca5_en_*.

Implementation of open64 in libredirect seems to be causing some problems. If I just comment it out, kde-open5 works fine.

The problem seems to be that implementation of open and open64 doesn't check O_TMPFILE flag when it decides whether or not it should forward mode argument. Fixing that seems to solve the issue.

@demin-dmitriy Cool. What do we have to do next? I am a little far from the Linux internals and NixOS development process, the problem is not local to the package.

@angordeyev This is a problem with libredirect, which is nixpkgs-specific hack to rewrite file paths that application tries to open. (This has nothing to do with Linux internals). I think we keep this issue open until it's fixed. Somebody will make MR for libredirect (maybe it will be me, maybe even soon) which will fix this issue.

@demin-dmitriy thanks a lot for digging into this (I hoped I'd have more time this weekend to look into this as well, sry :/)! You're absolutely right, libredirect is barely used these, so it's pretty painful to debug issues there.
Unless you're faster here, I might give it a try to fix this during the next week :)

kf5.kservice.sycoca: ERROR writing database "/home/andrey/.cache/ksycoca5_en_4v8+t83XVDI1ahgMTvpVh_Z_UiM=" . Disk full?

Double-checking that your disk is indeed not full. Then the next thing would be to check if you have write permissions on that file, is it owned by your user?

The disk is almost empty on my working machine, this message is also shown on the fresh VM machine with sublime installed. The file is owned by a user and has "-rw-rw-rw-" permissions.

@zimbatm that error happens because open, open64, openat calls to glibc are intercepted by libredirect and there is a bug in libredirect which creates file with wrong permissions when O_TMPFILE flag is passed.

Late thanks to everybody.
Works fine in Chromium, does not work when Chrome is the default browser.
Steps to reproduce:

Set Chrome as the default browser
run in a terminal:

export LD_PRELOAD='/nix/store/5zmj09p2vnpn6rhkysfci5gjmawwr96n-libredirect-0/lib/libredirect.so'

xdg-open https://nixos.org or
google-chrome-stable https://nixos.org does not work

I am getting segfault with libredirect and git --version from different nixpkgs version:
let
  nixpkgs-newer = import (fetchTarball {
    url = "https://github.com/NixOS/nixpkgs/archive/5717d9d2f7ca0662291910c52f1d7b95b568fec2.tar.gz";
    sha256 = "17gxd2f622pyss3r6cjngdav6wzdbr31d7bqx9z2lawxg47mmk1l";
  }) {};
  nixpkgs-older = import (fetchTarball {
    url = "https://github.com/NixOS/nixpkgs/archive/b3251e04ee470c20f81e75d5a6080ba92dc7ed3f.tar.gz";
    sha256 = "0hld390gb3q055sa7j1rzxl1hzaxgagc60vrqmkk8fnfpv813g75";
  }) {};
  inherit (nixpkgs-older) git;
  inherit (nixpkgs-newer) libredirect;
in
nixpkgs-newer.runCommand "test" {
  buildInputs = [ git ];
} ''
  env LD_PRELOAD=${libredirect}/lib/libredirect.so git --version
  touch $out
''

I opened an issue upstream https://github.com/sublimehq/sublime_text/issues/3502

I'm getting a segfault (SIGSEGV) in git with Sublime Merge from <nixos-unstable> and Git from <nixos-20.03>. Chasing around the syscalls and core dump, Git used to load (from sublime-merge on <nixos-20.03> (stable)) just using /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/. This matches its closure. The segfaulting Git is calling openat & mmaping /nix/store/xg6ilb...-glibc-2.30/ just fine until after openat(AT_FDCWD, "/nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libc.so.6", O_RDONLY|O_CLOEXEC). The next library load tries openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls/haswell/x86_64/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) and others, up to success with openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3. This is the last library to be loaded. Here's some annotated strace output:

28473 14:08:33.242925 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/msp4hm62a75pdidlc3s2ymma2g5hsjjk-zlib-1.2.11/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.242977 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/mr8q9cdzmpgc8q8jy2s2fgk50kxmkqjv-pcre2-10.34/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.243015 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
28473 14:08:33.243054 [00007f165d0e7634] read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240>\2\0\0\0\0\0@\0\0\0\0\0\0\0\30O\37\0\0\0\0\0\0\0\0\0@\08\0\f\0@\0A\0@\0\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\240\2\0\0\0\0\0\0\240\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\200\214\30\0\0\0\0\0\200\214\30\0\0\0\0\0\200\214\30\0\0\0\0\0P\0\0\0\0\0\0\0P\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0`\25\2\0\0\0\0\0`\25\2\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0 \2\0\0\0\0\0\0 \2\0\0\0\0\0\0 \2\0\0\0\0\0\330?\24\0\0\0\0\0\330?\24\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0`\26\0\0\0\0\0\0`\26\0\0\0\0\0\0`\26\0\0\0\0\0\270\330\4\0\0\0\0\0\270\330\4\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\6\0\0\0HE\33\0\0\0\0\0HU\33\0\0\0\0\0HU\33\0\0\0\0\0\270P\0\0\0\0\0\0\370\217\0\0\0\0\0\0\0\20\0\0\0\0\0\0\2\0\0\0\6\0\0\0\300y\33\0\0\0\0\0\300\211\33\0\0\0\0\0\300\211\33\0\0\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\340\2\0\0\0\0\0\0\340\2\0\0\0\0\0\0\340\2\0\0\0\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0HE\33\0\0\0\0\0HU\33\0\0\0\0\0HU\33\0\0\0\0\0\20\0\0\0\0\0\0\0\220\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\0\0\0\320\214\30\0\0\0\0\0\320\214\30\0\0\0\0\0\320\214\30\0\0\0\0\0lb\0\0\0\0\0\0lb\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0R\345td\4\0\0\0HE\33\0\0\0\0\0HU\33\0\0\0\0\0HU\33\0\0\0\0\0\270:\0\0\0\0\0\0\270:\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\t\17\213\214{\33h2\214\342l\215\24\33`\300\243\300@V\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0 \0\0\0\0\0\0\0\363\3\0\0\f\0\0\0\0\1\0\0\16\0\0\0\0000\20D\240 \2\1", 832) = 832
28473 14:08:33.243093 [00007f165d0e7763] mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f165cfd0000
28473 14:08:33.243130 [00007f165d0e73f3] fstat(3, {st_dev=makedev(0, 0x1d), st_ino=90879188, st_mode=S_IFREG|0555, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=4016, st_size=2056024, st_atime=1597082851 /* 2020-08-10T11:07:31.856901565-0700 */, st_atime_nsec=856901565, st_mtime=1 /* 1969-12-31T16:00:01-0800 */, st_mtime_nsec=0, st_ctime=1595910015 /* 2020-07-27T21:20:15.759091262-0700 */, st_ctime_nsec=759091262}) = 0
28473 14:08:33.243180 [00007f165d0e7763] mmap(NULL, 1828160, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f165ce11000
28473 14:08:33.243231 [00007f165d0e7817] mprotect(0x7f165ce33000, 1650688, PROT_NONE) = 0
28473 14:08:33.243311 [00007f165d0e7763] mmap(0x7f165ce33000, 1327104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f165ce33000
28473 14:08:33.243355 [00007f165d0e7763] mmap(0x7f165cf77000, 319488, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x166000) = 0x7f165cf77000
28473 14:08:33.243392 [00007f165d0e7763] mmap(0x7f165cfc6000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0x7f165cfc6000
28473 14:08:33.243532 [00007f165d0e7763] mmap(0x7f165cfcc000, 13632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f165cfcc000
28473 14:08:33.243596 [00007f165d0e74a7] close(3) = 0
28473 14:08:33.243644 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls/haswell/x86_64/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.243692 [00007f165d0e73b5] stat("/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls/haswell/x86_64", 0x7ffc23768310) = -1 ENOENT (No such file or directory)
28473 14:08:33.243731 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls/haswell/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.243771 [00007f165d0e73b5] stat("/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls/haswell", 0x7ffc23768310) = -1 ENOENT (No such file or directory)
28473 14:08:33.243808 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls/x86_64/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.243846 [00007f165d0e73b5] stat("/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls/x86_64", 0x7ffc23768310) = -1 ENOENT (No such file or directory)
28473 14:08:33.243882 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.243920 [00007f165d0e73b5] stat("/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/tls", 0x7ffc23768310) = -1 ENOENT (No such file or directory)
28473 14:08:33.243957 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/haswell/x86_64/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.243995 [00007f165d0e73b5] stat("/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/haswell/x86_64", 0x7ffc23768310) = -1 ENOENT (No such file or directory)
28473 14:08:33.244032 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/haswell/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.244069 [00007f165d0e73b5] stat("/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/haswell", 0x7ffc23768310) = -1 ENOENT (No such file or directory)
28473 14:08:33.244106 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/x86_64/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28473 14:08:33.244144 [00007f165d0e73b5] stat("/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/x86_64", 0x7ffc23768310) = -1 ENOENT (No such file or directory)
28473 14:08:33.244181 [00007f165d0e756d] openat(AT_FDCWD, "/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
28473 14:08:33.244222 [00007f165d0e7634] read(3,  <unfinished ...>
28473 14:08:33.244258 [00007f165d0e7634] <... read resumed>"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \21\0\0\0\0\0\0@\0\0\0\0\0\0\0`@\0\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\36\0\35\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0`\r\0\0\0\0\0\0`\r\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\20\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\20\0\0\0\0\0\0\301\r\0\0\0\0\0\0\301\r\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\354\6\0\0\0\0\0\0\354\6\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\6\0\0\0\330,\0\0\0\0\0\0\330<\0\0\0\0\0\0\330<\0\0\0\0\0\0000\3\0\0\0\0\0\0\270\3\0\0\0\0\0\0\0\20\0\0\0\0\0\0\2\0\0\0\6\0\0\0\370,\0\0\0\0\0\0\370<\0\0\0\0\0\0\370<\0\0\0\0\0\0000\2\0\0\0\0\0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\08\2\0\0\0\0\0\08\2\0\0\0\0\0\08\2\0\0\0\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\244 \0\0\0\0\0\0\244 \0\0\0\0\0\0\244 \0\0\0\0\0\0\324\0\0\0\0\0\0\0\324\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0R\345td\4\0\0\0\330,\0\0\0\0\0\0\330<\0\0\0\0\0\0\330<\0\0\0\0\0\0(\3\0\0\0\0\0\0(\3\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\3\304\241\265;h,=\3418sU\177\221w\362\306\24V\366\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0 \0\0\0\0\0\0\0\33\0\0\0\33\0\0\0\2\0\0\0\7\0\0\0\230\2\21\0\200H\0\4\22\0 @\203(\10\236\33\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\0\0\0\0\35\0\0\0\0\0\0\0\36\0\0\0\0\0\0\0\37\0\0\0\0\0\0\0 \0\0\0\0\0\0\0!\0\0\0#\0\0\0$\0\0\0&\0\0\0'\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0(\0\0\0)\0\0\0\0\0\0\0\0\0\0\0\353\26\251\30a\257\0\371\301S\200\30\273\25sB\257\304M\17\221!\374\370\6\2\4\371\3733\373\17\371\31sB\372\31sB\225\263_\31\177\236\320\30a\242\222\6", 832) = 832
28473 14:08:33.244301 [00007f165d0e73f3] fstat(3,  <unfinished ...>
28473 14:08:33.244328 [00007f165d0e73f3] <... fstat resumed>{st_dev=makedev(0, 0x1d), st_ino=91215983, st_mode=S_IFREG|0555, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=40, st_size=18400, st_atime=1596752821 /* 2020-08-06T15:27:01.494330980-0700 */, st_atime_nsec=494330980, st_mtime=1 /* 1969-12-31T16:00:01-0800 */, st_mtime_nsec=0, st_ctime=1595912221 /* 2020-07-27T21:57:01.088005191-0700 */, st_ctime_nsec=88005191}) = 0
28473 14:08:33.244373 [00007f165d0e7763] mmap(NULL, 16528, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f165ce0c000
28473 14:08:33.244412 [00007f165d0e7763] mmap(0x7f165ce0d000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000 <unfinished ...>
28473 14:08:33.244451 [00007f165d0e7763] <... mmap resumed>) = 0x7f165ce0d000
28473 14:08:33.244481 [00007f165d0e7763] mmap(0x7f165ce0e000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000 <unfinished ...>
28473 14:08:33.244544 [00007f165d0e7763] <... mmap resumed>) = 0x7f165ce0e000
28473 14:08:33.244595 [00007f165d0e7763] mmap(0x7f165ce0f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000 <unfinished ...>
28473 14:08:33.244707 [00007f165d0e7763] <... mmap resumed>) = 0x7f165ce0f000
28473 14:08:33.244736 [00007f165d0e74a7] close(3 <unfinished ...>
28473 14:08:33.244784 [00007f165d0e74a7] <... close resumed>) = 0
28473 14:08:33.244842 [00007f165d0e7763 /* ld-2.30.so <mmap64+67> */] mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...>
28473 14:08:33.244881 [00007f165d0e7763] <... mmap resumed>) = 0x7f165ce0a000
28473 14:08:33.244923 [00007f165d0ceb1c /* ld-2.30.so <init_tls+204> */] arch_prctl(ARCH_SET_FS, 0x7f165ce0ab80 <unfinished ...>
28473 14:08:33.244962 [00007f165d0ceb1c] <... arch_prctl resumed>) = 0
28473 14:08:33.245112 [00007f165d0e7817 /* ld-2.30.so <mprotect+7> */] mprotect(0x7f165cfc6000, 16384, PROT_READ <unfinished ...>
28473 14:08:33.245196 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.245246 [00007f165d0e7817 /* ld-2.30.so <mprotect+7> */] mprotect(0x7f165ce0f000, 4096, PROT_READ <unfinished ...>
28473 14:08:33.245289 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.245360 [00007f165d0e7817] mprotect(0x7f165cfed000, 4096, PROT_READ <unfinished ...>
28473 14:08:33.245445 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.245482 [00007f165d0e7817] mprotect(0x7f165d00b000, 4096, PROT_READ <unfinished ...>
28473 14:08:33.245524 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.245796 [00007f165d0e7817] mprotect(0x7f165d015000, 4096, PROT_READ <unfinished ...>
28473 14:08:33.246080 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.246143 [00007f165d0e7817] mprotect(0x7f165d032000, 4096, PROT_READ <unfinished ...>
28473 14:08:33.246248 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.246319 [00007f165d0e7817] mprotect(0x7f165d0c3000, 4096, PROT_READ <unfinished ...>
28473 14:08:33.246356 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.246392 [00007f165d0e7817] mprotect(0x7f165d0c9000, 4096, PROT_READ <unfinished ...>
28473 14:08:33.246424 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.247231 [00007f165d0e7817 /* ld-2.30.so <mprotect+7> */] mprotect(0x6c5000, 16384, PROT_READ <unfinished ...>
28473 14:08:33.247293 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.247412 [00007f165d0e7817 /* ld-2.30.so <mprotect+7> */] mprotect(0x7f165d0f5000, 4096, PROT_READ <unfinished ...>
28473 14:08:33.247472 [00007f165d0e7817] <... mprotect resumed>) = 0
28473 14:08:33.247512 [00007f165cfd8892 /* libc-2.30.so <sighandler_setxid+233> */] set_tid_address(0x7f165ce0ae50 <unfinished ...>
28473 14:08:33.247551 [00007f165cfd8892] <... set_tid_address resumed>) = 28473
28473 14:08:33.247741 [00007f165cfd88dd /* libpthread-2.30.so <__pthread_initialize_minimal+109> */] set_robust_list(0x7f165ce0ae60, 24 <unfinished ...>
28473 14:08:33.247784 [00007f165cfd88dd] <... set_robust_list resumed>) = 0
28473 14:08:33.247821 [00007f165cfe5030 /* libpthread-2.30.so <__libc_sigaction+176> */] rt_sigaction(SIGRTMIN, {sa_handler=0x7f165cfd86a0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f165cfe4f70},  <unfinished ...>
28473 14:08:33.247864 [00007f165cfe5030] <... rt_sigaction resumed>NULL, 8) = 0
28473 14:08:33.247896 [00007f165cfe5030 /* libpthread-2.30.so <__libc_sigaction+176> */] rt_sigaction(SIGRT_1, {sa_handler=0x7f165cfd8740, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f165cfe4f70},  <unfinished ...>
28473 14:08:33.247941 [00007f165cfe5030] <... rt_sigaction resumed>NULL, 8) = 0
28473 14:08:33.247973 [00007f165cfd89c3 /* libpthread-2.30.so.0 <__pthread_initialize_minimal+339> */] rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1],  <unfinished ...>
28473 14:08:33.248013 [00007f165cfd89c3] <... rt_sigprocmask resumed>NULL, 8) = 0
28473 14:08:33.248050 [00007f165ceffbd8 /* libc-2.30.so <getrlimit64+24> */] prlimit64(0, RLIMIT_STACK, NULL,  <unfinished ...>
28473 14:08:33.248090 [00007f165ceffbd8] <... prlimit64 resumed>{rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
28473 14:08:33.248221 [00007f165cfe229e /* libpthread-2.30.so.0 <__pthread_once_slow+190> */] futex(0x7f165ce10048, FUTEX_WAKE_PRIVATE,<PHONE_NUMBER>) = 0
28473 14:08:33.248306 [00007f165cf00087 /* libc-2.30.so <brk+7> */] brk(NULL /* $0xc */) = 0x215a000
28473 14:08:33.248360 [00007f165cf00087 /* libc-2.30.so <brk+7> */] brk(0x217b000) = 0x217b000
28473 14:08:33.248435 [0000000000000000] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
28473 14:08:33.544344 [????????????????] +++ killed by SIGSEGV (core dumped) +++

/nix/store/7p1v1b...-glibc-2.31/ is only found in Sublime Merge's closure. openat(AT_FDCWD, "/nix/store/bj075giskvll56sd241rvmbrny40fwzz-libredirect-0/lib/libredirect.so", O_RDONLY|O_CLOEXEC) = 3 was the first load of this process (created via glibc's <_clone> AFAICT). In Git's execve(), there is no NIX_REDIRECTS environment entry, but Sublime Merge is passed "NIX_REDIRECTS=/usr/bin/pkexec=/run/wrappers/bin/pkexec:/bin/true=/nix/store/vssdbs9s059qm5rqpw5q25z3c2d065f7-coreutils-8.31/bin/true".
For some extra debugging information, Sublime Merge's process tree loads libredirect.so three different times.

PID 28455 (root): execve("…/bin/sublime_merge`, ["sublime_merge", "."], …)
[28455] /nix/store/bj075giskvll56sd241rvmbrny40fwzz-libredirect-0/lib/libredirect.so
libredirect.so -> 0x00007f5f044e5000 (r-x) +8192 (private, fixed, denywrite)
libredirect.so -> 0x00007f5f044e7000 (r--) +4096 (private, fixed, denywrite)
libredirect.so -> 0x00007f5f044e8000 (rw-) +8192 (private, fixed, denywrite)
PID 28456 (parent 28455): clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f5f03c96b10)
PID 28457 (parent 28456): clone(child_stack=0x7f5ef549bff0, flags=CLONE_VM|CLONE_VFORK|SIGCHLD)
PID 28457: execve("/nix/store/9a67fh1alv0xr15fzm26lq7g63ivbxcw-sublime-merge-bin-2020/.sublime_merge-wrapped", ["/nix/store/9a67fh1alv0xr15fzm26lq7g63ivbxcw-sublime-merge-bin-2020/sublime_merge", "--multiinstance", "."], …)
[28457] /nix/store/bj075giskvll56sd241rvmbrny40fwzz-libredirect-0/lib/libredirect.so
libredirect.so -> 0x00007fac7c8e0000 (r-x) +8192 (private, fixed, denywrite)
libredirect.so -> 0x00007fac7c8e2000 (r--) +4096 (private, fixed, denywrite)
libredirect.so -> 0x00007fac7c8e3000 (rw-) +8192 (private, fixed, denywrite)
PID 28468 (parent 28457): clone(child_stack=0x7fac4fffeeb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[28468], tls=0x7fac4ffff700, child_tidptr=0x7fac4ffff9d0)
PID 28468: prctl(PR_SET_NAME, "git_queue")
PID 28473 (parent 28468): clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD)
PID 28473: execve("/nix/store/rz1x5fv1pxavdzmx8dlbdw9kc542xf8n-git-2.25.4/bin/git", ["git", "add", …], …)
[28473] /nix/store/bj075giskvll56sd241rvmbrny40fwzz-libredirect-0/lib/libredirect.so
libredirect.so -> 0x00007f165d0c6000 (r-x) +8192 (private, fixed, denywrite)
libredirect.so -> 0x00007f165d0c8000 (r--) +4096 (private, fixed, denywrite)
libredirect.so -> 0x00007f165d0c9000 (rw-) +8192 (private, fixed, denywrite)

The SIGSEGV takes a path through 0x00007f165d0c65b4, which is Git's mapping of libredirect. The objdump -d disassembly of libredirect.so shows that 0x1570: <open64> is taken, with a segfault at 0x15af: <open64+0x3f>, callq  10d0 <dlsym@plt>. Here's the coredumpctl debug … backtrace:
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f165ce0d3e0 in dlsym () from /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libdl.so.2
#2  0x00007f165d0c65b4 in open64 () from /nix/store/bj075giskvll56sd241rvmbrny40fwzz-libredirect-0/lib/libredirect.so
#3  0x00000000005bee39 in sanitize_stdfds ()
#4  0x0000000000405f52 in main ()

This is the original source of libredirect.so, libredirect.c:

static const char * rewrite(const char * path, char * buf)
{
    if (path == NULL) return path;
    for (int n = 0; n < nrRedirects; ++n) {
        int len = strlen(from[n]);
        if (strncmp(path, from[n], len) != 0) continue;
        if (snprintf(buf, PATH_MAX, "%s%s", to[n], path + len) >= PATH_MAX)
            abort();
        return buf;
    }

    return path;
}

int open64(const char * path, int flags, ...)
{
    int (*open64_real) (const char *, int, mode_t) = dlsym(RTLD_NEXT, "open64");
    mode_t mode = 0;
    if (open_needs_mode(flags)) {
        va_list ap;
        va_start(ap, flags);
        mode = va_arg(ap, mode_t);
        va_end(ap);
    }
    char buf[PATH_MAX];
    return open64_real(rewrite(path, buf), flags, mode);
}

And this is the objdump -d disassembly, annotated:

00000000000010fa <open64.cold>:
    10fa:	e8 51 ff ff ff       	callq  1050 <abort@plt>

0000000000001570 <open64>: # backtrace #2
    1570:	41 57                	push   %r15
    1572:	49 89 ff             	mov    %rdi,%r15
    1575:	48 c7 c7 ff ff ff ff 	mov    $0xffffffffffffffff,%rdi
    157c:	41 56                	push   %r14
    157e:	41 55                	push   %r13
    1580:	41 54                	push   %r12
    1582:	55                   	push   %rbp
    1583:	89 f5                	mov    %esi,%ebp
    1585:	48 8d 35 95 1a 00 00 	lea    0x1a95(%rip),%rsi        # 3021 <_fini+0xd95>
    158c:	53                   	push   %rbx
    158d:	48 81 ec 88 10 00 00 	sub    $0x1088,%rsp
    1594:	48 89 94 24 60 10 00 	mov    %rdx,0x1060(%rsp)
    159b:	00
    159c:	64 48 8b 04 25 28 00 	mov    %fs:0x28,%rax
    15a3:	00 00
    15a5:	48 89 84 24 48 10 00 	mov    %rax,0x1048(%rsp)
    15ac:	00
    15ad:	31 c0                	xor    %eax,%eax
    15af:	e8 1c fb ff ff       	callq  10d0 <dlsym@plt>         # backtrace #2 (ip 0x00007f165d0c65af; offset -0x7f165d0c500)
    15b4:	48 89 c3             	mov    %rax,%rbx
    15b7:	40 f6 c5 40          	test   $0x40,%bpl
    15bb:	0f 85 7f 00 00 00    	jne    1640 <open64+0xd0>
    15c1:	89 e8                	mov    %ebp,%eax
    15c3:	45 31 ed             	xor    %r13d,%r13d
    15c6:	25 00 00 41 00       	and    $0x410000,%eax
    15cb:	3d 00 00 41 00       	cmp    $0x410000,%eax
    15d0:	74 6e                	je     1640 <open64+0xd0>
    15d2:	8b 05 68 42 00 00    	mov    0x4268(%rip),%eax        # 5840 <nrRedirects>
    15d8:	85 c0                	test   %eax,%eax
    15da:	0f 8e de 00 00 00    	jle    16be <open64+0x14e>
    15e0:	83 e8 01             	sub    $0x1,%eax
    15e3:	45 31 e4             	xor    %r12d,%r12d
    15e6:	4c 8d 35 53 3e 00 00 	lea    0x3e53(%rip),%r14        # 5440 <from>
    15ed:	48 89 44 24 18       	mov    %rax,0x18(%rsp)
    15f2:	4b 8b 34 e6          	mov    (%r14,%r12,8),%rsi
    15f6:	44 89 64 24 14       	mov    %r12d,0x14(%rsp)
    15fb:	48 89 f7             	mov    %rsi,%rdi
    15fe:	48 89 74 24 08       	mov    %rsi,0x8(%rsp)
    1603:	e8 68 fa ff ff       	callq  1070 <strlen@plt>
    1608:	48 8b 74 24 08       	mov    0x8(%rsp),%rsi
    160d:	4c 89 ff             	mov    %r15,%rdi
    1610:	4c 63 c0             	movslq %eax,%r8
    1613:	4c 89 c2             	mov    %r8,%rdx
    1616:	4c 89 04 24          	mov    %r8,(%rsp)
    161a:	e8 41 fa ff ff       	callq  1060 <strncmp@plt>
    161f:	4c 8b 04 24          	mov    (%rsp),%r8
    1623:	85 c0                	test   %eax,%eax
    1625:	74 49                	je     1670 <open64+0x100>
    1627:	49 8d 44 24 01       	lea    0x1(%r12),%rax
    162c:	4c 39 64 24 18       	cmp    %r12,0x18(%rsp)
    1631:	0f 84 87 00 00 00    	je     16be <open64+0x14e>
    1637:	49 89 c4             	mov    %rax,%r12
    163a:	eb b6                	jmp    15f2 <open64+0x82>
    163c:	0f 1f 40 00          	nopl   0x0(%rax)
    1640:	48 8d 84 24 c0 10 00 	lea    0x10c0(%rsp),%rax
    1647:	00
    1648:	c7 44 24 28 10 00 00 	movl   $0x10,0x28(%rsp)
    164f:	00
    1650:	44 8b ac 24 60 10 00 	mov    0x1060(%rsp),%r13d
    1657:	00
    1658:	48 89 44 24 30       	mov    %rax,0x30(%rsp)
    165d:	48 8d 84 24 50 10 00 	lea    0x1050(%rsp),%rax
    1664:	00
    1665:	48 89 44 24 38       	mov    %rax,0x38(%rsp)
    166a:	e9 63 ff ff ff       	jmpq   15d2 <open64+0x62>
    166f:	90                   	nop
    1670:	4c 63 64 24 14       	movslq 0x14(%rsp),%r12
    1675:	4c 8d 74 24 40       	lea    0x40(%rsp),%r14
    167a:	4d 01 f8             	add    %r15,%r8
    167d:	48 83 ec 08          	sub    $0x8,%rsp
    1681:	41 50                	push   %r8
    1683:	b9 00 10 00 00       	mov    $0x1000,%ecx
    1688:	ba 01 00 00 00       	mov    $0x1,%edx
    168d:	4c 89 f7             	mov    %r14,%rdi
    1690:	48 8d 05 a9 39 00 00 	lea    0x39a9(%rip),%rax        # 5040 <to>
    1697:	4c 8d 05 62 19 00 00 	lea    0x1962(%rip),%r8        # 3000 <_fini+0xd74>
    169e:	be 00 10 00 00       	mov    $0x1000,%esi
    16a3:	4e 8b 0c e0          	mov    (%rax,%r12,8),%r9
    16a7:	31 c0                	xor    %eax,%eax
    16a9:	e8 92 f9 ff ff       	callq  1040 <__snprintf_chk@plt>
    16ae:	5a                   	pop    %rdx
    16af:	59                   	pop    %rcx
    16b0:	3d ff 0f 00 00       	cmp    $0xfff,%eax
    16b5:	0f 8f 3f fa ff ff    	jg     10fa <open64.cold>
    16bb:	4d 89 f7             	mov    %r14,%r15
    16be:	44 89 ea             	mov    %r13d,%edx
    16c1:	89 ee                	mov    %ebp,%esi
    16c3:	4c 89 ff             	mov    %r15,%rdi
    16c6:	ff d3                	callq  *%rbx
    16c8:	48 8b 9c 24 48 10 00 	mov    0x1048(%rsp),%rbx
    16cf:	00
    16d0:	64 48 33 1c 25 28 00 	xor    %fs:0x28,%rbx
    16d7:	00 00
    16d9:	75 12                	jne    16ed <open64+0x17d>
    16db:	48 81 c4 88 10 00 00 	add    $0x1088,%rsp
    16e2:	5b                   	pop    %rbx
    16e3:	5d                   	pop    %rbp
    16e4:	41 5c                	pop    %r12
    16e6:	41 5d                	pop    %r13
    16e8:	41 5e                	pop    %r14
    16ea:	41 5f                	pop    %r15
    16ec:	c3                   	retq
    16ed:	e8 8e f9 ff ff       	callq  1080 <__stack_chk_fail@plt>
    16f2:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
    16f9:	00 00 00 00
    16fd:	0f 1f 00             	nopl   (%rax)

(0x3021, over in .rodata, is open64\x00.)

The open64_real indirection has been inlined, as well as the whole rewrite call. <dlsym@plt> is called before any of the rewrite machinery, or AFAICT any chances for jumps. dlsym is never called again in the function. The earliest possible jump is at 0x166a <open64+0xfa>, back to 0x15d2 <open64+0x62>, after our dlsym call at <open64+0x3f>.
Looking at man dlsym(3), the RTLD_NEXT pseudo-handle is described as:
RTLD_NEXT
       Find the next occurrence of the desired symbol in the search
       order after the current object.  This allows one to provide a
       wrapper around a function in another shared object, so that,
       for example, the definition of a function in a preloaded
       shared object (see LD_PRELOAD in ld.so(8)) can find and invoke
       the "real" function provided in another shared object (or for
       that matter, the "next" definition of the function in cases
       where there are multiple layers of preloading).

I'm wondering if glibc is preferring to load itself for libc upon RTLD_NEXT, as it's I think maybe basing from the original libredirect.so position in a search path?
Here's glibc-2.30/elf/dl-sym.c & glibc-2.31/elf/dl-sym.c, and here's the patch from Nixpkgs's 2.30 to 2.31:
diff -u glibc-{2.30,2.31}/elf/dl-sym.c
--- glibc-2.30/elf/dl-sym.c	2019-07-31 21:29:31.000000000 -0700
+++ glibc-2.31/elf/dl-sym.c	2020-02-01 03:52:50.000000000 -0800
@@ -1,5 +1,5 @@
 /* Look up a symbol in a shared object loaded by `dlopen'.
-   Copyright (C) 1999-2019 Free Software Foundation, Inc.
+   Copyright (C) 1999-2020 Free Software Foundation, Inc.
    This file is part of the GNU C Library.

    The GNU C Library is free software; you can redistribute it and/or
@@ -14,7 +14,7 @@

    You should have received a copy of the GNU Lesser General Public
    License along with the GNU C Library; if not, see
-   <http://www.gnu.org/licenses/>.  */
+   <https://www.gnu.org/licenses/>.  */

 #include <assert.h>
 #include <stddef.h>
@@ -80,6 +80,18 @@
 					args->flags, NULL);
 }

+/* Return the link map containing the caller address.  */
+static inline struct link_map *
+find_caller_link_map (ElfW(Addr) caller)
+{
+  struct link_map *l = _dl_find_dso_for_object (caller);
+  if (l != NULL)
+    return l;
+  else
+    /* If the address is not recognized the call comes from the main
+       program (we hope).  */
+    return GL(dl_ns)[LM_ID_BASE]._ns_loaded;
+}

 static void *
 do_sym (void *handle, const char *name, void *who,
@@ -89,13 +101,13 @@
   lookup_t result;
   ElfW(Addr) caller = (ElfW(Addr)) who;

-  struct link_map *l = _dl_find_dso_for_object (caller);
-  /* If the address is not recognized the call comes from the main
-     program (we hope).  */
-  struct link_map *match = l ? l : GL(dl_ns)[LM_ID_BASE]._ns_loaded;
+  /* Link map of the caller if needed.  */
+  struct link_map *match = NULL;

   if (handle == RTLD_DEFAULT)
     {
+      match = find_caller_link_map (caller);
+
       /* Search the global scope.  We have the simple case where
 	 we look up in the scope of an object which was part of
 	 the initial binary.  And then the more complex part
@@ -128,6 +140,8 @@
     }
   else if (handle == RTLD_NEXT)
     {
+      match = find_caller_link_map (caller);
+
       if (__glibc_unlikely (match == GL(dl_ns)[LM_ID_BASE]._ns_loaded))
 	{
 	  if (match == NULL
@@ -187,6 +201,9 @@
 	  unsigned int ndx = (ref - (ElfW(Sym) *) D_PTR (result,
 							 l_info[DT_SYMTAB]));

+	  if (match == NULL)
+	    match = find_caller_link_map (caller);
+
 	  if ((match->l_audit_any_plt | result->l_audit_any_plt) != 0)
 	    {
 	      unsigned int altvalue = 0;
@@ -198,17 +215,20 @@

 	      for (unsigned int cnt = 0; cnt < GLRO(dl_naudit); ++cnt)
 		{
+		  struct auditstate *match_audit
+		    = link_map_audit_state (match, cnt);
+		  struct auditstate *result_audit
+		    = link_map_audit_state (result, cnt);
 		  if (afct->symbind != NULL
-		      && ((match->l_audit[cnt].bindflags & LA_FLG_BINDFROM)
-			  != 0
-			  || ((result->l_audit[cnt].bindflags & LA_FLG_BINDTO)
+		      && ((match_audit->bindflags & LA_FLG_BINDFROM) != 0
+			  || ((result_audit->bindflags & LA_FLG_BINDTO)
 			      != 0)))
 		    {
 		      unsigned int flags = altvalue | LA_SYMB_DLSYM;
 		      uintptr_t new_value
 			= afct->symbind (&sym, ndx,
-					 &match->l_audit[cnt].cookie,
-					 &result->l_audit[cnt].cookie,
+					 &match_audit->cookie,
+					 &result_audit->cookie,
 					 &flags, strtab + ref->st_name);
 		      if (new_value != (uintptr_t) sym.st_value)
 			{

I have no idea if these glibc changes to discovery are relevant.

Okay, double posting for ease of discovery after that long comment. readelf -d /nix/store/bj075giskvll56sd241rvmbrny40fwzz-libredirect-0/lib/libredirect.so:
Dynamic section at offset 0x3d60 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib]
 0x000000000000000c (INIT)               0x1000
 0x000000000000000d (FINI)               0x228c
 0x0000000000000019 (INIT_ARRAY)         0x4d48
 0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x4d58
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000004 (HASH)               0x200
 0x000000006ffffef5 (GNU_HASH)           0x2c0
 0x0000000000000005 (STRTAB)             0x5c0
 0x0000000000000006 (SYMTAB)             0x320
 0x000000000000000a (STRSZ)              571 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x4f70
 0x0000000000000002 (PLTRELSZ)           264 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x968
 0x0000000000000007 (RELA)               0x8a8
 0x0000000000000008 (RELASZ)             192 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000000000001e (FLAGS)              BIND_NOW
 0x000000006ffffffb (FLAGS_1)            Flags: NOW
 0x000000006ffffffe (VERNEED)            0x838
 0x000000006fffffff (VERNEEDNUM)         2
 0x000000006ffffff0 (VERSYM)             0x7fc
 0x000000006ffffff9 (RELACOUNT)          4
 0x0000000000000000 (NULL)               0x0

Of importance is the RUNPATH, I believe. It's directly referencing /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib, and for libc.so.6 & libdl.so.2 to boot. Git directly references /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib, but only with NEEDED entries including libc.so.6 but not libdl.so.2, which makes me think glibc's dlsym(3) is preferring libdl.so.2 in just this case.
I have no idea how we'd get around this, and it's getting late here, but this is the first concept I actually feel confident on.

As you already pointed out this is most likely related to the different glibc versions in use. IMHO, the easiest way to fix this would be to wrap git in sublime-merge.
The following patch fixes the issue on my NixOS 20.03 machine:
diff --git a/pkgs/applications/version-management/sublime-merge/common.nix b/pkgs/applications/version-management/sublime-merge/common.nix
index ad540c46411..998f9f08ca6 100644
--- a/pkgs/applications/version-management/sublime-merge/common.nix
+++ b/pkgs/applications/version-management/sublime-merge/common.nix
@@ -2,7 +2,7 @@

 { fetchurl, stdenv, xorg, glib, libGL, glibcLocales, gtk3, cairo, pango, libredirect, makeWrapper, wrapGAppsHook
 , pkexecPath ? "/run/wrappers/bin/pkexec"
-, writeScript, common-updater-scripts, curl, gnugrep, coreutils
+, writeScript, common-updater-scripts, curl, gnugrep, coreutils, git
 }:

 let
@@ -91,7 +91,8 @@ in stdenv.mkDerivation (rec {

   installPhase = ''
     mkdir -p "$out/bin"
-    makeWrapper "''$${primaryBinary}/${primaryBinary}" "$out/bin/${primaryBinary}"
+    makeWrapper "''$${primaryBinary}/${primaryBinary}" "$out/bin/${primaryBinary}" \
+      --prefix PATH : ${stdenv.lib.makeBinPath [ git ]}
   '' + builtins.concatStringsSep "" (map (binaryAlias: "ln -s $out/bin/${primaryBinary} $out/bin/${binaryAlias}\n") primaryBinaryAliases) + ''
     mkdir -p "$out/share/applications"
     substitute "''$${primaryBinary}/${primaryBinary}.desktop" "$out/share/applications/${primaryBinary}.desktop" --replace "/opt/${primaryBinary}/${primaryBinary}" "$out/bin/${primaryBinary}"

After installing some logging into libredirect (which I'll probably PR soon), including passthrough-but-log dlopen(3), here are the shared object paths of both Sublime Merge right before spawning Git & Git right before segfaulting (with some post formatting).
Sublime Merge shared objects
libredirect(7090): [fopen(/home/bb010g/.config/sublime-merge/Cache/Markdown/Markdown.sublime-syntax.rcache, rb)]
  dl_names: [
    ,
    linux-vdso.so.1,
    /nix/store/j3lj96vbdiwc1b5vbsqjc1cr2kr8jk33-libredirect-0/lib/libredirect.so,
    /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/librt.so.1,
    /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libdl.so.2,
    /nix/store/50cjdvl7s00fxfn3kba34bi8nr0ziz38-glib-2.64.4/lib/libgobject-2.0.so.0,
    /nix/store/50cjdvl7s00fxfn3kba34bi8nr0ziz38-glib-2.64.4/lib/libglib-2.0.so.0,
    /nix/store/acpkm0aczyhl0j3lggpn7s4a58cx9956-libGL-1.3.1/lib/libGL.so.1,
    /nix/store/9l9xf027b896chvnbimm26g31pgkpvxx-libX11-1.6.8/lib/libX11.so.6,
    /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libm.so.6,
    /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libpthread.so.0,
    /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libc.so.6,
    /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/ld-linux-x86-64.so.2,
    /nix/store/j3d9ilj9plhhcpiv4nhilc4230bc1cw5-libffi-3.3/lib/../lib64/libffi.so.7,
    /nix/store/spllwnjhpsdli39nl99vzqw2q20av202-pcre-8.44/lib/libpcre.so.1,
    /nix/store/b9ivqdjgp8dkgvvr33ydna0nx55p1wx6-libglvnd-1.3.1/lib/libGLX.so.0,
    /nix/store/m6sz8wvmjsihmi159pd4j7zblaliarbg-libXext-1.3.4/lib/libXext.so.6,
    /nix/store/b9ivqdjgp8dkgvvr33ydna0nx55p1wx6-libglvnd-1.3.1/lib/libGLdispatch.so.0,
    /nix/store/l8bv805510i46fbcpdd775yfbayx1fdr-libxcb-1.13.1/lib/libxcb.so.1,
    /nix/store/d1i2lgi51mwvvn58pdsg11vg9pd66div-libXau-1.0.9/lib/libXau.so.6,
    /nix/store/33pkxbx8j08dhaz7mwbc6nyvpzcdmiax-libXdmcp-1.1.3/lib/libXdmcp.so.6,
    /nix/store/rvw605hhix27ri5b9xwwyyibnr5fgbkn-cairo-1.16.0/lib/libcairo.so,
    /nix/store/pj9jzslar1zdmanf306h3vf383cf3wan-pixman-0.38.4/lib/libpixman-1.so.0,
    /nix/store/7fjg1l821gma1c8vzi91gia7rwpdkd4i-fontconfig-2.13.92-lib/lib/libfontconfig.so.1,
    /nix/store/3014fh6gvjx1k5az033n7jw0l88441i0-freetype-2.10.2/lib/libfreetype.so.6,
    /nix/store/b9ivqdjgp8dkgvvr33ydna0nx55p1wx6-libglvnd-1.3.1/lib/libEGL.so.1,
    /nix/store/1wn5c8p021cm43hkxlrz1mgdpya1hps8-libpng-apng-1.6.37/lib/libpng16.so.16,
    /nix/store/l8bv805510i46fbcpdd775yfbayx1fdr-libxcb-1.13.1/lib/libxcb-shm.so.0,
    /nix/store/l8bv805510i46fbcpdd775yfbayx1fdr-libxcb-1.13.1/lib/libxcb-render.so.0,
    /nix/store/jh400yrx7cccdihkfq6cpiamqirqmifa-libXrender-0.9.10/lib/libXrender.so.1,
    /nix/store/7k9qr9k34j695fc5ls6pld8vhq0cy45j-zlib-1.2.11/lib/libz.so.1,
    /nix/store/wgvsjyw5halzhpkkn308pvi3zyqbphb0-bzip2-<IP_ADDRESS>.1/lib/libbz2.so.1,
    /nix/store/h9fpybfq9dchk6myvy33lmwyh589a148-expat-2.2.8/lib/libexpat.so.1,
    /nix/store/xhphii2b9xwb6gviqpmn4ycapzd964dz-pango-1.44.7/lib/libpango-1.0.so,
    /nix/store/s46qha1v3ivas1ji3nnj01s5rg3c3xdj-fribidi-1.0.7/lib/libfribidi.so.0,
    /nix/store/d0fz4rcry844ccfijxbw722xmc1lh72b-harfbuzz-2.6.7/lib/libharfbuzz.so.0,
    /nix/store/crl79nzvrcpkxf61a19dkmdnhgz55zgg-graphite2-1.3.14/lib/libgraphite2.so.3,
    /nix/store/xhphii2b9xwb6gviqpmn4ycapzd964dz-pango-1.44.7/lib/libpangocairo-1.0.so,
    /nix/store/xhphii2b9xwb6gviqpmn4ycapzd964dz-pango-1.44.7/lib/libpangoft2-1.0.so.0,
    /nix/store/2j0gwa4wrjah1mvj34xsz8n409n8y8ia-gtk+3-3.24.21/lib/libgdk-3.so,
    /nix/store/dkxblfvqjwyrlis0f21fcdbszgic90yv-gdk-pixbuf-2.40.0/lib/libgdk_pixbuf-2.0.so.0,
    /nix/store/rvw605hhix27ri5b9xwwyyibnr5fgbkn-cairo-1.16.0/lib/libcairo-gobject.so.2,
    /nix/store/icydxlvyk91xmhzqbvn3yci5zxfh6kxd-epoxy-1.5.4/lib/libepoxy.so.0,
    /nix/store/50cjdvl7s00fxfn3kba34bi8nr0ziz38-glib-2.64.4/lib/libgio-2.0.so.0,
    /nix/store/4sgz8pxp6b6pml2v96bf934k1f40ssl9-libxkbcommon-0.10.0/lib/libxkbcommon.so.0,
    /nix/store/v2jrrdwn697jllprgg8hs6h9gj9zil94-wayland-1.18.0/lib/libwayland-client.so.0,
    /nix/store/v2jrrdwn697jllprgg8hs6h9gj9zil94-wayland-1.18.0/lib/libwayland-cursor.so.0,
    /nix/store/v2jrrdwn697jllprgg8hs6h9gj9zil94-wayland-1.18.0/lib/libwayland-egl.so.1,
    /nix/store/ig0gncq7cr4krrzy8247n85sfyl3s9na-libXi-1.7.10/lib/libXi.so.6,
    /nix/store/r00fbj4ink4h46m6b08ycv2k27mscw68-libXcursor-1.2.0/lib/libXcursor.so.1,
    /nix/store/h5blirdisd7h8fsk7g22vm7pf1m8rki8-libXdamage-1.1.5/lib/libXdamage.so.1,
    /nix/store/qyd4j7isjamc93q7ljrq10f5klmqccxq-libXfixes-5.0.3/lib/libXfixes.so.3,
    /nix/store/i9h0y0042qqrmmv97yjavawp0c8yshv1-libXcomposite-0.4.5/lib/libXcomposite.so.1,
    /nix/store/agxh5yw0il6wxb6zinb3pv1dq1aha70b-libXrandr-1.5.2/lib/libXrandr.so.2,
    /nix/store/vcm0ix3rd88h62ril84fc9bw30354532-libXinerama-1.1.4/lib/libXinerama.so.1,
    /nix/store/50cjdvl7s00fxfn3kba34bi8nr0ziz38-glib-2.64.4/lib/libgmodule-2.0.so.0,
    /nix/store/41frqmgic34dv67yymsyg8p80wzw1jzl-util-linux-2.35.2/lib/libmount.so.1,
    /nix/store/3n2rcj1zv1n78s3qw2rgzdldk7wppxsr-libselinux-2.9/lib/libselinux.so.1,
    /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libresolv.so.2,
    /nix/store/41frqmgic34dv67yymsyg8p80wzw1jzl-util-linux-2.35.2/lib/libblkid.so.1,
    /nix/store/2j0gwa4wrjah1mvj34xsz8n409n8y8ia-gtk+3-3.24.21/lib/libgtk-3.so,
    /nix/store/3pldcpdakbknzj1y52rd26vrfa9gz5w1-atk-2.36.0/lib/libatk-1.0.so.0,
    /nix/store/wl1qslnb6654pqxg5hc5jf5vwm4xisc1-at-spi2-atk-2.34.2/lib/libatk-bridge-2.0.so.0,
    /nix/store/bn1ivmjcqv8xhiyf2fkq9l56ni8i4nrv-dbus-1.12.20-lib/lib/libdbus-1.so.3,
    /nix/store/519a4mvvrslrxsi9747vsz12hggwaz0a-at-spi2-core-2.36.0/lib/libatspi.so.0,
    /nix/store/3vznkmsm8mipqks12pl4383f9jmwzkff-systemd-245.6-lib/lib/libsystemd.so.0,
    /nix/store/dj857vbf0mnrqfh29pjz8kchpb8sl8xb-xz-5.2.5/lib/liblzma.so.5,
    /nix/store/m3d4alqnjhqb46cgz3an25qyrr06kzlb-lz4-1.9.2/lib/liblz4.so.1,
    /nix/store/lw0k97c2m7q3qk3c0zw67ymh2k2hxczy-libcap-2.27-lib/lib/libcap.so.2,
    /nix/store/m387fasf3n7mhyrmzjxdgzx4n99f08h8-libgcrypt-1.8.6/lib/libgcrypt.so.20,
    /nix/store/0g0ikqc1qvwk2n7xspd5nsr3ndn1apxf-libgpg-error-1.38/lib/libgpg-error.so.0,
    /nix/store/dkxblfvqjwyrlis0f21fcdbszgic90yv-gdk-pixbuf-2.40.0/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so,
    /nix/store/gxdvrsd74c5p6ikics797243wb02nhbl-dconf-0.36.0-lib/lib/gio/modules/libdconfsettings.so,
    /nix/store/y0x2sdyc6zdgci27wd6wb4ijzg09x9sp-gvfs-1.42.2/lib/gio/modules/libgioremote-volume-monitor.so,
    /nix/store/y0x2sdyc6zdgci27wd6wb4ijzg09x9sp-gvfs-1.42.2/lib/gvfs/libgvfscommon.so,
    /nix/store/y0x2sdyc6zdgci27wd6wb4ijzg09x9sp-gvfs-1.42.2/lib/gio/modules/libgvfsdbus.so
  ]

Git shared objects
libredirect(7106): [open64(/dev/null, 2, ...)]
  dl_names: [
    ,
    linux-vdso.so.1,
    /nix/store/j3lj96vbdiwc1b5vbsqjc1cr2kr8jk33-libredirect-0/lib/libredirect.so,
    /nix/store/mr8q9cdzmpgc8q8jy2s2fgk50kxmkqjv-pcre2-10.34/lib/libpcre2-8.so.0,
    /nix/store/msp4hm62a75pdidlc3s2ymma2g5hsjjk-zlib-1.2.11/lib/libz.so.1,
    /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/librt.so.1,
    /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libgcc_s.so.1,
    /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libpthread.so.0,
    /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libc.so.6,
    /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libdl.so.2,
    /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/ld-linux-x86-64.so.2
  ]

Git is launching with a completely separate set of dynamic libraries, as it should. Also, no libraries are getting loaded after libredirect.so—the ones that do in Sublime Merge do show up in dlopen calls, but the one pasted here is the only entry for Git. This matches up with @jtojnar's reproducing example that shows a lack of dependence on a parent with both libredirect and a different (g)libc, which I didn't grok enough until after my previous 2 comments.
The core dump backtrace still shows the crash occurring during libredirect's open64, loaded into the libdl it was built with, the one library from new glibc, during libdl's dlsym, when it tries to call an address defined in <_rtld_global@GLIBC_PRIVATE> in ld-linux-x86-64.so.2, which in this case is loaded from a foreign glibc.
readelf -d /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libc.so.6
Dynamic section at offset 0x1b79e0 contains 27 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x000000000000000e (SONAME)             Library soname: [libc.so.6]

readelf -d /nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib/libdl.so.2
Dynamic section at offset 0x2cf8 contains 31 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x000000000000000e (SONAME)             Library soname: [libdl.so.2]

So, libredirect.so has NEEDED entries for libdl.so.2 and libc.so.6, and a RUNPATH for new glibc. Git has a NEEDED entry for libc.so.6, and a RUNPATH for old glibc. So, the old libc.so.6 & ld-linux-x86-64 are loaded from the initial Git libc.so.6 request, the new libdl.so.2 is loaded from Git's libredirect.so request, and both of the libdl.so.2 dependencies are already provided (by old glibc, though if they weren't loaded they'd come from new glibc). Also, multiple copies of a shared object are shown not to load from new glibc not loading in addition to new libdl.so.2.
So, my proposition to make libredirect not segfault is to statically link libredirect against Musl.

Unstale

@bb010g Thanks for this research.

my proposition to make libredirect not segfault is to statically link libredirect against Musl.

How could that be done?
I searched a bit for "statically linked .so", and found https://musl.openwall.narkive.com/piLvnZjo/how-to-build-libc-a-with-fpic-for-all-archive-members which sounds like what you suggest, but the final answer was:

This is not intended to be possible, and there are many things that would break. Among them: ...


New Service Fabric Rest Client

Packages impacted by this PR
New @azure-rest/service-fabric
Issues associated with this PR
N/A
Describe the problem that is addressed by this PR
Adding a new Rest Client library for Service Fabric data plane
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
N/A
Are there test cases added in this PR? (If not, why?)
Yes
Provide a list of related PRs (if any)
N/A
Command used to generate this PR:**(Applicable only to SDK release request PRs)
rushx generate:client
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-rest-service-fabric


Is there a release timeline for v4?

I don't mean to apply pressure at all by my title question.  I totally understand this is OSS and people have other lives, both inside and out of work.  All I'm asking is if there is a plan to release soon, or if not is there a specific breaking feature missing that would preclude it?
I have a working use case using 4.0.0-beta.13 but I'm obviously reluctant to commit my use of a beta package without some guarantees on changes.

There is no time commitment. But w heave landed the lost significant changes for V4. Beta 13 already contains many of them, 14 will contain some API signature changes.
Might be the last beta, but no promises.
In an ideal world we ship 4.0 this year.


Allow datacenters to use the state backend as a secret store

Is your feature request related to a problem? Please describe.
Right now, our example local datacenter, ./__tests__/datacenters/local.yml, requires the user to provide an account that is to be used to store secrets for the datacenter. This can be a confusing first-touch experience.
Describe the solution you'd like
It would be great if datacenters could be designed to automatically utilize the CLIs state.backend to store secrets since it is, after all, an account that can store secrets.
# example datacenter file

environment:
  hooks:
    - when:
        type: secret
      account: ${{ system.backend.account }}

Accounts and providers have been deprecated. Closing.


Fix generation of loss spec from output spec

Description
In PiPPy we automatically generate loss spec from output chunk spec.
Terminology:
"loss spec": a one-hot map indicating which output value is a loss. It consists of True, False values.
"output chunk spec": a data structure corresponding to output format describing which (chunked) value should be merged and which should be reduced (such as loss).
Issue
In previous code, we only considered the case where the output chunk spec is a dictionary.
But in cases such as return logits, loss, the output chunk spec is a tuple, i.e. (TensorChunkSpec(0), sum_reducer).
Fix
Use fx.node.map_aggregate to generalize the auto generation.
It takes a lambda function that outputs True/False.
Testing
torchrun --nproc-per-node 4 local_test_chunkspec.py

Thanks for fixing this!


Black outlines for Pokemon sprites

RimWorld pawns mostly have black outlines, so I haphazardly batched in some outlines. Could use some feedback.
Definitely obscures some finer details in a few of the sprites, but I personally like the result. Use it if you want :)
Style settings used in Photoshop:

I made some previews for comparison. Not all of the sprites are shown, but it gives a decent overview of the differences.
Before (click for full size):

After (click for full size):

Wow nice work! It does look better, I'm definitely merging that.


Add segments array to CircularInstance

This is needed because a circular instance are set by updating CircularIntance.segments[0].value. See update() example in the following documentation: http://www.chartjs.org/docs/#doughnut-pie-chart-prototype-methods.

@Slimfit thanks mate!


Added reading from temp urls

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

Fixes #97

@gilv This is ready for review

@djalova thanks. works perfectly. i will merge it.


Performance doubt

Is the csx file interpret or compile?
I had test by a O(n log n) algorithm with 20,000 data point.

The standard .net core console takes about 45 seconds.
The csx which run by dotnet-script takes about 64 seconds.

Both are run in Release mode, same code.

it's compiled, cached and run.
second run would be fast

This is my code, if it's compiled I don't think the Stopwatch.Elapsed will includes the compile time.
And I run it 3 times, but same result, it looks far from 45 seconds.

yeah you are only measuring execution time. there is not interpreted C# support in the C# compiler. scripting here is just a syntactic trick

So what caused the performance difference?

you should open an issue in the compiler repository https://github.com/dotnet/roslyn
we are only users of the compiler API and the execution performance difference here is not cause by dotnet-script but some behavior of the compiler (or the runtime)


Fix unescaped string

Fixes https://github.com/PrestaShop/PrestaShop/issues/15329
This fix has been verified by me on 1.7.7.x:

Thanks @eternoendless & @sarahdib


#64 Mandator administration section is not implemented at all yet

@rultor merge

@proshin-roman Done! FYI, the full log is here (took me 2min)


Unable to login in Telegram

Unable to login in Telegram, Infinity loading and can't loading QR Code

Same here for Telegram and Whatsup equally.

QR-Code not working in both
Telegram Login via User/Pass isn't loading after pressing login
Distro: Fedora 35

(Slack i.e. seems to be broken too. It is working to login but not able to finish loading the slack-deck. Infinity reloading)


[Bug]: useCompilerFolder seams to have side effects when dontPublish is false.

AL-Go version
6.0
Describe the issue
Hi,
I've enabled useCompilerFolder to try and achieve faster failures when the app compilation fails.
That's didn't seem to work when your apps have dependencies.
We have App B which depends on App A. App A is correctly downloaded from our internal Nuget Feed the compilation works correct. But when trying to install the previous version of App B the Action fails with the error that required objects are missing.
We had the same error when upgrading to AL-GO v6 when only the symbols for App A where resolved from the Microsoft feeds.So my best guess is that the useCompileFolder Option turns app files into symbols. I checked to see App A was resolved in the correct version from our feed and was present as a full app.
Removing the useCompileFolder option fixed the error.
Expected behavior
Well useCompileFolder should not create a state where action fail. Secondly it would be good to be able to fail fast in case of compilation errors. Pretty wasteful to spin up a docker container only to realize it not even compiling.
Steps to reproduce
Create 2 Apps which depend on each other. And then enable useCompileFolder.
Additional context (logs, screenshots, etc.)
No response

As described on https://aka.ms/algosettings#useCompilerFolder - you need to also set doNotPublishApps in order to get a performance enhancement. I tried to reproduce the issue you are talking about here - but cannot:
This repo has 3 apps and one is dependent on another:
https://github.com/BusinessCentralApps/GHP-Common/actions/runs/11511476130/job/32044989671
Building using CompilerFolder without doNotPublishApps.

But, you are right that we should wait with the creation of the container until we actually need it.

Now, I think I was able to repro this - the problem is when you have two repositories with apps with dependencies - then the compilation works, but the deployment fails.
Is this the problem you are referring to?
https://github.com/BusinessCentralApps/GHP-W1/actions/runs/11511743372/job/32045671301

I don't think its the same error. Our error happens in "installing previous app"
Maybe the diffrence is that we use useProjectDependencies.
App A and App B are in diffrent projects.

 Symbols for the requested app BeyondRecordSearch by BEYONDIT GmbH <IP_ADDRESS> could not be found in the database.
  error AL1024: A package with publisher 'BEYONDIT GmbH', name 'BeyondAttributesCore', and a version compatible with '<IP_ADDRESS>' could not be loaded. Symbols for the requested app BeyondAttributesCore by BEYONDIT GmbH <IP_ADDRESS> could not be found in the database.
  src/RecordSearchEvents.Codeunit.al(3,54): error AL0118: The name '"BYD RS Record Search Mgt."' does not exist in the current context.
  src/ServiceItemSearch.Codeunit.al(16,32): error AL0185: Table 'BYD AT Attribute Value Mapping' is missing
  src/ServiceItemSearch.Codeunit.al(23,44): error AL0185: Table 'BYD RS Record Search Column' is missing
  src/RecordSearchEvents.Codeunit.al(4,89): error AL0185: Interface 'BYD RS IRecordSearchProvider' is missing
  src/ServiceItemSearch.Codeunit.al(44,100): error AL0185: Table 'BYD RS Record Search Column' is missing
  src/ServiceItemSearch.Codeunit.al(44,166): error AL0185: Table 'BYD RS Record Search Filter' is missing
  src/ServiceItemSearch.Codeunit.al(44,233): error AL0185: Table 'BYD RS Record Search Sorting' is missing
  src/ServiceItemSearch.Codeunit.al(44,302): error AL0185: Table 'BYD RS Record Search Row Value' is missing
  src/ServiceItemSearch.Codeunit.al(47,32): error AL0185: Table 'BYD AT Attribute Value Mapping' is missing
  src/ServiceItemSearch.Codeunit.al(107,118): error AL0185: Table 'BYD RS Record Search Column' is missing
  src/ServiceItemSearch.Codeunit.al(117,149): error AL0185: Table 'BYD RS Record Search Row Value' is missing
  src/ServiceItemSearch.Codeunit.al(128,61): error AL0185: Table 'BYD AT Attribute Value Mapping' is missing
  src/ServiceItemSearch.Codeunit.al(128,120): error AL0185: Table 'BYD RS Record Search Column' is missing
  src/ServiceItemSearch.Codeunit.al(128,186): error AL0185: Table 'BYD RS Record Search Filter' is missing
  src/ServiceItemSearch.Codeunit.al(128,253): error AL0185: Table 'BYD RS Record Search Sorting' is missing
  src/ServiceItemQuery.Query.al(39,54): error AL0185: Table 'BYD AT Attribute Value Mapping' is missing
  src/ServiceItemQuery.Query.al(41,32): error AL0171: The property value 'Id = Service_Item."BYD RSAB RecordId"' on property 'DataItemLink' is not valid.
  src/ServiceItemSearch.Codeunit.al(1,61): error AL0185: Interface 'BYD RS IRecordSearchProvider' is missing
  src/ServiceItemQuery.Query.al(43,40): error AL0345: The source of a Column or Filter must be a field defined on the table referenced by its parent DataItem
  src/ServiceItemQuery.Query.al(43,24): error AL0353: A Column must have a valid data source or have the 'Method' property set to 'Count'
  src/ServiceItemQuery.Query.al(47,46): error AL0345: The source of a Column or Filter must be a field defined on the table referenced by its parent DataItem
  src/ServiceItemQuery.Query.al(47,24): error AL0353: A Column must have a valid data source or have the 'Method' property set to 'Count'

  Exception Script Stack Trace:
  at <ScriptBlock>, <No file>: line 41

  PowerShell Call Stack:
  at Invoke-ScriptInBcContainer, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\ContainerHandling\Invoke-ScriptInNavContainer.ps1: line 71
  at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\AppHandling\Publish-NavContainerApp.ps1: line 379
  at Publish-BcContainerApp, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\AppHandling\Publish-NavContainerApp.ps1: line 154
  at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\AppHandling\Run-AlPipeline.ps1: line 873
  at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\AppHandling\Run-AlPipeline.ps1: line 2208
  at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\AppHandling\Run-AlPipeline.ps1: line 2189
  at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\AppHandling\Run-AlPipeline.ps1: line 2184
  at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\AppHandling\Run-AlPipeline.ps1: line 977
  at Run-AlPipeline, C:\ProgramData\BcContainerHelper\6.0.26\BcContainerHelper\AppHandling\Run-AlPipeline.ps1: line 939
  at <ScriptBlock>, C:\3\_work\_actions\microsoft\AL-Go-Actions\v6.0\RunPipeline\RunPipeline.ps1: line 391
  at <ScriptBlock>, C:\3\_work\_temp\403ce9da-ac3d-4103-807e-b6991c4f0d66.ps1: line 3
  at <ScriptBlock>, C:\3\_work\_actions\microsoft\AL-Go-Actions\v6.0\Invoke-AlGoAction.ps1: line 17
  at <ScriptBlock>, C:\3\_work\_temp\403ce9da-ac3d-4103-807e-b6991c4f0d66.ps1: line 2
  at <ScriptBlock>, <No file>: line 1

  Container Free Physical Memory: 8.3Gb
  Disk C: Free 124Gb from 127Gb

  Services in container bcBeyondAttributesBridge11403259053:
  - MicrosoftDynamicsNavServer$BC is Running
  - MSSQL$SQLEXPRESS is Running
  Publish-BcContainerApp Telemetry Correlation Id: 66d28d85-e005-4071-9f23-62d84c7d4eb1

And regarding the performance improvement. I read the docs but I wanted to see if it would improve performance in failure szenarios. Because it would fail before the container is created to skipping the unnessary time of container creation.

BeyondRecordSearch was build in Build1 BeyondAttributeCore is build in another repo and downloaded from nuget.

Will investigate

Will let you know when you try out a test branch on one of your own forks or branches.


some cleanup; newest libraries; get tests to work again

some cleanup in queue API
update to newest libraries
get tests to work again

Replaces https://github.com/tools4j/mmap/pull/9
@anton-anufriev if you are happy with the changes with can repoint this one to master and merge directly

replaced by https://github.com/tools4j/mmap/pull/11


Website TLS version is out of date

I recently visited https://www.esmvaltool.org/ , and Firefox (version 78) refused to load the webpage; its error message suggests the TLS version is too old, i.e., version 1.1 or 1.0. These two version have been deprecated in 2020. Chrome (version 84) does load the page, but shows a "Not Secure" indication, even if the URL starts with https.
Probably, the webserver software needs an update.
Side note: the main ESMValGroup GitHub page has a link to http://www.esmvaltool.org instead of the https version, but the former redirects to the latter (and consequently consequently fails in Firefox).

Just updated the ESMValGroup URL from http to https and inquired with our it department about the possibility of updating the TLS version used by esmvaltool.org.

@axel-lauer Any news from the IT department?

It's still on their radar but more urgent tasks are keeping them busy at least all of September... I will inquire again early October just to make sure they did not forget.

ping the DLR IT geeks via @axel-lauer :grin:

The update had been scheduled for yesterday but then had to be postponed. Hoping this will take place soon...

they're watching the US Eelections, don't get fooled they're busy :grin:

Finally, the TLS version used by esmvaltool.org has been updated!


MF-888 - SDK tests

What does this do?
Added SDK tests
Which issue(s) does this PR fix/relate to?
Resolves #888
List any changes that modify/break current functionality
Have you included tests for your changes?
SDK Tests
Did you document any new/modified functionality?
No
Notes

Codecov Report

Merging #1629 (3b3a034) into master (931b48f) will increase coverage by 1.98%.
The diff coverage is 76.47%.

@@            Coverage Diff             @@
##           master    #1629      +/-   ##
==========================================
+ Coverage   69.18%   71.17%   +1.98%
==========================================
  Files         138      138
  Lines       11231    11218      -13
==========================================
+ Hits         7770     7984     +214
+ Misses       2769     2472     -297
- Partials      692      762      +70

Impacted Files
Coverage Δ

pkg/sdk/go/bootstrap.go
50.00% <0.00%> (+50.00%)
:arrow_up:

pkg/sdk/go/responses.go
0.00% <ø> (ø)

pkg/sdk/go/sdk.go
81.13% <ø> (ø)

pkg/sdk/go/certs.go
62.16% <81.25%> (+62.16%)
:arrow_up:

pkg/messaging/nats/publisher.go
59.09% <0.00%> (+9.09%)
:arrow_up:

pkg/sdk/go/keys.go
56.86% <0.00%> (+56.86%)
:arrow_up:

pkg/sdk/go/groups.go
60.46% <0.00%> (+60.46%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@zzokki81 Can you, please, resolve conflicts so we can review the PR?

There was changes in SDK

@zzokki81 Can you, please, resolve conflicts so we can review the PR?
Sure, I'll take a look at that.


tour:

Context: https://go-tour-ru-ru.appspot.com/basics/3
just run the program in editor - "Error communicating with remote server."
Probably its because selecting ru language. See url - "ru-ur" probably problem here

fixed by reset button, but by default server not responding


[BugFix] Fix NPE from trim() method when no enable parameter given in GlobalDictMetaService request

Why I'm doing:
When no enable parameter given in request trim() method throws NPE.
What I'm doing:
Setted that parameter default as true and add controls.
Fixes #issue
What type of PR is this:

[X] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[X] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.2
[x] 3.1
[x] 3.0
[ ] 2.5

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@Mesut-Doner could you sign-off this PR by git commit -s

@Mesut-Doner I have merged this PR into main branch, but there are some conflicts to backport to branch-3.2 3.1 and 3.0, do you want to resolve all this conflicts?

@Mesut-Doner I have merged this PR into main branch, but there are some conflicts to backport to branch-3.2 3.1 and 3.0, do you want to resolve all this conflicts?

Hello @imay, many thanks. Do you mean creating new PR's manually for 3.2 - 3.1 - 3.0 branches after resolving conflicts?

@Mesut-Doner I have merged this PR into main branch, but there are some conflicts to backport to branch-3.2 3.1 and 3.0, do you want to resolve all this conflicts?

Hello @imay, many thanks. Do you mean creating new PR's manually for 3.2 - 3.1 - 3.0 branches after resolving conflicts?

I will take care of this.


What type of update are you requesting?
A new version of an existing package
Current Package Identifier
Fortinet.FortiClientVPN
Package Version
7.4.1
Please describe the changes you would like to see
to get the msi you've to download the exe from official website:
https://links.fortinet.com/forticlient/win/vpnagent
lauch it for download files and get msi from temp folder
regards

https://github.com/microsoft/winget-pkgs/pull/166074
https://github.com/microsoft/winget-pkgs/issues/166049
https://github.com/microsoft/winget-pkgs/issues/164057

can't we provide it? because we can downlaod it with forti support account

Has to be first party hosted for, as far as I understand, security reasons.
If Forti has locked the download behind a paywall, not much we can do sadly :(


Unable to extract yt initial data

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting that yt-dlp is broken on a supported site
[X] I've verified that I'm running yt-dlp version 2023.07.06 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
Germany
Provide a description that is worded well enough to be understood
when am trying to download any video from youtube i got this errors, on all of my VPS ( Germany and Netherlands )
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
root@vmi1388531:~# yt-dlp -vU -f b https://youtu.be/8EzYoUxkg9c
[debug] Command-line config: ['-vU', '-f', 'b', 'https://youtu.be/8EzYoUxkg9c']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b532a3481] (pip)
[debug] Python 3.8.10 (CPython x86_64 64bit) - Linux-5.4.0-105-generic-x86_64-with-glibc2.29 (OpenSSL 1.1.1f  31 Mar 2020, glibc 2.31)[debug] exe versions: ffmpeg 4.2.7, ffprobe 4.2.7
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2019.11.28, mutagen-1.46.0, secretstorage-2.3.1, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1855 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>yt-dlp is up to date<EMAIL_ADDRESS>[youtube] Extracting URL: https://youtu.be/8EzYoUxkg9c
[youtube] 8EzYoUxkg9c: Downloading webpage
WARNING: [youtube] unable to extract initial player response; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
[youtube] 8EzYoUxkg9c: Downloading ios player API JSON
[youtube] 8EzYoUxkg9c: Downloading android player API JSON
[youtube] 8EzYoUxkg9c: Downloading iframe API JS
[youtube] 8EzYoUxkg9c: Downloading player 7ee36b0e
[youtube] 8EzYoUxkg9c: Downloading web player API JSON
[youtube] 8EzYoUxkg9c: Downloading m3u8 information
WARNING: [youtube] unable to extract yt initial data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
WARNING: [youtube] Incomplete data received in embedded initial data; re-fetching using API.
[youtube] 8EzYoUxkg9c: Downloading initial data API JSON
[debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec:vp9.2, channels, acodec, lang, proto
[debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec:vp9.2(10), channels, acodec, lang, proto, size, br, asr, vext, aext, hasaud, id
[info] 8EzYoUxkg9c: Downloading 1 format(s): 22
[debug] Invoking http downloader on "https://rr5---sn-4g5lznl6.googlevideo.com/videoplayback?expire=1694199441&ei=MRr7ZIzzHfaZ6dsP1LO2sAE&ip=<IP_ADDRESS>&id=o-AH2OPcq9r7GvRpSF-NYQgwKChhTGAJ3A_oE83pXYEhdR&itag=22&source=youtube&requiressl=yes&mh=tP&mm=31%2C26&mn=sn-4g5lznl6%2Csn-5hne6nsy&ms=au%2Conr&mv=u&mvi=5&pl=24&gcr=de&spc=UWF9f68WW2w5apglf89nUBSHC7kcrIM&vprv=1&svpuc=1&mime=video%2Fmp4&cnr=14&ratebypass=yes&dur=399.151&lmt=1575362039116829&mt=1694177169&fvip=1&fexp=24007246%2C51000022&beids=24350018&c=ANDROID&txp=1311222&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Ccnr%2Cratebypass%2Cdur%2Clmt&sig=AOq0QJ8wRgIhAMJJnxTbte7T5PbzfmuIs9AdAtKBCkiMob75MMEmN758AiEAvwi9XlchSci3GIk_nBHkSW23SPQu9sY9RI4fgzPoOq0%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl&lsig=AG3C_xAwRQIgdb8gXtPkxeYb8nArGumcdrYBkBcGTwyErJEks9rBdssCIQCB2ik6iPrkPne1gh7y5vh6HHh9ewBJEeu0ENAAu8Zp4A%3D%3D"
ERROR: unable to download video data: HTTP Error 403: Forbidden
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/yt_dlp/YoutubeDL.py", line 3363, in process_info
    success, real_download = self.dl(temp_filename, info_dict)
  File "/usr/local/lib/python3.8/dist-packages/yt_dlp/YoutubeDL.py", line 3084, in dl
    return fd.download(name, new_info, subtitle)
  File "/usr/local/lib/python3.8/dist-packages/yt_dlp/downloader/common.py", line 461, in download
    ret = self.real_download(filename, info_dict)
  File "/usr/local/lib/python3.8/dist-packages/yt_dlp/downloader/http.py", line 377, in real_download
    establish_connection()
  File "/usr/local/lib/python3.8/dist-packages/yt_dlp/downloader/http.py", line 129, in establish_connection
    ctx.data = self.ydl.urlopen(request)
  File "/usr/local/lib/python3.8/dist-packages/yt_dlp/YoutubeDL.py", line 3863, in urlopen
    return self._opener.open(req, timeout=self._socket_timeout)
  File "/usr/lib/python3.8/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.8/urllib/request.py", line 640, in http_response
    response = self.parent.error(
  File "/usr/lib/python3.8/urllib/request.py", line 569, in error
    return self._call_chain(*args)
  File "/usr/lib/python3.8/urllib/request.py", line 502, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.8/urllib/request.py", line 649, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 403: Forbidden

root@vmi1388531:~#

Duplicate of #7860
tl;dr: your VPS' IP has been blocked by Youtube
workarounds:

try passing -4 or -6
pass logged in youtube cookies (refreshed w/in the last 30 minutes)
change your IP or use a proxy


Include .nojekyll file

This bypasses Jekyll processing and insures that files or folders that start with an underscore (that Sphinx generates) are copied to the served site.
See https://github.blog/2009-12-29-bypassing-jekyll-on-github-pages/

@hpenedones I've noticed that you guys fixed the .nojekyllscenario yesterday but apparently also broke the build. This PR fixes the build 😄


luci-app-attendedsysupgrade: Fix logic error in EFI image selection

If a non-EFI image comes first in the list of images, it would have been selected even on an EFI system.
Closes: openwrt/luci#6884
@aparcar

[x] This PR is not from my main or master branch :poop:, but a separate branch :white_check_mark:
[x] Each commit has a valid :black_nib: Signed-off-by<EMAIL_ADDRESS>row (via git commit --signoff)
[x] Each commit and PR title has a valid :memo: <package name>: title first line subject for packages
[ ] Incremented :up: any PKG_VERSION in the Makefile
[x] Tested on: (x86-64, <IP_ADDRESS>, Firefox) :white_check_mark:
[x] ( Preferred ) Mention: @ the original code author for feedback
[ ] ( Preferred ) Screenshot or mp4 of changes:
[x] ( Optional ) Closes: e.g. openwrt/luci#issue-number
[x] Description: (describe the changes proposed in this PR)

Thank you for this comprehensive PR @sur5r. I thought this was weird because when I was comparing your PR, I had v22 branch checked out. It was identical. So I understood that it had been changed between v22 and master for some important reason.
Please refer to #6623 and d7e905e83a11d59ea217cd37189040bd6c9d403e.
Your fix functionally reverts the above-mentioned commits. ( Meaning if we revert, it once again causes problems a la #6623 ) But for you, it works?
The before and after code seem functionally synonymous:
					if (this.data.efi) {
						if (image.type == 'combined-efi') {
							return image;
						}

vs
					if (this.data.efi && image.type == 'combined-efi') {
						return image;

...

Not, it doesn't revert d7e905e83a11d59ea217cd37189040bd6c9d403e. The problem is very subtle.
The code as currently in master is sensitive to the order of images in the array. It does not reject non-EFI images on EFI systems.
The code before and after is not synonymous as the else part is connected differently.
Please see the following JS code. It contains both the old and the new selectImage function (slightly adapted to work outside a class) and applies them to the image list from #6884.
images = [
    {
      "filesystem": "ext4",
      "name": "openwrt-23.05.2-afe704423c9b-x86-64-generic-ext4-combined.img.gz",
      "sha256": "a3c2bbb19d48561f95dae77b89f0d8b9b248b38c1dd9182812713393c632d2c0",
      "sha256_unsigned": "37cb2e2122e35a4f5025b15f6d7d207f90feb6addf1649cf5637a5245769c1d6",
      "type": "combined"
    },
    {
      "filesystem": "squashfs",
      "name": "openwrt-23.05.2-afe704423c9b-x86-64-generic-squashfs-combined-efi.img.gz",
      "sha256": "cc51a6393a51c17ef608fb4fdb2cff2c04e0b0e8c8bdb7f3ad607a8ec300836a",
      "sha256_unsigned": "1363ee584ba83972cde8cab83ceee8a0eaa89bc2471d755fdb22ee1d872004c5",
      "type": "combined-efi"
    },
    {
      "filesystem": "squashfs",
      "name": "openwrt-23.05.2-afe704423c9b-x86-64-generic-squashfs-combined.img.gz",
      "sha256": "8cad7d9b8cdac568e5b94fde76ab8607fbecb81e4556cba061493bb8a21636a4",
      "sha256_unsigned": "0164c07ff181050d848bac9478db1f424ea76d70aee1c26c1395308b35effed5",
      "type": "combined"
    },
    {
      "filesystem": "squashfs",
      "name": "openwrt-23.05.2-afe704423c9b-x86-64-generic-squashfs-rootfs.img.gz",
      "sha256": "9fbf34e74d680d769c8b4af748e2585d2328c2586b63d1e53b43f72596f48ff6",
      "sha256_unsigned": "9fbf34e74d680d769c8b4af748e2585d2328c2586b63d1e53b43f72596f48ff6",
      "type": "rootfs"
    },
    {
      "filesystem": "ext4",
      "name": "openwrt-23.05.2-afe704423c9b-x86-64-generic-ext4-combined-efi.img.gz",
      "sha256": "63536ad2d836c7a6885fdd83abc9d5b06168d432b7d6a76c680af79d8312d00f",
      "sha256_unsigned": "7a1068e802164370e3ab4025f5e7d02176a9c842bdbfa6f32c2b48f7715aa637",
      "type": "combined-efi"
    },
    {
      "filesystem": "ext4",
      "name": "openwrt-23.05.2-afe704423c9b-x86-64-generic-ext4-rootfs.img.gz",
      "sha256": "dfd3badb2c8fd95791519ef979332ff427b76ae0b191d64a8001cc7ee2987516",
      "sha256_unsigned": "dfd3badb2c8fd95791519ef979332ff427b76ae0b191d64a8001cc7ee2987516",
      "type": "rootfs"
    }
  ]

firmware = { "filesystem": "ext4", target :"x86/64" }
data = { "efi": "yes" }

selectImage_new=function (images,firmware,data) {
	let image;
	for (image of images) {
		if (firmware.filesystem == image.filesystem) {
			// x86 images can be combined-efi (EFI) or combined (BIOS)
			if(firmware.target.indexOf("x86") != -1) {
				if (data.efi) {
					if (image.type == 'combined-efi') {
						return image;
					}
				} else if (image.type == 'combined') {
					return image;
				}
			} else {
				if (image.type == 'sysupgrade' || image.type == 'combined') {
					return image;
				}
			}
		}
	}
	return null;
}

selectImage_old = function (images,firmware,data) {
	let image;
	for (image of images) {
		if (firmware.filesystem == image.filesystem) {
			// x86 images can be combined-efi (EFI) or combined (BIOS)
			if(firmware.target.indexOf("x86") != -1) {
				if (data.efi && image.type == 'combined-efi') {
					return image;
				} else if (image.type == 'combined') {
					return image;
				}
			} else {
				if (image.type == 'sysupgrade' || image.type == 'combined') {
					return image;
				}
			}
		}
	}
	return null;
}

console.log("selectImage_new:")
console.log(selectImage_new(images,firmware,data))
console.log("selectImage_old:")
console.log(selectImage_old(images,firmware,data))

Running it shows the behavior as mentioned:
$ js selectImage.js
selectImage_new:
{
  filesystem: 'ext4',
  name: 'openwrt-23.05.2-afe704423c9b-x86-64-generic-ext4-combined-efi.img.gz',
  sha256: '63536ad2d836c7a6885fdd83abc9d5b06168d432b7d6a76c680af79d8312d00f',
  sha256_unsigned: '7a1068e802164370e3ab4025f5e7d02176a9c842bdbfa6f32c2b48f7715aa637',
  type: 'combined-efi'
}
selectImage_old:
{
  filesystem: 'ext4',
  name: 'openwrt-23.05.2-afe704423c9b-x86-64-generic-ext4-combined.img.gz',
  sha256: 'a3c2bbb19d48561f95dae77b89f0d8b9b248b38c1dd9182812713393c632d2c0',
  sha256_unsigned: '37cb2e2122e35a4f5025b15f6d7d207f90feb6addf1649cf5637a5245769c1d6',
  type: 'combined'
}

Thinking about it, the function seems very fragile. How about switching it to array.filter() instead?
Rough sketch:
selectImage_filter = function(images,firmware,data) {
        fsfilter=function(e) {
                return (e.filesystem == firmware.filesystem);
        }
        typefilter=function(e) {
                if(firmware.target.indexOf("x86") != -1 && data.efi)
                {
                        if(data.efi)
                                return (e.type == 'combined-efi')
                        else
                                return (e.type == 'combined');
                }
                else
                {
                        return(e.type == 'sysupgrade' || e.type == 'combined');
                }

        }
        return images.filter(fsfilter).filter(typefilter)[0]
}

Thinking about it, the function seems very fragile. How about switching it to array.filter() instead?

I was going to suggest the same thing initially until I thought it best to understand some more details.
Sure, filter. Then we avoid these subtle if clause problems.  Perhaps doing away with the if altogether.

I just looked at https://github.com/openwrt/packages/blob/master/utils/auc/src/auc.c#L1653 and find that approach interesting as well. It has a clear preference spelt out as code.
I could write an alternative implementation using filter and easily test it on all 4 x86 variants (MBR/EFI, ext4/squashfs). The only embedded device I could currently test this on is a FritzBOX 7412.
Should I replace it here or open an alternative PR?

Here is fine. The filter aims to resolve the same bug :) thanks for taking
a stab at it.
The fritz boxes are all generally arm or ath, which iirc take a sysupgrade
Message ID: @.***>

Rewritten using filter functions.
Tested sucessfully on:

QEMU x86_64 ext4 BIOS
QEMU x86_64 ext4 EFI
QEMU x86_64 squashfs BIOS
QEMU x86_64 squashfs EFI
TP-Link TL-WDR4300 v1 squashfs

Unfortunately, I'm not a JS developer as well. I guess it would be great to have auc and luci-app-attendedsysupgrade behave identically, but I understand that this is a lot of work.


Update Plugin Artifacts Links for v0.158.9

Automated changes by create-pull-request GitHub action

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.