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
recursion in overload sub results in segfault #16333
Comments
From data@cpan.orgCreated by data@cpan.orgHi, i've run accross a segmentation fault with the following script: package Clock; use overload sub equals_to{ $_[0] eq $_[1] } package main; The SIGSEGV goes away when I change equals_to to: sub equals_to{ $_[0]->to_string eq $_[1] } bye, Danijel Perl Info
|
From @jkeenanOn Thu, 21 Dec 2017 09:52:59 GMT, DaTa wrote:
Confirmed. Note that the problem is older than the perl-5.010 needed to make use of the '//' operator in sub to_string(). If we switch those to '||', we can reproduce the segfault going back at least to perl 5.6. See attached. Thank you very much. -- |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgDanijel Tasov wrote:
Here's your problem you've defined the "eq" overload to apply "eq" to sub equals_to{ "$_[0]" eq $_[1] } or just remove that overload and enable overload fallback, so that Perl There is no Perl bug here. -zefram |
From @jkeenanOn Sat, 23 Dec 2017 07:56:23 GMT, zefram@fysh.org wrote:
There may not be a bug in perl here -- but there's certainly a deficiency in our documentation. I've been writing Perl for a long time but have never had occasion to 'use overload'. I stared at the original poster's code and couldn't see anything obviously wrong. I then went and read the documentation. Again, I couldn't find anything that would lead me to guess that the OP's code would segfault. So we have to improve the documentation. Otherwise, people will repeatedly stumble into this problem. How should we change the docs? Thank you very much. -- |
From @eserte"James E Keenan via RT" <perlbug-followup@perl.org> writes:
With "use warnings" the script emits Useless use of string eq in void context at ... At least the "deep recursion" warning should be a note to the But maybe a sentence in perldiag.pod could be added. Regards, -- Berlin Perl Mongers - http://berlin.pm.org |
From gm@qwurx.deFrom the keyboard of Zefram [23.12.17,07:56]:
That's right; on my machine that segfaults at recursion 26186, gdb bt
You're probably right here, but: I guess this could be handled more gracefully by determining the stack Is it feasible to implement an overloading short-circuit detection? best regards, -- |
From zefram@fysh.orgshmem wrote:
For two reasons. Firstly, buffer overflow is always an implementation It would be nicer if deep recursion that currently occurs on the C stack -zefram |
From @cpansproutOn Sat, 23 Dec 2017 07:42:52 -0800, zefram@fysh.org wrote:
This is the first I’ve heard of it being a design decision, rather than an unfortunate unfixable flaw. -- Father Chrysostomos |
From gm@qwurx.deFrom the keyboard of Zefram [23.12.17,15:42]:
Arguably the buffer overflow is an implementation mistake of the C
It is not a design decision of perl, because it is not perl which emits I know far too little of the perl internals to be able to tell at which An alternative would be to set up an alternate signal stack as described The current stack size limit is a perl runtime condition. If I run the Running it with my current ulimit settings (-s being 8192 kbytes) it The simple recursion 'sub r{&r} r' instead seems to make the heap grow, Does that make sense? best regards, -- |
Migrated from rt.perl.org#132638 (status was 'open')
Searchable as RT132638$
The text was updated successfully, but these errors were encountered: