Thursday, May 31, 2018

Re: programs crash on Dell Latitude E7470

On 31 May 10:15 Stuart Henderson wrote:
> On 2018/05/31 10:06, Marco van Hulten wrote:
> > Stuart,
> >
> > [...]
> >
> > I now see there are some limits [...] as normal user
> > [now given from ksh(1)]
$ ulimit -a
time(cpu-seconds) unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 786432
stack(kbytes) 4096
lockedmem(kbytes) 5303878
memory(kbytes) 15888396
nofiles(descriptors) 512
processes 128

I put myself in login class "staff", which increased limits, and then
increased limits a bit further where I could:

$ ulimit -a
time(cpu-seconds) unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 15728640
stack(kbytes) 4096
lockedmem(kbytes) 5503878
memory(kbytes) 15888396
nofiles(descriptors) 1024
processes 512

From this shell I started abiword, and get an immediate crash:

$ rm -rf ~/.config/abiword
$ abiword
Abort trap (core dumped)
$ gdb abiword abiword.core
[...]
Loaded symbols for /usr/local/lib/abiword-3.0/plugins/pdf.so
#0 thrkill () at -:3
3 -: No such file or directory.
in -
(gdb)


whereas calcurse stops in rthread.c, which I thought could be a
calcurse bug so I reported it [1], but I'm not sure at all anymore.

[1]: https://lists.calcurse.org/bugs/msg00261.html

Two days or so ago Firefox and Claws Mail crashed at arbitrary
moments. Just maybe this behaviour will stop now.

> Limits are grouped by login class (5th field in master.passwd). root
> is usually in "daemon" and the initial user created during install is
> in "staff" (default 1.5GB for datasize-cur, no limit for
> datasize-max). Users that you've added separately are likely to be in
> the default class (768MB datasize-cur and datasize-max).
>
> datasize-cur is a "soft limit", a user can increase it themselves with
> "ulimit -d <value>" up to the hard limit in datasize-max.

I learnt something!

> I'd start by putting the relevant user/s into "staff" class (as root,
> vipw, or "chsh <user>" and edit the Class: line), logout/login and
> retry. If it needs more than this, it maybe better to raise the soft
> limit for the individual program by using a shell alias or wrapper
> script rather than raising it across the board (OpenBSD doesn't cope
> very well if the entire system runs out of memory and this is a useful
> brake on runaway processes). For example you could use an alias like
> this:
>
> alias firefox="(ulimit -d $((3*1024*1024)); /usr/local/bin/firefox)"

Thanks, I'll do that when appropriate. At the moment it does not seem
to be a memory limitation issue.

By decreasing ulimit -d $((128*1024)), I can reproduce an immediate
crash of firefox-esr and get the same traceback message as generated by
abiword above. But there I *increased* the limits.

Thanks for the apropos(1) tip!

Marco

No comments:

Post a Comment