traveling-ruby
traveling-ruby copied to clipboard
segfault caused on VIA Nano processor U2250
We've recently distributed VirtKick binaries to our users. One user got segfaults all the time. Not sure if it's directly in Ruby, or some native extension like sqlite (we use sqlite in this application). That's the systemd journal with the backtrace.
CentOS 7 x86_64
[root@hostname ~]# uname -a
Linux hostname 3.10.0-123.13.2.el7.x86_64 #1 SMP Thu Dec 18 14:09:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
VIA Nano processor U2250 lacking some flags that your code requires to run?
[root@hostname ~]# cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 15
model name : VIA Nano processor U2250 (1.6GHz Capable)
stepping : 3 cpu
MHz : 800.000
cache size : 1024 KB
physical id : 0
siblings : 1 '
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc rep_good nopl pni monitor vmx est tm2 ssse3 cx16 xtpr rng rng_en ace ace_en ace2 phe phe_en lahf_lm
bogomips : 3192.14
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
Thanks.
I'm not sure. This is also the first time I've ever heard of this processor. The backtrace doesn't reveal anything related to C extensions, though that doesn't rule out that it's caused by a C extension.
The backtrace seems to imply that the crash occurs in some string hashing function, though I cannot think of a reason why that might be the case.
Is the app crashing consistently during startup?
Could you also report this to the upstream Ruby authors? This might be an issue in Ruby itself. If they need debugging symbols, I'd be happy to supply them.
This is also the first time I've ever heard of this processor.
Me too.
Is the app crashing consistently during startup?
Yes, the systemd service is set as Restart=always
which means systemd keeps the process alive any time the process dies, or whatever. The error repeats many times in the log I provided.
Could you also report this to the upstream Ruby authors? This might be an issue in Ruby itself. If they need debugging symbols, I'd be happy to supply them.
I can, but I'd like to work out the error report text with you. I suck at C-level things, so I wouldn't really know what to state there, other than what I reported to you. ;)
What you have reported here is pretty much what you should report to the Ruby authors. There's not much else I can extract from this information either.
Have you also tried running VirtKick on a CentOS 7 x86_64 system, but on a regular Intel or AMD processor? Does that work?
There's not much else I can extract from this information either.
Isn't any info on how you compile Ruby needed? Like what optimizations are applied, etc. Little do I know about this.
Does that work?
Works okay.
I had some troubles with such processor in a different project. Code worked on Intel and AMD but on VIA crashed with unknown instruction. Cannot recall the specifics but I was using some -march=
and I had to make the build very very generic instead.
Isn't any info on how you compile Ruby needed? Like what optimizations are applied, etc. Little do I know about this.
Just standard compiler options on CentOS 5 x86_64. That's -O2.
Cannot recall the specifics but I was using some -march= and I had to make the build very very generic instead.
That's good to know. But this is x86_64 we're talking about. There is only one possible target; I cannot make the binary any more generic than this.