GNU bug report logs - #71712
29.3; Crash on OpenBSD

Previous Next

Full log

View this message in rfc822 format

From: Kirill A. Korinsky <kirill <at> korins.ky>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 71712 <at> debbugs.gnu.org
Subject: bug#71712: 29.3; Crash on OpenBSD
Date: Sat, 22 Jun 2024 12:00:49 +0100

On Sat, 22 Jun 2024 11:00:53 +0100,
Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> Yes, but memory_full signals an error, which (a) you should have seen,
> and (b) it prevents the rest of the code from being executed, because
> it throws to top-level.  Thus, for all practical purposes the return
> value of xmalloc does not matter if the memory could not be allocated.
> So I don't believe this is what happened to you, even if we assume
> that you have indeed ran out of memory (which in itself is quite
> improbably on modern systems).

This isn't that large machine which has 16Gb ram, and I use default OpenBSD
limits which is:

  ~ $ ulimit -a
  time(cpu-seconds)    unlimited
  file(blocks)         unlimited
  coredump(blocks)     unlimited
  data(kbytes)         134217728
  stack(kbytes)        4096
  lockedmem(kbytes)    87381
  memory(kbytes)       15959444
  nofiles(descriptors) 512
  processes            256
  ~ $ 

thus, emacs instance which had crashed had run magit, markdown-mode and a
few other heavy things for couple of hours at least.

Additionally, I use 1Gb of RAM for /tmp, at time of crash it had run VM
which uses 5Gb, and over of it Chrome which consumes some memory.

So, I really think that it migth be tin on available memory.

But I haven't got any proof of that.

Anyway, I preserve the core, and if something additional is required, feel
free to ask.

-- 
wbr, Kirill

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.