kgio Gem segfaults the VM #2837

Closed
YorickPeterse opened this Issue Dec 18, 2013 · 4 comments

Projects

None yet

2 participants

@YorickPeterse
Member

Although I'm not really sure if kgio is supposed to work on Rbx, and if it even brings any benefits, I figured it's worth reporting. Currently I'm running a bunch of benchmarks and kgio happens to be loaded, mainly for Dalli. Upon exiting the application (using ^C) I was greeted with the following error:

Rubinius Crash Report #rbxcrashreport

Error: signal SIGSEGV

[[Backtrace]]
ruby[0x59c530]
/lib64/libpthread.so.0(+0xf8e0)[0x7fe37b1698e0]
/lib64/libc.so.6(fileno_unlocked+0x0)[0x7fe37a9a74c0]
/var/www/review_collector/deploy-2013-12-17_19_34_37/vendor/bundle/rbx/2.1/gems/kgio-2.8.1/lib/kgio_ext.so(+0x51cd)[0x7fe3598031cd]
/var/www/review_collector/deploy-2013-12-17_19_34_37/vendor/bundle/rbx/2.1/gems/kgio-2.8.1/lib/kgio_ext.so(+0x5335)[0x7fe359803335]
/var/www/review_collector/deploy-2013-12-17_19_34_37/vendor/bundle/rbx/2.1/gems/kgio-2.8.1/lib/kgio_ext.so(+0x54c9)[0x7fe3598034c9]
ruby(_ZN8rubinius12NativeMethod23executor_implementationINS_11OneArgumentEEEPNS_6ObjectEPNS_5StateEPNS_9CallFrameEPNS_10ExecutableEPNS_6ModuleERNS_9ArgumentsE+0x409)[0x6be259]
ruby(_ZN8rubinius11MachineCode11interpreterEPNS_5StateEPS0_PNS_20InterpreterCallFrameE+0x1e97)[0x5c16a7]
ruby(_ZN8rubinius11MachineCode19execute_specializedINS_11OneArgumentEEEPNS_6ObjectEPNS_5StateEPNS_9CallFrameEPNS_10ExecutableEPNS_6ModuleERNS_9ArgumentsE+0x298)[0x5ff0a8]
ruby(_ZN8rubinius8CallSite19empty_cache_privateEPNS_5StateEPS0_PNS_9CallFrameERNS_9ArgumentsE+0x138)[0x6893f8]
ruby(_ZN8rubinius11MachineCode11interpreterEPNS_5StateEPS0_PNS_20InterpreterCallFrameE+0x1e97)[0x5c16a7]
ruby(_ZN8rubinius11MachineCode19execute_specializedINS_11OneArgumentEEEPNS_6ObjectEPNS_5StateEPNS_9CallFrameEPNS_10ExecutableEPNS_6ModuleERNS_9ArgumentsE+0x298)[0x5ff0a8]
ruby(_ZN8rubinius8Dispatch4sendEPNS_5StateEPNS_9CallFrameERNS_10LookupDataERNS_9ArgumentsENS_19MethodMissingReasonE+0x6c)[0x59bbcc]
ruby(_ZN8rubinius6Object9send_primEPNS_5StateEPNS_9CallFrameEPNS_10ExecutableEPNS_6ModuleERNS_9ArgumentsEPNS_6SymbolE+0x101)[0x6bfcc1]
ruby(_ZN8rubinius6Object17private_send_primEPNS_5StateEPNS_9CallFrameEPNS_10ExecutableEPNS_6ModuleERNS_9ArgumentsE+0x1c)[0x6bfd3c]
ruby(_ZN8rubinius10Primitives11object_sendEPNS_5StateEPNS_9CallFrameEPNS_10ExecutableEPNS_6ModuleERNS_9ArgumentsE+0x52)[0x625aa2]
ruby(_ZN8rubinius8CallSite19empty_cache_privateEPNS_5StateEPS0_PNS_9CallFrameERNS_9ArgumentsE+0x138)[0x6893f8]
ruby(_ZN8rubinius11MachineCode11interpreterEPNS_5StateEPS0_PNS_20InterpreterCallFrameE+0x2113)[0x5c1923]
ruby(_ZN8rubinius11MachineCode19execute_specializedINS_16GenericArgumentsEEEPNS_6ObjectEPNS_5StateEPNS_9CallFrameEPNS_10ExecutableEPNS_6ModuleERNS_9ArgumentsE+0x21a)[0x5fda7a]
ruby(_ZN8rubinius8CallSite17empty_cache_superEPNS_5StateEPS0_PNS_9CallFrameERNS_9ArgumentsE+0x129)[0x6882e9]
ruby(_ZN8rubinius11MachineCode11interpreterEPNS_5StateEPS0_PNS_20InterpreterCallFrameE+0x41a4)[0x5c39b4]
ruby(_ZN8rubinius16BlockEnvironment19execute_interpreterEPNS_5StateEPNS_9CallFrameEPS0_RNS_9ArgumentsERNS_15BlockInvocationE+0x201)[0x685b91]
ruby(_ZN8rubinius16BlockEnvironment6invokeEPNS_5StateEPNS_9CallFrameEPS0_RNS_9ArgumentsERNS_15BlockInvocationE+0x7d)[0x68628d]
ruby(_ZN8rubinius16BlockEnvironment4callEPNS_5StateEPNS_9CallFrameERNS_9ArgumentsEi+0x3d)[0x6864ad]
ruby(rbx_yield_stack+0xca)[0x76da5a]
[0x7fe342146ad7]

[[System Info]]
sysname: Linux
nodename: ip-10-80-18-152
release: 3.4.57-48.42.amzn1.x86_64
version: #1 SMP Mon Aug 12 21:43:36 UTC 2013
machine: x86_64

I'm perfectly fine with not using this particular Gem if it doesn't work, so far I haven't really noticed any IO boosts anyway.

@YorickPeterse
Member

This is on an EC2 m1.small instance running CentOS, whatever version Amazon ships (6.something I believe).

@dbussink
Member

We've fixed issues with kgio in the past, so if we can we should support it. Any way to reproduce this / extract the issue?

@YorickPeterse
Member

I have honestly no clue how I triggered it and I find it odd in particular that this only occurred when I terminated the application. I suspect it's due to the use of multi-threading but I'm not sure how we'd reproduce it.

@YorickPeterse
Member

Closing this one. I've since never seen this issue arise again so perhaps something related to it has been fixed in the mean time. I'll re-open this issue if it manifests again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment