On 2021-05-07, yancy ribbens <yancy.ribb...@gmail.com> wrote: > I'm running 6.8 and trying to run bitcoind (C++), however, I continue to > receive a core dump while running the application (out of memory). The > dmesg file is below.
Always surprises me when people are willing to run things like that as root.. > The application is running as root and I've set datasize-max and > datasize-cur to infinity in the login.conf daemon section as I suspect the > core dump is happening because of an upper memory bound enforced by the OS. Did you logout and back in between updating login.conf and retrying? (Needs to be a full logout; if you use an ssh persistent connection that will need to be closed; if you use X that needs to be restarted). Check what ulimit -a says. > running the application \time -l twice shows the resident set size each > time to be: > 662128 > 650388 > > I've also observed "top" while running and there is more than 1GB free and > SWAP is not being used at the time it core dumps (out of memory). If it requests an allocation which fails, that memory won't be "used" to show up in top / time -l. > Is this a problem with a login.conf parameter or something else? > > OpenBSD 6.8 (GENERIC.MP) #440: Sun Oct 4 18:33:20 MDT 2020 > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP ... > cpu0: > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN LONG in the cpu capabilities line means that the hardware can usually run amd64. That would give you a few hundred MB more physical memory, and much more available memory address space (and a lot of software is only really tested on 64-bit archs these days anyway..) So you might possibly like to try that.
