After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder
which can longjmp(3) to it through its vtx_assert()s. This corrupts
the stack and creates confusing core dumps, so we need to avoid it.
While there, I decided to print the offending values for debugability.
---
And pushed.
On Fri, Jun 1, 2018 at 8:04 AM, Jason Ekstrand wrote:
> Reviewed-by: Jason Ekstrand
>
> On Fri, Jun 1, 2018 at 5:27 AM, Martin Pelikán wrote:
>
>> After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder
>> which can longjmp(3) to it through its vtx_assert()s. This
Reviewed-by: Jason Ekstrand
On Fri, Jun 1, 2018 at 5:27 AM, Martin Pelikán wrote:
> After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder
> which can longjmp(3) to it through its vtx_assert()s. This corrupts
> the stack and creates confusing core dumps, so we need to avoid it.
On Sun, May 13, 2018 at 9:01 AM, Martin Pelikán wrote:
> After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder
> which can longjmp(3) to it through its vtx_assert()s. This corrupts
> the stack and creates confusing core dumps, so we need to avoid it.
>
> While there, I decided to
After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder
which can longjmp(3) to it through its vtx_assert()s. This corrupts
the stack and creates confusing core dumps, so we need to avoid it.
While there, I decided to print the offending values for debugability.
---
Ugh... I know this worked correctly when I did it. I think the setjmp must
not have quite survived over of the refactors. I need to take a serious
look at out on Monday.
On May 13, 2018 09:02:24 Martin Pelikán wrote:
After bebe3d626e5, b->fail_jump is prepared after