File owned by my LD_PRELOAD library gets closed somewhere

This seems problematic -- is the second call under the call stack of the first? It may be that you've caused unintentional recursion somehow.

The brk system call is used to resize the heap.

Wild guess, perhaps the duplicated initialization has corrupted some of regex's internal caches?

Life before main is really hard to get right, which is why it's usually advised to avoid that, or keep it minimal if you must use constructors.

From what I can tell there is no recursion.
The initialization of APP64BITONLY_PATTERNS uses data read into CONFIG, that happens before this like as follows. commented works. uncomment crashes.

        lazy_static::initialize(&CONFIG);
//        lazy_static::initialize(&APP64BITONLY_PATTERNS);
        lazy_static::initialize(&TRACKER);

I can tell based on strace above, the brk's happen during and the code for it

    pub static ref  APP64BITONLY_PATTERNS: RegexSet = {
        event!(Level::INFO, "APP64BITONLY_PATTERNS Reading....");
        let p: Vec<String> = if CONFIG.app64bitonly_patterns.is_empty() {
            CONFIG.app64bitonly_patterns.iter().map(|v| {
                if v.starts_with("^") {
                    render(v,&TEMPLATEMAP)
                } else {
                    let mut x = "^".to_owned();
                    x.push_str("{{RE_WSROOT}}");
                    x.push_str("/");
                    x.push_str(v);
                    // eprintln!("REGEX: {}", x.as_str());
                    render(x.as_str(),&TEMPLATEMAP)
                }
            }).collect()
        } else {
            vec!("^NOMATCH/.*$".to_owned())
        };
        event!(Level::INFO,"p: {:?}", p);
        let x = RegexSet::new(&p).unwrap_or_else(|e| {
            errorexit!("WISK_ERROR: Error compiling list of regex in app_64bitonly_match: {:?}", e);
        });
        event!(Level::INFO, "APP64BITONLY_PATTERNS Reading....Done");
        x
    };

Even when this is enabled to be initialized in the constructor function, if the pattern list in the config file is small, i.e I comment out all but 1 simple pattern as follows, there is no crash.

app64bitonly_patterns:
    - '^NOMATCH/.*$'

If I uncomment a large pattern as follows, it crashes

    - 'binos/linkfarm/host/sdk/sysroots/x86_64\-xesdk\-linux/usr/bin/(x86_64\-xesdk\-linux\-strings|semodule_unpackage|qemu\-ppc|qemu\-mips\.real|staprun|grpc_node_plugin|tset|x86_64\-xesdk\-linux\-as|qemu\-pr\-helper|grpc_objective_c_plugin|mkfs\.ubifs|pseudodb|fdtput|git\-upload\-archive|groupdel|chage|bison\.real|x86_64\-xesdk\-linux\-nm|qemu\-img|grpc_python_plugin|pkg\-config|qemu\-ga|fdtdump|qemu\-system\-mips64|chgpasswd|groupmod|grpc_ruby_plugin|pwconv|ubiblock|groupadd|unfsd|pwunconv|qemu\-system\-mips64el|grpc_php_plugin|chpasswd\.shadow|ubinfo|sedismod|gpasswd|python2\.7\.real|logoutd|qemu\-system\-mips|unsquashfs|ubicrc32|grpck|usermod|ivshmem\-server|qemu\-riscv32|qemu\-system\-riscv32|checkpolicy|checkmodule|perl\.real|openssl|ctest|cpack|x86_64\-xesdk\-linux\-gprof|faillog|sepolgen\-ifgen\-attr\-helper|m4|x86_64\-xesdk\-linux\-dwp|ubiformat|userdel|ubimkvol\.mtd\-utils|newuidmap|useradd|qemu\-system\-sh4|uboot\-mkimage|x86_64\-xesdk\-linux\-gnu\-pkg\-config|vgdb|trace\-cmd|qemu\-nbd|flex\.real|ubirmvol\.mtd\-utils|qemu\-system\-riscv64|pseudo|qemu\-i386|fdtoverlay|x86_64\-xesdk\-linux\-objcopy|mksquashfs|node|x86_64\-xesdk\-linux\-size|tunctl|x86_64\-xesdk\-linux\-elfedit|grpc_cpp_plugin|grpc_csharp_plugin|tput|qemu\-system\-arm|x86_64\-xesdk\-linux\-addr2line|cg_merge|qemu\-aarch64|qemu\-system\-ppc64|qemu\-ppc64|python3\.7\.real|git\.real|newgidmap|qemu\-system\-x86_64|protoc|qemu\-x86_64|qemu\-sh4|file\.real|qemu\-system\-i386|qemu\-system\-ppc|valgrind\.real|sedispol|grpconv|ubirename\.mtd\-utils|python3\.7m|x86_64\-xesdk\-linux\-ranlib|pseudolog|cryptsetup|expiry|dtc|semodule_expand|qemu\-io|stap|git\-upload\-pack|pwck|ubidetach\.mtd\-utils|ubiupdatevol\.mtd\-utils|ubiattach\.mtd\-utils|newusers|bsdcat|xorriso|veritysetup|x86_64\-xesdk\-linux\-objdump|semodule_package|groupmems|uboot\-fit_check_sign|qemu\-system\-mipsel|rpcgen|iconv|getconf|getent|iconvconfig|pldd|gencat|locale|sprof|zic|makedb|zdump|pcprofiledump|passwd\.shadow|x86_64\-xesdk\-linux\-ld|x86_64\-xesdk\-linux\-c\+\+filt|valgrind\-listener|git\-shell|qemu\-mips64|qemu\-mipsel|stapsh|uboot\-dumpimage|ubirsvol\.mtd\-utils|x86_64\-xesdk\-linux\-ld\.gold|chsh\.shadow|semodule_link|ivshmem\-client|stap\-merge|lastlog|x86_64\-xesdk\-linux\-readelf|valgrind\-di\-server|chfn\.shadow|qemu\-system\-aarch64|dmsetup|yat2m|kmod|x86_64\-xesdk\-linux\-strip|grpunconv|protoc\-gen\-c|mpicalc|qemu\-riscv64|update\-mime\-database|x86_64\-xesdk\-linux\-ld\.bfd|x86_64\-xesdk\-linux\-ar|ubinize|qemu\-arm|git\-receive\-pack|fdtget|qemu\-mips64el|patchelf|cmake|qemu\-edid|lz4|opkg)'

It segaults. I suspect I could simply reproduce it by doing a large enough number or size of malloc, dybnamically sized array, operations from within the constructor code. Will try that.

Basically, either trigger brk a second time from within the library constructor/CTOR code or triggering brk too many times, messes with the system and creates crashes later when the main program runs.

I will look. All initialization done in the constructor, completes and wrapped with lazy_static and hence with Once code. I will check again. But they don complete fine, which suggests there is no recursion.

I suspect it may have something to do with the amount malloc happenning inside the constructor forcing heap resizing.

  1. Are you aware of any heap size limits for library constructor code?
  2. Is there way to pepare during compilation for a larger limit for this.

This is what I am driving towards. But still figuring out the right way to initialize within a Once, and where to invoke that innitialization. As the initialization code itself uses some of the intercepted code and causes recursion. I will continue to hack down this path as well.

The recursion I meant would be something indirect, where the first initialization might somehow lead to other code that tries to access that static too, re-initializing it before the first time has completed. It wouldn't have to be infinite recursion to be a problem. But I'm just guessing.

I don't know of any heap limits during constructors, but if you suspect the allocator is broken, you could try an alternate like jemalloc.