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
bless() invoked in AUTOLOAD causes SEGV #11493
Comments
From @stscCreated by @stsc[guest@testing ~]$ ./perl-7b70e81 -e 'AUTOLOAD { bless {} }; __PACKAGE__->method' Reproducible with 5.004_05, 5.005_04, 5.6.2, 5.8.9, 5.10.0, 5.10.1, Attached the output of valgrind and gdb. Perl Info
|
From @stsc==4158== Memcheck, a memory error detector |
From @stscGNU gdb (GDB) 7.0.1-debian Program received signal SIGSEGV, Segmentation fault. ... #58226 0x08113a9c in S_curse (my_perl=0x81c9008, sv=0x81e68b0, check_refcnt=1 '\001') at sv.c:6269 Inferior 1 [process 4146] will be killed. Quit anyway? (y or n) |
From @rgarciaOn 11 July 2011 11:41, stsc@refcnt.org <perlbug-followup@perl.org> wrote:
That segfaults during global destruction. Adding an empty A simpler way to trigger that bug, without autoloading : ~§ perl -e 'sub DESTROY { bless {} }; bless {}' |
The RT System itself - Status changed from 'new' to 'open' |
From sog@msg.mxOn 07/11/2011 09:32 AM, Rafael Garcia-Suarez wrote:
Some guards against reentrance are required for "magic" functions. Not the same path, but on the same theme, a little more explicit: $ perl -e 'sub TIEHASH { tie %tmp, "main" } tie %foo, "main"' |
From @cpansproutOn Tue Jul 12 21:19:22 2011, sortiz wrote:
But sometimes it is necessary for DESTROY, etc. to be recursive. It’s For me, the crash happens 102273 C function calls deep, which will Or do we want objects destroyed with DESTROY actually to remain alive I’m inclined to classify this bug as unfixable. |
Migrated from rt.perl.org#94510 (status was 'open')
Searchable as RT94510$
The text was updated successfully, but these errors were encountered: