[vim/vim] Crashes on larger files when scrolling on OpenBSD with sysctl vm.malloc_conf=S (Issue #14070)
Dante
Steps to reproduce
doas sysctl vm.malloc_conf=S or set vm.malloc_conf=S in /etc/sysctl.conf and reboot.
vim
open a large file 1000+ lines ideally
scroll up and down to see if it crashes.
Expected behaviour
Program crashes likely due to a memory issue and gives segmentation fault
Version of Vim
9.0.2035
Environment
OS: OpenBSD 7.4 (not current)
Terminal: alacritty 0.12.2
$TERM: xterm-256color
shell: zsh 5.9 and default ksh on OpenBSD which is KSH v5.2.14 99/07/13.2
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
since you seem to be able to easily reproduce, can you please share a stack trace?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dante
since you seem to be able to easily reproduce, can you please share a stack trace?
Not sure how to do that sorry
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
byteskeptical
@dante-robinson you can run ktrace vim yourlargefile.txt and provide the dump file after triggering the behavior. I'm running on current (7.5 #10) also with the aforementioned sysctl flag and can't seem to reproduce this on any flavor of vim (gtk or nox11*) on a ~2400 line file. Can you reproduce the behavior in xterm? Lastly what class is the user your running this as a part of (userinfo $USER)?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Dante
@dante-robinson you can run
ktrace vim yourlargefile.txtand provide the dump file after triggering the behavior. I'm running on current (7.5 build 10) also with the aforementioned sysctl flag and can't seem to reproduce this on any flavor of vim (gtk or nox11*) on a ~2400 line file. Can you reproduce the behavior in xterm? Lastly what class is the user your running this as a part of (userinfo $USER)?
xterm causes the same issue.
groups user wheel operator wsrc staff _shutdown
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
byteskeptical
@dante-robinson are you all syspatch 'ed up on this system? Given the memory access error and the trapno=6 I would suspect the recent syscall changes may be playing a role here. You wouldn't happen to be running a current flavor package on a stable system by any chance?
67101 vim CALL mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
67101 vim RET mmap 7136648458240/0x67da1657000
67101 vim CALL mprotect(0x67da165a000,0x1000,0<PROT_NONE>)
67101 vim RET mprotect 0
67101 vim CALL munmap(0x67ccdc92000,0x4000)
67101 vim RET munmap 0
67101 vim CALL munmap(0x67da1657000,0x4000)
67101 vim RET munmap 0
67101 vim PSIG SIGSEGV caught handler=0x67ac95e52d0 mask=0<> code=SEGV_ACCERR addr=0x67d702a1003 trapno=6
67101 vim CALL sigprocmask(SIG_BLOCK,0<>)
67101 vim RET sigprocmask 0x400<SIGSEGV>
67101 vim CALL sigaction(SIGHUP,0x67dc66d5b60,0x67dc66d5b70)
67101 vim STRU struct sigaction { handler=SIG_IGN, mask=0<>, flags=0x2<SA_RESTART> }
67101 vim STRU struct sigaction { handler=0x67ac95e52d0, mask=0<>, flags=0x1<SA_ONSTACK> }
67101 vim RET sigaction 0
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Please see here: https://github.com/vim/vim/wiki/Debugging-Vim-Bugs for a stack trace
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dante
@dante-robinson are you all
syspatch'ed up on this system? Given the memory access error and the trapno=6 I would suspect the recent syscall changes may be playing a role here. You wouldn't happen to be running a current flavor package on a stable system by any chance?67101 vim CALL mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) 67101 vim RET mmap 7136648458240/0x67da1657000 67101 vim CALL mprotect(0x67da165a000,0x1000,0<PROT_NONE>) 67101 vim RET mprotect 0 67101 vim CALL munmap(0x67ccdc92000,0x4000) 67101 vim RET munmap 0 67101 vim CALL munmap(0x67da1657000,0x4000) 67101 vim RET munmap 0 67101 vim PSIG SIGSEGV caught handler=0x67ac95e52d0 mask=0<> code=SEGV_ACCERR addr=0x67d702a1003 trapno=6 67101 vim CALL sigprocmask(SIG_BLOCK,0<>) 67101 vim RET sigprocmask 0x400<SIGSEGV> 67101 vim CALL sigaction(SIGHUP,0x67dc66d5b60,0x67dc66d5b70) 67101 vim STRU struct sigaction { handler=SIG_IGN, mask=0<>, flags=0x2<SA_RESTART> } 67101 vim STRU struct sigaction { handler=0x67ac95e52d0, mask=0<>, flags=0x1<SA_ONSTACK> } 67101 vim RET sigaction 0
Have all the current syspatches and am using the stable package from pkg_add not the -current package.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dante
Issue seems to be fixed in OpenBSD 7.5
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dante
Closed #14070 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.