[perl #23159] Parrot SIGSEGV in scratchpad_find

[Will Coleda via RT]

While there was a lot of talk in this thread about how we were not going to provide extra
checks to prevent segfaults... both the original case and the simple one below no longer
generate segfaults, but instead throw an exception of some kind.

Closing ticket.

> [sc...@amnh.org - Tue Jul 29 14:42:13 2003]:
>
>
> On Tue, 29 Jul 2003, Jos Visser wrote:
>
> > On Tue, Jul 29, 2003 at 09:11:15AM -0700 it came to pass that Mr.
> Nobody wrote:
> > > I don't think it's worth adding extra overhead to lexical
> variables just to
> > > support broken pasm. There are many ways to crash parrot with bad
> code - but
> > > it's OK, since compilers of higher level languages simply won't
> generate
> > > them. :)
> >
> > I would call an "if (!pad) return 0;" hardly extra overhead (4
> > instructions on an Intel x86). There is a lot of stuff you can not
> do
> > if this is the sort of overhead you are worried about.
> >
> > I was unaware that the entire parrot VM can crash due to bad code.
>
> It's actually extremely easy to do; for instance, this:
>
> set I0, P10
> end
>
> will segfault since Parrot tries to call get_integer on a NULL PMC
> (since
> there's nothing in P10 at startup).
>
> Now, this segfault can be avoided, just as the one you point out
> above
> can be avoided, but only at the cost of adding extra checks. The
> problem
> is that you wind up needing a LOT of these, if you're to guarantee
> that
> Parrot will never segfault when given bad code. So: in the individual
> case, the cost is not much (although branches are icky on modern
> processors due to deep pipelines), but in the aggregate it will be
> considerably more.
>
> Therefore the decision was taken that we should not guarantee that
> Parrot
> should never segfault when fed bad assembler; the creation of invalid
> assembler is a compiler bug, and should be fixed at the compiler
> level.
>
> (Note, however, that we should never segfault on _valid_ assembler).
>
> Hope that clarifies things, and thanks for the report and for the
> patch
> (even if we don't end up applying it).
>
> Simon
>
>
>
>