develooper Front page | perl.perl5.porters | Postings from December 2017

Re: [perl #132638] I've discovered a segfault

Thread Previous | Thread Next
From:
shmem
Date:
December 23, 2017 15:32
Subject:
Re: [perl #132638] I've discovered a segfault
Message ID:
alpine.DEB.1.00.1712231416120.2163@mail.mgm-net.de
From the keyboard of Zefram [23.12.17,07:56]:

> Danijel Tasov wrote:
>> use overload
>> 'eq' => \&equals_to,
> ...
>> sub equals_to{ $_[0] eq $_[1] }
>
> Here's your problem you've defined the "eq" overload to apply "eq" to
> its operands, which invokes the "eq" overload in an infinite recursion.

That's right; on my machine that segfaults at recursion 26186, gdb bt
shows 104775 stack frames.

> The segv is just C stack overflow.  You probably want to write the "eq"
> overload as
>
>    sub equals_to{ "$_[0]" eq $_[1] }
>
> or just remove that overload and enable overload fallback, so that Perl
> will synthesise that "eq" overload for you.
>
> There is no Perl bug here.

You're probably right here, but:
Why should a buffer overflow be a bug but a stack overflow should not?

I guess this could be handled more gracefully by determining the stack
limit before runtime and die with an appropriate message, instead of
running into a SIGSEGV.

Is it feasible to implement an overloading short-circuit detection?

best regards,
0--gg-

-- 
_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                               /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About