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: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Jilles Tjoelker
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-05-16 11:46 UTC by Jan Beich
Modified: 2020-05-30 14:45 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer freebsd_triage 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

http://beefy17.nyi.freebsd.org/data/head-i386-default/p535343_s361095/logs/errors/xsystem35-1.7.3.p5_4.log
http://beefy18.nyi.freebsd.org/data/head-amd64-default/p535193_s361019/logs/errors/xsystem35-1.7.3.p5_4.log
Comment 2 Jilles Tjoelker freebsd_committer freebsd_triage 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 freebsd_triage 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

Log:
  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

Changes:
  head/bin/sh/jobs.c
  head/bin/sh/tests/execution/Makefile
  head/bin/sh/tests/execution/unknown2.0
Comment 4 commit-hook freebsd_committer freebsd_triage 2020-05-30 13:40:55 UTC
A commit references this bug:

Author: jilles
Date: Sat May 30 13:39:57 UTC 2020
New revision: 361646
URL: https://svnweb.freebsd.org/changeset/base/361646

Log:
  MFC r361112,r361117: 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.

  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

Changes:
_U  stable/12/
  stable/12/bin/sh/jobs.c
  stable/12/bin/sh/tests/execution/Makefile
  stable/12/bin/sh/tests/execution/unknown2.0