Bug 255339 - logger(1): exited on signal 6 (core dumped): assertion in capability code (regression)
Summary: logger(1): exited on signal 6 (core dumped): assertion in capability code (re...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 13.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: needs-qa, regression
Depends on:
Blocks:
 
Reported: 2021-04-23 08:36 UTC by Borja Marcos
Modified: 2021-04-26 07:15 UTC (History)
2 users (show)

See Also:
koobs: maintainer-feedback? (oshogbo)
koobs: mfc-stable13?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Borja Marcos 2021-04-23 08:36:58 UTC
After updating from 12.3 to 13-RELEASE (and recompiling all ports) I have noticed that logger(1) is exiting on signal 6.

Having a look at the core file, an assertion has been triggered.

-----
(gdb) bt
#0  thr_kill () at thr_kill.S:4
#1  0x00000000203053a4 in __raise (s=s@entry=6)
    at /usr/src/lib/libc/gen/raise.c:52
#2  0x00000000203ba369 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3  0x00000000202e82c1 in __assert (func=<optimized out>, 
    file=<optimized out>, line=<optimized out>, failedexpr=<optimized out>)
    at /usr/src/lib/libc/gen/assert.c:51
#4  0x000000002024d582 in service_clean (sock=5, procfd=1, 
    flags=<optimized out>) at /usr/src/lib/libcasper/libcasper/service.c:394
#5  service_start (service=service@entry=0x20a0a000, sock=sock@entry=5, 
    procfd=procfd@entry=1) at /usr/src/lib/libcasper/libcasper/service.c:427
#6  0x000000002024c393 in service_execute (chanfd=5)
    at /usr/src/lib/libcasper/libcasper/libcasper_service.c:162
#7  0x000000002024d92b in zygote_main (sock=4)
    at /usr/src/lib/libcasper/libcasper/zygote.c:162
#8  0x000000002024d798 in zygote_init ()
    at /usr/src/lib/libcasper/libcasper/zygote.c:209
#9  0x000000002024c3bb in casper_main_loop (fd=2)
    at /usr/src/lib/libcasper/libcasper/libcasper_service.c:233
#10 0x000000002024b8bf in cap_init ()
    at /usr/src/lib/libcasper/libcasper/libcasper.c:105
#11 0x0000000000203361 in main (argc=<optimized out>, argv=<optimized out>)
    at /usr/src/usr.bin/logger/logger.c:179
(gdb) 
-----


Looks like an assertion

----
(gdb) up
#2  0x00000000203ba369 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
67		(void)raise(SIGABRT);
(gdb) up
#3  0x00000000202e82c1 in __assert (func=<optimized out>, 
    file=<optimized out>, line=<optimized out>, failedexpr=<optimized out>)
    at /usr/src/lib/libc/gen/assert.c:51
51		abort();
(gdb) up
#4  0x000000002024d582 in service_clean (sock=5, procfd=1, 
    flags=<optimized out>) at /usr/src/lib/libcasper/libcasper/service.c:394
394		assert(procfd > STDERR_FILENO);

----
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-04-23 09:03:01 UTC
Thank you for the report and analysis Borja.

Anything relevent in /etc/make.conf or /etc/src*.conf with respect to build environment?
Comment 2 Borja Marcos 2021-04-23 09:07:03 UTC
Empty src.conf and this is make.conf.

OPTIONS_UNSET=DOXYGEN DOCS DOCBOOK DOC
DEFAULT_VERSIONS+=perl5=5.32

Nothing fancy.
Comment 3 Borja Marcos 2021-04-23 09:10:36 UTC
Sorry I didn't add enough details.

% uname -a
FreeBSD hostname 13.0-RELEASE FreeBSD 13.0-RELEASE #0 ea31abc26: Tue Apr 20 06:12:14 UTC 2021     root@hostname:/usr/obj/usr/src/amd64.amd64/sys/DNS13  amd64


logger is being called by a script.

---
LOGGER="logger -t program -p $syslog_priority"
---

case X$basename in
    X*.extension)
        queue_and_upload file "$channel" "$fname" | ( cd /tmp && $LOGGER )

---

I am quite puzzled. This didn't fail in previous FreeBSD versions.
Comment 4 Mark Johnston freebsd_committer 2021-04-23 13:20:34 UTC
Is your script running with some low limit on the number of open fds in a process?  Are you able to reproduce the problem by running logger(1) manually?
Comment 5 Borja Marcos 2021-04-26 07:15:20 UTC
(In reply to Mark Johnston from comment #4)

No relevant limitation, I checked it and it had a 500 MB memory limit. Removing it doesn't avoid the issue anyway. 

----
Resource limits (current):
  cputime              infinity secs
  filesize             infinity kB
  datasize             33554432 kB
  stacksize              524288 kB
  coredumpsize         infinity kB
  memoryuse            infinity kB
  memorylocked           131072 kB
  maxprocesses             8514
  openfiles              117306
  sbsize               infinity bytes
  vmemoryuse           infinity kB
  pseudo-terminals     infinity
  swapuse              infinity kB
  kqueues              infinity
  umtxp                infinity
-----

The same server was running 12.2 before updating to 13-RELEASE and it didn't happen. Of course after the make world and installworld I nuked all the installed ports, did a make delete-old and make delete-old-libs and I recompiled all the ports.

And no, I can't reproduce it just running it from the command line. 

Checking whether something else is breaking it.