mrb_load_file panics due to an expired syscall

[erikh]

In reference to #38 and #39:

I'm not sure if this is mruby or us, but here's a trace:

fatal error: exitsyscall: syscall frame is no longer valid

runtime stack:
runtime.throw(0x84679e, 0x2d)
        /usr/local/go/src/runtime/panic.go:566 +0x95
runtime.exitsyscall.func1()
        /usr/local/go/src/runtime/proc.go:2470 +0x36
runtime.systemstack(0x7ffe3ea0c490)
        /usr/local/go/src/runtime/asm_amd64.s:298 +0x79
runtime.mstart()
        /usr/local/go/src/runtime/proc.go:1079

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x7108e0, 0xc4201e0fd0, 0xc400000000)
        /usr/local/go/src/runtime/cgocall.go:131 +0x110 fp=0xc4201e0f88 sp=0xc4201e0f48
github.com/erikh/box/vendor/github.com/mitchellh/go-mruby._C2func_mrb_load_file(0x14ae400, 0x14cbc90, 0x0, 0x0, 0x0, 0x0)
        ??:0 +0x72 fp=0xc4201e0fd0 sp=0xc4201e0f88
github.com/erikh/box/vendor/github.com/mitchellh/go-mruby.(*Mrb).LoadFile(0xc420084370, 0xc4200107d0, 0x9, 0x0, 0x0, 0x0)
        /home/erikh/src/github.com/erikh/box/vendor/github.com/mitchellh/go-mruby/mruby.go:196 +0x219 fp=0xc4201e10b0 sp=0xc4201e0fd0
github.com/erikh/box/builder.(*Builder).Load(0xc420245000, 0xc4200107d0, 0x9, 0x1, 0x1, 0x0)
        /home/erikh/src/github.com/erikh/box/builder/builder.go:115 +0x43 fp=0xc4201e10f0 sp=0xc4201e10b0

box is my project, and it just calls LoadFile there.

[erikh]

this ruby code in a file that is loaded with LoadFile will break it:

sleep 600

[mikesimons]

@erikh Do you have exact code & steps we can use to reproduce this?

I pulled your load file patch and tried with implementations of sleep using both golang and mruby-sleep mgem but could not reproduce. Is there any chance that other goroutines could be sharing the mruby interpreter?

I did find this which may be relevant.

[erikh]

let me see if I can find the test case I used, but IIRC, I converted
github.com/erikh/box to use load_file instead of load_string (which is what
already exists). this is what caused the behavior.

box's tests build for about 20 minutes now, so it tripped in there
somewhere.

I'll try to investigate soon. If you are feeling confident in the patch,
I'm not going to object to it being merged if my case was an edge one.

On Fri, Nov 11, 2016 at 5:16 AM, Mike Simons notifications@github.com
wrote:

@erikh https://github.com/erikh Do you have exact code & steps we can
use to reproduce this?

I pulled your load file patch and tried with implementations of sleep
using both golang and mruby-sleep mgem but could not reproduce. Is there
any chance that other goroutines could be sharing the mruby interpreter?

I did find this
golang/go#15639 (comment) which
may be relevant.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABJ6w8cJFKjZurvW7HPEAKSB6FqmP2iks5q9GqYgaJpZM4KjGyY
.

[mikesimons]

My gut feel is that this is an issue albeit one that is triggered with a very specific, possibly compound set of steps. I haven't been able to replicate it though, even with your patch applied to box (and modified to use LoadFile).

This is the kind of tricky issue that is going to crop up and put folks off using it for stability concerns so I think it is important to understand the reasons behind it so we can either mitigate or inform potential users.

[erikh]

Sorry I was a little short, basically, what I did was make a long running
open mrb_load_file (running ruby program), at which point I got this error.
maybe a platform issue?

On Thu, Nov 17, 2016 at 4:44 AM, Mike Simons notifications@github.com
wrote:

My gut feel is that this is an issue albeit one that is triggered with
a very specific, possibly compound set of steps. I haven't been able to
replicate it though, even with your patch applied to box (and modified to
use LoadFile).

This is the kind of tricky issue that is going to crop up and put folks
off using it for stability concerns so I think it is important to
understand the reasons behind it so we can either mitigate or inform
potential users.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABJ67hW3kRkvntr5BNJIwSx_SjDCQvDks5q_EwRgaJpZM4KjGyY
.

[erikh]

for now, the code is reverted, I'm hoping I can resolve this soon.

On Thu, Nov 17, 2016 at 8:28 AM, Erik Hollensbe h-e@hollensbe.org wrote:

Sorry I was a little short, basically, what I did was make a long running
open mrb_load_file (running ruby program), at which point I got this error.
maybe a platform issue?

On Thu, Nov 17, 2016 at 4:44 AM, Mike Simons notifications@github.com
wrote:

My gut feel is that this is an issue albeit one that is triggered with
a very specific, possibly compound set of steps. I haven't been able to
replicate it though, even with your patch applied to box (and modified to
use LoadFile).

This is the kind of tricky issue that is going to crop up and put folks
off using it for stability concerns so I think it is important to
understand the reasons behind it so we can either mitigate or inform
potential users.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABJ67hW3kRkvntr5BNJIwSx_SjDCQvDks5q_EwRgaJpZM4KjGyY
.

[erikh]

@mikesimons ar eyou still using this project? do you still see this on recent versions? I have run a lot of builds through box now -- almost 10k/day now -- and I never see it.