zsh-workers
 help / color / mirror / code / Atom feed
* Memory error on exporting XPC_SERVICE_NAME from a subshell
@ 2022-07-18 18:45 Varun Gandhi
  2022-07-20  0:11 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Varun Gandhi @ 2022-07-18 18:45 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Hey folks,

While bisecting my shell configuration for an unrelated issue, I ran into what looks like a use-after-free on exporting XPC_SERVICE_NAME from a subshell. Minimized example shown below:

❯ env -i -S'XPC_SERVICE_NAME=0' zsh --no-rcs
Varuns-MacBook-Pro% export
HOME=/Users/varun
LOGNAME=varun
OLDPWD=/Users/varun
PWD=/Users/varun
SHLVL=1
XPC_SERVICE_NAME=0
Varuns-MacBook-Pro% (export XPC_SERVICE_NAME=0)
zsh(29836,0x104d1c580) malloc: *** error for object 0x14c9043d0: pointer being freed was not allocated
zsh(29836,0x104d1c580) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort      ( export XPC_SERVICE_NAME=0 ; )

Configuration information:
- zsh 5.8.1 (x86_64-apple-darwin21.0) (from /bin/zsh). This bug doesn't seem arch-specific, but I'll note that the x86_64 in the version is misleading, the binary is a universal one (arm64e + x86_64).
- macOS 12.4 (21F79) running on an M1 Mac.

Let me know if you're having trouble reproducing the issue.

Cheers,
Varun

[-- Attachment #2: Type: text/html, Size: 1509 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Memory error on exporting XPC_SERVICE_NAME from a subshell
  2022-07-18 18:45 Memory error on exporting XPC_SERVICE_NAME from a subshell Varun Gandhi
@ 2022-07-20  0:11 ` Bart Schaefer
  2022-07-21  9:40   ` Jun T
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2022-07-20  0:11 UTC (permalink / raw)
  To: Varun Gandhi; +Cc: Zsh hackers list

On Mon, Jul 18, 2022 at 11:46 AM Varun Gandhi <varun@cutcul.us> wrote:
>
> While bisecting my shell configuration for an unrelated issue, I ran into what looks like a use-after-free on exporting XPC_SERVICE_NAME from a subshell.

This is an error in a MacOS library routine.  Previously seen in zsh
with constructs like
% XPC_SERVICE_NAME=0 somecommand

However, if you're able to reproduce it with "env -i
-S'XPC_SERVICE_NAME=0'" then it's not limited to the zsh internals and
should probably be reported to Apple as well.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Memory error on exporting XPC_SERVICE_NAME from a subshell
  2022-07-20  0:11 ` Bart Schaefer
@ 2022-07-21  9:40   ` Jun T
  2022-07-21 21:11     ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Jun T @ 2022-07-21  9:40 UTC (permalink / raw)
  To: zsh-workers


> 2022/07/20 9:11, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
> On Mon, Jul 18, 2022 at 11:46 AM Varun Gandhi <varun@cutcul.us> wrote:
>> 
>> While bisecting my shell configuration for an unrelated issue, I ran into what looks like a use-after-free on exporting XPC_SERVICE_NAME from a subshell.
> 
> This is an error in a MacOS library routine.  Previously seen in zsh
> with constructs like
> % XPC_SERVICE_NAME=0 somecommand

The error occurs at line 5263 in params.c.

I din't know why the problem occurs only with XPC_SERVER_NAME, but
I think we can fix it (at least for relatively new macOS).

On macOS, USE_SET_UNSET_ENV is not defined because setenv(3) had a
strange feature that it removed a leading '=' from the value
(Bart's patch in workers/38432); line 786 in zsh_system.h.

But on my Macs setenv() behaves normally. I've looked into the
source (setenv.c) and manpage (getenv.3) of older macOS (now on
GitHub), and found that Apple has fixed this in macOS Sierra (10.12).
El Capitan (10.11) is the last version with this problem, but Apple
has stopped supporting El Capitan on Oct. 2018. There are very few
Macs still running El Captain or older OS X now (about 2% of Macs?).

So the simplest solution is to ignore El Capitan and older, and
remove !defined(__APPLE__) from the line 786 in zsh_system.h.

Or we can check the macOS version in configure.ac, as in the
patch below (I don't know the way to get the macOS version
from C preprocessor macro).

Or we can use the Peter's patch in workers/38433⁩ (with some fixes?).



diff --git a/Src/zsh_system.h b/Src/zsh_system.h
index 6f4efce96..16f724401 100644
--- a/Src/zsh_system.h
+++ b/Src/zsh_system.h
@@ -783,7 +783,8 @@ extern char **environ;
  * We always need setenv and unsetenv in pairs, because
  * we don't know how to do memory management on the values set.
  */
-#if defined(HAVE_SETENV) && defined(HAVE_UNSETENV) && !defined(__APPLE__)
+#if defined(HAVE_SETENV) && defined(HAVE_UNSETENV) \
+    && !defined(SETENV_MANGLES_EQUAL)
 # define USE_SET_UNSET_ENV
 #endif
 
diff --git a/configure.ac b/configure.ac
index 77e381f50..890ef8dd2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1515,6 +1515,14 @@ else
 zsh_cv_use_xattr=no
 fi])
 
+dnl We don't want to use setenv(3) on El Capitan or older OS X because it
+dnl removes a leading '=' from the value of the environment variable
+AH_TEMPLATE([SETENV_MANGLES_EQUAL],
+[Define to 1 if setenv removes a leading =])
+case $host_os in
+  darwin1[0-5]*) AC_DEFINE(SETENV_MANGLES_EQUAL) ;;
+esac
+
 dnl -------------
 dnl CHECK SIGNALS
 dnl -------------





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Memory error on exporting XPC_SERVICE_NAME from a subshell
  2022-07-21  9:40   ` Jun T
@ 2022-07-21 21:11     ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2022-07-21 21:11 UTC (permalink / raw)
  To: Jun T; +Cc: Zsh hackers list

On Thu, Jul 21, 2022 at 2:46 AM Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> So the simplest solution is to ignore El Capitan and older, and
> remove !defined(__APPLE__) from the line 786 in zsh_system.h.
>
> Or we can check the macOS version in configure.ac, as in the
> patch below (I don't know the way to get the macOS version
> from C preprocessor macro).
>
> Or we can use the Peter's patch in workers/38433⁩ (with some fixes?).

I still compile on some older (not upgradable) Mac laptops, but could
live with having to manually disable USE_SET_UNSET_ENV

Your suggested configure change is simpler than PWS's and would
probably be fine.  I don't think we ever got a working version of
38433, but if you want to chase that down, that would be the "most
complete" fix.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-07-21 21:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-18 18:45 Memory error on exporting XPC_SERVICE_NAME from a subshell Varun Gandhi
2022-07-20  0:11 ` Bart Schaefer
2022-07-21  9:40   ` Jun T
2022-07-21 21:11     ` Bart Schaefer

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).