mitchellh
mrb_load_file panics due to an expired syscall
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.
this ruby code in a file that is loaded with LoadFile will break it:
sleep 600
@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.
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 [email protected] 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 https://github.com/golang/go/issues/15639#issuecomment-219897791 which may be relevant.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mitchellh/go-mruby/issues/40#issuecomment-259955001, or mute the thread https://github.com/notifications/unsubscribe-auth/AABJ6w8cJFKjZurvW7HPEAKSB6FqmP2iks5q9GqYgaJpZM4KjGyY .
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.
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 [email protected] 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 https://github.com/mitchellh/go-mruby/issues/40#issuecomment-261237559, or mute the thread https://github.com/notifications/unsubscribe-auth/AABJ67hW3kRkvntr5BNJIwSx_SjDCQvDks5q_EwRgaJpZM4KjGyY .
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 [email protected] 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 [email protected] 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 https://github.com/mitchellh/go-mruby/issues/40#issuecomment-261237559, or mute the thread https://github.com/notifications/unsubscribe-auth/AABJ67hW3kRkvntr5BNJIwSx_SjDCQvDks5q_EwRgaJpZM4KjGyY .
@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.