Bug 246497 - /bin/sh crashes since r360452 in emulators/xsystem35, misc/gpsim, x11-themes/clearlooks
Summary: /bin/sh crashes since r360452 in emulators/xsystem35, misc/gpsim, x11-themes/...
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Jilles Tjoelker
Keywords: regression
Depends on:
Reported: 2020-05-16 11:46 UTC by Jan Beich
Modified: 2020-05-16 16:30 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2020-05-16 11:46:24 UTC
$ make clean all -C ${PORTSDIR-/usr/ports}/emulators/xsystem35
checking for glib-config... /nonexistent/bin/glib-config
checking for GLIB - version >= 1.2.0... ./configure: /nonexistent/bin/glib-config: not found
Unsafe ckmalloc() call
* thread #1, name = 'sh', stop reason = signal SIGABRT
    frame #0: 0x000000080048741a libc.so.7`__sys_thr_kill at thr_kill.S:4
(lldb) bt
* thread #1, name = 'sh', stop reason = signal SIGABRT
  * frame #0: 0x000000080048741a libc.so.7`__sys_thr_kill at thr_kill.S:4
    frame #1: 0x0000000800486dc4 libc.so.7`__raise(s=6) at raise.c:52:10
    frame #2: 0x00000008003fb419 libc.so.7`abort at abort.c:67:8
    frame #3: 0x000000000021a423 sh`badalloc(message=<unavailable>) at memalloc.c:57:2
    frame #4: 0x000000000021a5c8 sh`stalloc [inlined] ckmalloc(nbytes=496) at memalloc.c:70:3
    frame #5: 0x000000000021a5be sh`stalloc [inlined] stnewblock(nbytes=<unavailable>) at memalloc.c:155
    frame #6: 0x000000000021a5be sh`stalloc(nbytes=128) at memalloc.c:172
    frame #7: 0x0000000000211b05 sh`appendarglist(list=0x00007fffffffe0b8, str="") at expand.c:137:13
    frame #8: 0x000000000020ecd1 sh`evalcommand(cmd=0x0000000800a4f250, flags=0, backcmd=0x0000000000000000) at eval.c:864:2
    frame #9: 0x000000000020e31c sh`evaltree(n=0x0000000800a4f250, flags=<unavailable>) at eval.c:289:4
    frame #10: 0x000000000020e371 sh`evaltree(n=0x0000000800a4f368, flags=<unavailable>) at eval.c:212:4
    frame #11: 0x000000000021a1bc sh`cmdloop(top=1) at main.c:220:4
    frame #12: 0x000000000021a030 sh`main(argc=17, argv=0x00007fffffffe338) at main.c:167:3
    frame #13: 0x000000000020bb20 sh`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7

Comment 2 Jilles Tjoelker freebsd_committer 2020-05-16 13:30:27 UTC
Looks like something is doing INTON while interrupts are already permitted. This could be related to a vfork encountering a not found error just before. I will investigate further.
Comment 3 commit-hook freebsd_committer 2020-05-16 16:30:10 UTC
A commit references this bug:

Author: jilles
Date: Sat May 16 16:29:24 UTC 2020
New revision: 361112
URL: https://svnweb.freebsd.org/changeset/base/361112

  sh: Fix double INTON with vfork

  The shell maintains a count of the number of times SIGINT processing has
  been disabled via INTOFF, so SIGINT processing resumes when all disables
  have enabled again (INTON).

  If an error occurs in a vfork() child, the processing of the error enables
  SIGINT processing again, and the INTON in vforkexecshell() causes the count
  to become negative.

  As a result, a later INTOFF may not actually disable SIGINT processing. This
  might cause memory corruption if a SIGINT arrives at an inopportune time. As
  of r360452, it causes the shell to abort when it would unsafely allocate or
  free memory in certain ways.

  Note that various places such as errors in non-special builtins
  unconditionally reset the count to 0, so the problem might still not always
  be visible.

  PR:		246497
  Reported by:	jbeich
  MFC after:	2 weeks