"panic: free from wrong pool" while freeing the env after fork on darwin #14955
Comments
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 |
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? -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From perl@profvince.com
gitweb is kind enough to answer your question : http://perl5.git.perl.org/perl.git/blob/4b89cb47a04366ffd503d523f2fcf2375cec0a8e:/perl.c#l836 |
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 |
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): |
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 |
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 |
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 |
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 |
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)
|
From @jkeenanOn Tue Dec 08 15:38:01 2015, tonyc wrote:
Smoking in branch: smoke-me/jkeenan/126240-darwin-use-safe-putenv -- |
From @rjbsThis patch cleared up my tests failures. -- |
From @jkeenanOn Tue Dec 08 16:22:42 2015, jkeenan wrote:
Built successfully on older Darwin; see attachment. -- |
From @jkeenanSummary of my perl5 (revision 5 version 23 subversion 6) configuration: Characteristics of this binary (from libperl): |
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 -- |
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 |
From @tonycozOn Wed Dec 16 22:06:58 2015, tonyc wrote:
This required an extra fix in 12ffbb1. Tony |
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. |
From @tonycozOn Sat, 07 May 2016 04:55:20 -0700, mojca.miklavec.lists@gmail.com wrote:
This was unrelated, closing. Tony |
|
@tonycoz - Status changed from 'open' to 'pending release' |
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. |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#126240 (status was 'resolved')
Searchable as RT126240$
The text was updated successfully, but these errors were encountered: