-
Notifications
You must be signed in to change notification settings - Fork 556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use encoding "utf8" causes segfault #7533
Comments
From hatta@yandex.ruHello, this code gives segmentation fault on my Fedora Core 2/linux-2.6.8.1 #!/usr/bin/perl -w my $t = threads->new(\&fn); sub fn { Output from perlbug -d (I cannot send email from my local machine) Flags: Site configuration information for perl v5.8.3: Configured by bhcompile at Thu Apr 15 13:08:28 EDT 2004. Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration: Locally applied patches: @INC for perl v5.8.3: Environment for perl v5.8.3: PATH=/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/lib/java/jre/bin:/usr/lib/java/bin:/usr/local/Wine/bin Goodbye. -- |
From @rgsKonstantin Stopani (via RT) wrote:
Reproduced here with bleadperl; apparently this comes from this bit in /* Not 100% sure stack swap is right thing to do during dup ... */ |
The RT System itself - Status changed from 'new' to 'open' |
From nick@ing-simmons.netRafael Garcia-Suarez <rgarciasuarez@mandrakesoft.com> writes:
Seems like it isn't ;-)
Someone could experiment with commenting out the stack swap, |
From @kimurakoichiHi, I use perl with sjis encoding. This cause by the script above. use v5.8.0; my $thread1 = threads->new(\&main, "One"); $thread1->join; print "done.\n"; sub main { Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Characteristics of this binary (from libperl): thanks, -- |
From rkitover@walmart.comCreated by rkitover@rkitover-linux.walmart.comAs reported by DawnFantasy on IRC (FreeNode #perl): produces a core dump. 5.8.8 (Debian unstable version) produces a core dump as well. Perl Info
|
From @jdhedden
Produces a seg fault with blead under Cygwin on Windows. |
The RT System itself - Status changed from 'new' to 'open' |
From shouldbedomo@mac.comOn 2007–08–23, at 13:52, Jerry D. Hedden wrote:
And on Mac OS 10.4.10 with both 5.8.8 and bleadperl (5.10 to be). Host Name: Tullamore Command: perl Version: ??? (???) PID: 11777 Exception: EXC_BAD_ACCESS (0x0001) Thread 0 Crashed: Thread 0 crashed with PPC Thread State 64: Binary Images Description: -- |
From @smpetersOn Thu, Aug 23, 2007 at 03:45:26AM -0700, Rafael Kitover wrote:
Here's the backtrace with blead.... Program terminated with signal 11, Segmentation fault. |
From @smpetersOn Thu, Aug 23, 2007 at 08:01:56AM -0500, Steve Peters wrote:
Now that I look at the code, this is a known bug. I'll merge this in with Steve Peters |
From blgl@hagernas.comIn article <20070823130816.GA3683@kirk.peters.homeunix.org>,
It's related to #41106 as well. /Bo Lindbergh |
From @nwc10Created by @nwc10$ valgrind ./perl -Ilib -Mthreads -e '{use encoding "latin1"} threads->new(sub {})->join()' Obviously it shouldn't do that. Nicholas Clark Perl Info
|
From @nwc10On Sun Mar 20 04:04:25 2011, nicholas wrote:
The crash happens when trying to swap stacks here: if (e->enc) { [that code is called both during dup, and at normal times] That line was added in 2002 in 24f59af Nicholas Clark |
@nwc10 - Status changed from 'new' to 'open' |
From blgl@stacken.kth.seYet another duplicate of #31923. PerlIO::encoding isn't thread safe. /Bo Lindbergh |
From au@hcsd.deHello, this bug is still present in 5.14.2 - I've just hit it. Are there any Best regards, Stephan |
From [Unknown Contact. See original ticket]Hello, this bug is still present in 5.14.2 - I've just hit it. Are there any Best regards, Stephan |
From au@hcsd.deHi, since I am facing this bug again within just a few weeks I took a closer I'd be very happy if someone with a more in-depth knowledge could take Thank you, best regards, Stephan On Fri Dec 09 05:17:52 2011, stephan_a wrote:
|
From @LeontOn Wed Dec 21 05:52:03 2011, stephan_a wrote:
I seems calling methods during thread duplications is a bad idea, so the Leon |
From pm.20.browseruk@xoxy.netCreated by pm.20.browseruk@xoxy.netAs is, the following code cause a segfault: #! perl -slw binmode STDIN, ':encoding(UTF-8)'; async{ sleep 10; }->detach; my $in = <STDIN>; Use binmode with any :encoding(*) on STDIN and it traps. Hence the conclusion that it is the Unicode IOlayers that are thread Also known to occur on linux systems. Perl Info
|
From @LeontOn Wed Jan 18 16:19:08 2012, pm.20.browseruk@xoxy.net wrote:
This bugreport is a duplicate of #31923 Leon |
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn Wed Jan 18 18:06:29 2012, LeonT wrote:
I am marking this as stalled, as discussed in |
From [Unknown Contact. See original ticket]On Wed Jan 18 18:06:29 2012, LeonT wrote:
I am marking this as stalled, as discussed in |
@khwilliamson - Status changed from 'open' to 'stalled' |
From @jmaslakCreated by @jmaslakThis is a bug report for perl from jmaslak@antelope.net, ----------------------------------------------------------------- Four line script to reproduce: use threads; Result is a coredump at the threads->create line. Perl Info
|
From @jkeenanOn Sat Jun 13 15:22:52 2015, jmaslak@antelope.net wrote:
Segfault confirmed at blead; see attached. But this is not a new bug. I did threaded builds at tags 'v5.20.1' and 'v5.18.4' and got similar results. Attaching output for 5.18.4 threaded build. -- |
From @jkeenan$ ./perl -Ilib -V Characteristics of this binary (from libperl): $ ./perl -Ilib -Mthreads -e 'binmode(STDOUT, ":encoding(UTF-8)");threads->create(\&processthread);sub processthreads {};' |
From @jkeenan[perl] 65 $ ./perl -Ilib -Mthreads -e 'binmode(STDOUT, ":encoding(UTF-8)");threads->create(\&processthread);sub processthreads {};' Characteristics of this binary (from libperl): |
The RT System itself - Status changed from 'new' to 'open' |
From @LeontOn Sun, Jun 14, 2015 at 12:22 AM, Joel Maslak <perlbug-followup@perl.org>
This is a duplicate of #31923. Leon |
From @tonycozOn Tue Dec 27 07:50:43 2011, LeonT wrote:
That's easy enough, but doesn't solve the problem. PerlIOEncode_dup() calls PerlIOBase_dup() which calls PerlIOEncode_pushed(), which then attempts to call Encode::find_encoding() and fails again in the stack change. I don't see an obvious way to tell _pushed() it's being called for a dup and to let the _dup() handler finish the job. I'm not too sure about memory allocation for the PerlIO structures either, but that's unrelated to this particular issue. Tony |
The RT System itself - Status changed from 'stalled' to 'open' |
From @LeontOn Wed, Jun 17, 2015 at 2:30 AM, Tony Cook via RT <perlbug-followup@perl.org
Yeah, I had since reached the same conclusion, otherwise I would have fixed
I suspect that allocating a new layer, and pushing it directly is the only
AFAIK allocating memory is safe. Leon |
From perl@profvince.comI've pushed a tentative fix for this into the Tony, Leon, care to have a look at this? Vincent |
From perl@profvince.com0001-Properly-duplicate-PerlIO-encoding-objects.patchFrom 1f20b10901126aaa2e568735d65ac32b7ba28ca7 Mon Sep 17 00:00:00 2001
From: Vincent Pit <perl@profvince.com>
Date: Fri, 28 Aug 2015 14:17:00 -0300
Subject: [PATCH] Properly duplicate PerlIO::encoding objects
PerlIO::encoding objects are usually initialized by calling Perl methods,
essentially from the pushed() and getarg() callbacks. During cloning, the
PerlIO API will by default call these methods to initialize the duplicate
struct when the PerlIOBase parent struct is itself duplicated. This does
not behave so well because the perl interpreter is not ready to call
methods at this point, for the stacks are not set up yet.
The proper way to duplicate the PerlIO::encoding object is to call sv_dup()
on its members from the dup() PerlIO callback. So the only catch is to make
the getarg() and pushed() calls implied by the duplication of the underlying
PerlIOBase object aware that they are called during cloning, and make them
wait that the control flow returns to the dup() callback. Fortunately,
getarg() knows since its param argument is then non-null, and its return
value is passed immediately to pushed(), so it is enough to tag this
returned value with a custom magic so that pushed() can see it is being
called during cloning.
This fixes [RT #31923].
---
ext/PerlIO-encoding/encoding.pm | 2 +-
ext/PerlIO-encoding/encoding.xs | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/ext/PerlIO-encoding/encoding.pm b/ext/PerlIO-encoding/encoding.pm
index 4cff76d..97f05ec 100644
--- a/ext/PerlIO-encoding/encoding.pm
+++ b/ext/PerlIO-encoding/encoding.pm
@@ -1,7 +1,7 @@
package PerlIO::encoding;
use strict;
-our $VERSION = '0.21';
+our $VERSION = '0.22';
our $DEBUG = 0;
$DEBUG and warn __PACKAGE__, " called by ", join(", ", caller), "\n";
diff --git a/ext/PerlIO-encoding/encoding.xs b/ext/PerlIO-encoding/encoding.xs
index 03b8850..c992dd2 100644
--- a/ext/PerlIO-encoding/encoding.xs
+++ b/ext/PerlIO-encoding/encoding.xs
@@ -49,13 +49,23 @@ typedef struct {
#define NEEDS_LINES 1
+static MGVTBL PerlIOEncode_tag = { 0, 0, 0, 0, 0, 0, 0, 0 };
+
SV *
PerlIOEncode_getarg(pTHX_ PerlIO * f, CLONE_PARAMS * param, int flags)
{
PerlIOEncode *e = PerlIOSelf(f, PerlIOEncode);
- SV *sv = &PL_sv_undef;
- PERL_UNUSED_ARG(param);
+ SV *sv;
PERL_UNUSED_ARG(flags);
+ /* During cloning, return an undef token object so that _pushed() knows
+ * that it should not call methods and wait for _dup() to actually dup the
+ * encoding object. */
+ if (param) {
+ sv = newSV(0);
+ sv_magicext(sv, NULL, PERL_MAGIC_ext, &PerlIOEncode_tag, 0, 0);
+ return sv;
+ }
+ sv = &PL_sv_undef;
if (e->enc) {
dSP;
/* Not 100% sure stack swap is right thing to do during dup ... */
@@ -85,6 +95,14 @@ PerlIOEncode_pushed(pTHX_ PerlIO * f, const char *mode, SV * arg, PerlIO_funcs *
IV code = PerlIOBuf_pushed(aTHX_ f, mode, Nullsv,tab);
SV *result = Nullsv;
+ if (SvTYPE(arg) >= SVt_PVMG
+ && mg_findext(arg, PERL_MAGIC_ext, &PerlIOEncode_tag)) {
+ e->enc = NULL;
+ e->chk = NULL;
+ e->inEncodeCall = 0;
+ return code;
+ }
+
PUSHSTACKi(PERLSI_MAGIC);
ENTER;
SAVETMPS;
@@ -566,6 +584,9 @@ PerlIOEncode_dup(pTHX_ PerlIO * f, PerlIO * o,
if (oe->enc) {
fe->enc = PerlIO_sv_dup(aTHX_ oe->enc, params);
}
+ if (oe->chk) {
+ fe->chk = PerlIO_sv_dup(aTHX_ oe->chk, params);
+ }
}
return f;
}
--
1.9.5 (Apple Git-50.3)
|
From @tonycozOn Fri Aug 28 11:54:03 2015, perl@profvince.com wrote:
Makes sense to me. Tony |
From bitcard@profvince.comNow in blead as commit 0ee3fa2. Closing. |
bitcard@profvince.com - Status changed from 'open' to 'resolved' |
Also: RT86550$ (There is a reference in the code to |
This test is skipped when running as threads (i.e. via t/re/pat_advanced_thr.t) since 20 Mar 2011 (commit 2feceb7) because of a bug. That bug `[perl #86550]` is GH Perl#7533 and that was fixed in Oct 2015 with commit 0ee3fa2. So I think it's safe to remove the `todo_skip` since the bug for why it was skipped looks resolved. (A smoke-me branch also revealed no unexpected problems)
This test is skipped when running as threads (i.e. via t/re/pat_advanced_thr.t) since 20 Mar 2011 (commit 2feceb7) because of a bug. That bug `[perl #86550]` is GH #7533 and that was fixed in Oct 2015 with commit 0ee3fa2. So I think it's safe to remove the `todo_skip` since the bug for why it was skipped looks resolved. (A smoke-me branch also revealed no unexpected problems)
This test is skipped when running as threads (i.e. via t/re/pat_advanced_thr.t) since 20 Mar 2011 (commit 2feceb7) because of a bug. That bug `[perl #86550]` is GH Perl#7533 and that was fixed in Oct 2015 with commit 0ee3fa2. So I think it's safe to remove the `todo_skip` since the bug for why it was skipped looks resolved. (A smoke-me branch also revealed no unexpected problems)
Migrated from rt.perl.org#31923 (status was 'resolved')
Searchable as RT31923$
The text was updated successfully, but these errors were encountered: