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
threads-shared object2.t crash #15215
Comments
From @cpansprout$ ./perl harness ../dist/threads-shared/t/object2.t But the problem disappears if I add the -v option to harness. Is anybody else seeing this problem? $ ./perl -Ilib -v This is perl 5, version 23, subversion 9 (v5.23.9 (v5.23.8-83-g6e64da7*)) built for darwin-thread-multi-2level Copyright 1987-2016, Larry Wall Perl may be copied only under the terms of either the Artistic License or the Complete documentation for Perl, including FAQ lists, should be found on Pint:perl.git sprout$ ./perl -Ilib -V Characteristics of this binary (from libperl): -- Father Chrysostomos |
From @cpansproutOn Sat Mar 05 16:22:20 2016, sprout wrote:
BTW, that command has to be run in the t/ folder. -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Sat Mar 05 16:22:20 2016, sprout wrote:
It also disappears if I run it with PERL_DESTRUCT_LEVEL=2, which surprised me. -- Father Chrysostomos |
From @khwilliamsonOn 03/05/2016 05:34 PM, Father Chrysostomos via RT wrote:
Those kind of weird things should be checked with valgrind to rule out |
From @jkeenanOn Sat Mar 05 16:22:20 2016, sprout wrote:
[snip]
Do you get the same failure if you either: (a) configure without the the '-Accflags' switches? and/or: (b) use a different C compiler? Thank you very much. -- |
From @cpansproutOn Sun Mar 06 05:41:32 2016, jkeenan wrote:
If I drop -Accflags=-DPERL_OP_PARENT, the problem remains. (Same with -Accflags=-DPERL_NO_CO, which does nothing. It’s just my way of turning PERL_NO_COW on and off: I delete the last letter.) I don’t get the problem with clang. I need these three flags to get it: -Accflags=-DPERL_DEBUG_READONLY_OPS -Accflags=-DPERL_BOOL_AS_CHAR -Dcc=g++ -- Father Chrysostomos |
From @cpansproutOn Sun Mar 06 06:32:42 2016, sprout wrote:
I have tried bisecting in the one computer where this appears 100% reproducible. (Unfortunately, it does not have valgrind, and I am not in a position to change that.) Here is the result I get: commit 6e64da7 regcomp.c: Revise, add comments, white-space changes which just gives me a sinking feeling that this is going to be hard to track down. I need to make the bisect smarter by having it run the test 100 times.... -- Father Chrysostomos |
From @khwilliamsonOn Sun Mar 06 14:53:27 2016, sprout wrote:
Since my name got mentioned, I did verify that that commit was as advertised, only comments and white-space. I rang this on blead on my 64-bit Linux box: ./Configure -DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO -Dcc=g++ -de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR I ran your script by hand, maybe 30-40 times in a row without failure. I ran it under valgrind, and also got no failure, though I don't know if there's something special to do with valgrind on subthreads. -- |
From @khwilliamsonOn 03/06/2016 10:09 PM, Karl Williamson via RT wrote:
That commit is adjacent to one that does change freeing things. You In examining the code, I see another potential memory leak, and will fix |
From @cpansproutOn Mon Mar 07 10:31:48 2016, public@khwilliamson.com wrote:
Thank you for the suggestion. Alas, it makes no difference. I honestly think I misread the bisect output, because now I can no longer get it to fail under an automated bisect. I have now bisected it manually to: commit 67ba812 narrow the filename check in strict.pm/warnings.pm which means we have a latent bug that has just been uncovered. I will keep digging.... -- Father Chrysostomos |
From @cpansproutOn Mon Mar 07 12:55:35 2016, sprout wrote:
After a while, I stopped being able to reproduce it myself, even with commits where I could consistently reproduce it before. So I am at a loss. With no way to track down this bug now, and nobody who can reproduce it, I am just going to mark it as rejected. -- Father Chrysostomos |
@cpansprout - Status changed from 'open' to 'rejected' |
From @khwilliamsonOn 03/08/2016 09:47 AM, Father Chrysostomos via RT wrote:
Problems that go away on their own tend to come back on their own. If you're saying that you've reset the perl HEAD to where it used to |
Migrated from rt.perl.org#127661 (status was 'rejected')
Searchable as RT127661$
The text was updated successfully, but these errors were encountered: