Accounts filling up with core.##### files.

J

jp_n9

Active Member
#1
#1
I have two Ruby on Rails apps on a VPS account with LiteSpeed 3.0.3

I had one account fill up last week with tons of files such as core.11323, core.12015, etc...

This morning I got another warning that the other account was running out of disk space, and sure enough it was getting filled up by the same core.##### files. I'm guessing the numeric portion of the filename is a process ID?

Although sometimes these files are empty, they are normally about 20MB each.

I don't know for sure that LiteSpeed is creating them, or what exactly they are. Has any one else experienced this? Any suggestions on how to track down the cause?

I had been running the first Rails app for 6 months and never had any problem. The only thing that has changed to the setup are upgrades to LSWS, LSAPI and that I added a second app to the VPS.
 
M

mistwang

LiteSpeed Staff
#2
#2
LSWS only dump core files to /tmp/lshttpd/.
The core file should be created by ruby. Maybe a LSAPI bug? Can you please check the core file using gdb?
Code: 
 gdb /usr/local/bin/ruby <corefile>
bt
Then post the output here.
 
J

jp_n9

Active Member
#5
#5
"yum install gdb" gives me an error because it is pointing to the fedoralegacy.org repository - which is no longer operational. Let me see if I can either find another repository or just compile it.
 
M

mistwang

LiteSpeed Staff
#6
#6
Looks like you are using a old linux distribution, you can try search the gdb rpm for your linux distribution, it probably is easier.
Compiling from source is fine, just hope it will not require other packages.
 
J

jp_n9

Active Member
#7
#7
According to GDB:

Core was generated by `ruby /opt/lsws/fcgi-bin/RailsRunner.rb'.

And these are showing up in /home/account_name/current NOT /tmp/lshttpd/.
 
J

jp_n9

Active Member
#9
#9
#0 0x40093da1 in kill () from /lib/libc.so.6
#1 0x40093b6c in raise () from /lib/libc.so.6
#2 0x40094d95 in abort () from /lib/libc.so.6
#3 0x080be06a in rb_bug (fmt=0x80d85a9 "Segmentation fault") at error.c:214
#4 0x080a1f9c in sigsegv (sig=11) at signal.c:447
#5 <signal handler called>
#6 0x080a4112 in st_lookup (table=0x408ea4bc, key=3959, value=0xbfffc4b4)
at st.c:245
#7 0x080527b7 in search_method (klass=1083090108, id=3959, origin=0xbfffc4b4)
at eval.c:434
#8 0x08052801 in rb_get_method_body (klassp=0xbfffc4f0, idp=0xbfffc4f4,
noexp=0xbfffc4e4) at eval.c:455
#9 0x08052967 in rb_method_node (klass=1083090108, id=3959) at eval.c:511
#10 0x0805905c in rb_obj_respond_to (obj=1083090128, id=6841, priv=0)
at eval.c:4110
#11 0x08059117 in rb_respond_to (obj=1083090128, id=6841) at eval.c:4127
#12 0x0807f1ac in convert_type (val=1083090128, tname=0x80c180c "Hash",
method=0x80c33ab "to_hash", raise=2) at object.c:2120
#13 0x0807f28a in rb_convert_type (val=1083090128, type=11,
tname=0x80c180c "Hash", method=0x80c33ab "to_hash") at object.c:2145
#14 0x0806c8e6 in to_hash (hash=1083090128) at hash.c:352
#15 0x0806cfa3 in rb_hash_replace (hash=1083089948, hash2=1) at hash.c:950
#16 0x08065e27 in call_cfunc (func=0x806cf90 <rb_hash_replace>,
---Type <return> to continue, or q <return> to quit---
recv=1083089948, len=0, argc=1, argv=0x6) at eval.c:5550
#17 0x0805b4ff in rb_call0 (klass=1075566932, recv=1083089948, id=4345, oid=0,
argc=1, argv=0xbfffc7f0, body=0x401bd2d8, flags=0) at eval.c:5692
#18 0x0805bd6d in rb_call (klass=1075566932, recv=1083089948, mid=4345,
argc=1, argv=0xbfffc7f0, scope=1) at eval.c:5920
#19 0x0805bfd2 in vafuncall (recv=1083089948, mid=4345, n=1, ar=0xbfffc834)
at ruby.h:638
#20 0x0805c03e in rb_funcall (recv=1083089948, mid=4345, n=1) at eval.c:6014
#21 0x40bfffa8 in clear_env () at lsruby.c:90
#22 0x40bfffcd in setup_cgi_env (data=0x89f63e0) at lsruby.c:96
#23 0x40c005e4 in lsapi_s_accept (self=1083089648) at lsruby.c:323
#24 0x08065e27 in call_cfunc (func=0x40c00488 <lsapi_s_accept>,
recv=1083089648, len=0, argc=0, argv=0x6) at eval.c:5550
#25 0x0805b4ff in rb_call0 (klass=1083089628, recv=1083089648, id=10289,
oid=0, argc=0, argv=0x0, body=0x408ea2c8, flags=0) at eval.c:5692
#26 0x0805bd6d in rb_call (klass=1083089628, recv=1083089648, mid=10289,
argc=0, argv=0x0, scope=0) at eval.c:5920
#27 0x0805749e in rb_eval (self=1075595632, n=0x0) at eval.c:3383
#28 0x0805739a in rb_eval (self=1075595632, n=0x0) at eval.c:3375
#29 0x080566fc in rb_eval (self=1075595632, n=0x0) at eval.c:3068
#30 0x08053d30 in ruby_exec_internal () at eval.c:1543
#31 0x08053d64 in ruby_exec () at eval.c:1563
#32 0x08053d89 in ruby_run () at eval.c:1573
#33 0x080521bd in main (argc=2, argv=0xbfffe654, envp=0xbfffe660) at main.c:46
#34 0x4008262d in __libc_start_main () from /lib/libc.so.6
 
M

mistwang

LiteSpeed Staff
#10
#10
The bug is inside ruby, not in our LSAPI code.
Code: 
 #6  0x080a4112 in st_lookup (table=0x408ea4bc, key=3959, value=0xbfffc4b4)
    at st.c:245
#7  0x080527b7 in search_method (klass=1083090108, id=3959, origin=0xbfffc4b4)
    at eval.c:434
#8  0x08052801 in rb_get_method_body (klassp=0xbfffc4f0, idp=0xbfffc4f4, 
    noexp=0xbfffc4e4) at eval.c:455
#9  0x08052967 in rb_method_node (klass=1083090108, id=3959) at eval.c:511
#10 0x0805905c in rb_obj_respond_to (obj=1083090128, id=6841, priv=0)
    at eval.c:4110
#11 0x08059117 in rb_respond_to (obj=1083090128, id=6841) at eval.c:4127
Have you upgrade ruby release? Maybe you can fill bug report to ruby developers. :)
 
You must log in or register to reply here.
Top