Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign up"panic: free from wrong pool" while freeing the env after fork on darwin #14955
Comments
This comment has been minimized.
This comment has been minimized.
From perl@profvince.comCreated by perl@profvince.comfork() causes a panic at destruction time with a debugging threaded $ ./perl -e '$pid = fork and waitpid $pid, 0' which also causes t/op/magic.t to fail. valgrind says : $ valgrind ./perl -e '$pid = fork and waitpid $pid, 0' Perl Info |
This comment has been minimized.
This comment has been minimized.
From @bulk88On Thu Oct 01 10:20:48 2015, perl@profvince.com wrote:
What is exactly is perl.c:836 ? What C code is at line 836 on your perl? -- |
This comment has been minimized.
This comment has been minimized.
|
The RT System itself - Status changed from 'new' to 'open' |
This comment has been minimized.
This comment has been minimized.
From perl@profvince.com
gitweb is kind enough to answer your question : http://perl5.git.perl.org/perl.git/blob/4b89cb47a04366ffd503d523f2fcf2375cec0a8e:/perl.c#l836 |
This comment has been minimized.
This comment has been minimized.
From @tonycozOn Thu Oct 01 10:20:48 2015, perl@profvince.com wrote:
I'm not seeing this in blead: neptune:perl tony$ uname -a This is perl 5, version 23, subversion 4 (v5.23.4 (v5.23.3-83-gf7294c1)) built for darwin-thread-multi-2level ... Tony |
This comment has been minimized.
This comment has been minimized.
From perl@profvince.comLe 09/11/2015 21:23, Tony Cook via RT a écrit :
Well I still do : $ ./perl -Ilib -e'$pid = fork and waitpid $pid, 0' $ uname -a $ ./perl -Ilib -V Characteristics of this binary (from libperl): |
This comment has been minimized.
This comment has been minimized.
From @tonycozOn Mon Nov 09 15:42:47 2015, perl@profvince.com wrote:
I've now reproduced this. It doesn't happen within a ssh shell, but it does in Terminal.app. Tony |
This comment has been minimized.
This comment has been minimized.
From @tonycozOn Mon Dec 07 20:46:09 2015, tonyc wrote:
What I suspect is happening is the xpc_atfork_child function is calling setenv() and libc is rearranging the environment, invalidating our environ pointers (allocated with malloc() instead of safesysmalloc()). Building with -DPERL_USE_SAFE_PUTENV prevents the errors. Tony |
This comment has been minimized.
This comment has been minimized.
From perl@profvince.comLe 08/12/2015 03:54, Tony Cook via RT a écrit :
This makes sense and matches what I've been seeing intermittently from Vincent |
This comment has been minimized.
This comment has been minimized.
From @tonycozOn Tue Dec 08 03:34:17 2015, perl@profvince.com wrote:
I suspect that we should be using -DPERL_USE_SAFE_PUTENV on any system we can, since it prevents conflicts with external libraries that use setenv()/unsetenv(), which was the problem here. From looking at the hints, riscos, sufficiently modern solaris and cygwin enable it. Please try the attached patch. Tony |
This comment has been minimized.
This comment has been minimized.
From @tonycoz0001-perl-126240-use-DPERL_USE_SAFE_PUTENV-where-possible.patchFrom 1bde2c639b40d1021477ad7b48c14805b32c7b60 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Wed, 9 Dec 2015 10:20:46 +1100
Subject: [perl #126240] use -DPERL_USE_SAFE_PUTENV where possible on OS X
On threaded builds on OS X, libSystem registers atfork handlers that
call setenv(), which internally modifies members of environ[], setting
them to malloc()ed blocks.
In some cases Perl_my_setenv() reallocates environ[] using
safesysmalloc(), which under debugging builds adds a tracking header,
and if perl_destruct() sees that environ[] has been reallocated, frees
it with safesysfree().
When these combine, perl attempts to free the malloc()ed block with
safesysfree(), which attempts to access the tracking header, causing
an invalid access in tools like valgrind, or a "free from wrong pool"
error, since the header contains unrelated data.
Avoid this mess by letting libc manage environ[] if unsetenv() is
available.
---
hints/darwin.sh | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/hints/darwin.sh b/hints/darwin.sh
index ee20760..2af6ae7 100644
--- a/hints/darwin.sh
+++ b/hints/darwin.sh
@@ -490,3 +490,13 @@ esac
# makefile in the same place. Since Darwin uses GNU make, this dodges
# the problem.
firstmakefile=GNUmakefile;
+
+# Parts of the system call setenv(), in particular in an atfork handler.
+# This causes problems when the child tries to clean up environ[], so
+# let libc manage environ[].
+cat >> config.over <<'EOOVER'
+if test "$d_unsetenv" = "$define" -a \
+ `expr "$ccflags" : '.*-DPERL_USE_SAFE_PUTENV'` -eq 0; then
+ ccflags="$ccflags -DPERL_USE_SAFE_PUTENV"
+fi
+EOOVER
--
2.4.9 (Apple Git-60)
|
This comment has been minimized.
This comment has been minimized.
From @jkeenanOn Tue Dec 08 15:38:01 2015, tonyc wrote:
Smoking in branch: smoke-me/jkeenan/126240-darwin-use-safe-putenv -- |
This comment has been minimized.
This comment has been minimized.
From @rjbsThis patch cleared up my tests failures. -- |
This comment has been minimized.
This comment has been minimized.
From @jkeenanOn Tue Dec 08 16:22:42 2015, jkeenan wrote:
Built successfully on older Darwin; see attachment. -- |
This comment has been minimized.
This comment has been minimized.
From @jkeenanSummary of my perl5 (revision 5 version 23 subversion 6) configuration: Characteristics of this binary (from libperl): |
This comment has been minimized.
This comment has been minimized.
From @iabynOn Tue, Dec 08, 2015 at 03:38:02PM -0800, Tony Cook via RT wrote:
By "can", do you mean any system that physically works with -- |
This comment has been minimized.
This comment has been minimized.
From @tonycozOn Wed Dec 09 07:08:21 2015, davem wrote:
I guess that's the hard bit to define. I'm guessing any system that has unsetenv() will be safe, since setenv(), getenv() and unsetenv() *should* be working together to manage memory correctly. putenv()'s memory handling isn't well defined in POSIX, ie. there's no POSIX also mentions[2] that using putenv() can (theoretically) slow down getenv() if an implementation uses an internal structure to speed up environment variable lookups. Tony [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/putenv.html [2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
From @tonycozOn Wed Dec 16 22:06:58 2015, tonyc wrote:
This required an extra fix in 12ffbb1. Tony |
This comment has been minimized.
This comment has been minimized.
From mojca.miklavec.lists@gmail.comI'm having problems building Perl 5.24.0-RC5 (I didn't try older ones), see https://rt.perl.org/Ticket/Display.html?id=128093 and https://trac.macports.org/ticket/51330 I'm not saying that commits related to this ticket lead to a build problem, but this is the only ticket related to "environ" that I found in the changelog. |
This comment has been minimized.
This comment has been minimized.
From @tonycozOn Sat, 07 May 2016 04:55:20 -0700, mojca.miklavec.lists@gmail.com wrote:
This was unrelated, closing. Tony |
This comment has been minimized.
This comment has been minimized.
|
@tonycoz - Status changed from 'open' to 'pending release' |
This comment has been minimized.
This comment has been minimized.
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.26.0, this and 210 other issues have been Perl 5.26.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
This comment has been minimized.
This comment has been minimized.
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#126240 (status was 'resolved')
Searchable as RT126240$