[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

segfaulting in IO.popen

Andres Salomon

9/27/2004 8:07:00 PM

Hi,

I'm having a problem w/ mod_xmlrpc segfaulting inside a call to
IO.popen. The code snippet that's being run is:

cmd = 'sudo ' + PRIV + ' /usr/bin/apt-get -u --trivial-only dist-
upgrade'
skip = 2

f = IO.popen(cmd)
output = f.readlines



Here's the backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1079499040 (LWP 14934)]
0x4063931e in st_lookup (table=0x0, key=321, value=0xbfff92b8) at
st.c:258
258 hash_val = do_hash(key, table);
(gdb) bt
#0 0x4063931e in st_lookup (table=0x0, key=321, value=0xbfff92b8) at
st.c:258
#1 0x405d5106 in search_method (klass=1085430708, id=321,
origin=0xbfff92e4)
at eval.c:380
#2 0x405d5161 in rb_get_method_body (klassp=0xbfff9340, idp=0xbfff9324,
noexp=0xbfff9328) at eval.c:401
#3 0x405e012e in rb_call (klass=1085430708, recv=1085430908, mid=321,
argc=1,
argv=0xbfff9358, scope=0) at eval.c:5732
#4 0x405daccf in rb_eval (self=1086135396, n=0x0) at ruby.h:631
#5 0x405d96da in rb_eval (self=1086135396, n=0x0) at eval.c:2804
#6 0x405dfad2 in rb_call0 (klass=1086135376, recv=1086135396, id=10777,
oid=0, argc=0, argv=0x0, body=0x40ac52c8, nosuper=0) at eval.c:5663
#7 0x405e01eb in rb_call (klass=1086135376, recv=1086135396, mid=10777,
argc=0, argv=0x0, scope=0) at eval.c:5756
#8 0x405daccf in rb_eval (self=1086135336, n=0x0) at ruby.h:631
#9 0x405dfad2 in rb_call0 (klass=1086135176, recv=1086135336, id=10801,
oid=0, argc=0, argv=0x0, body=0x40ac50c0, nosuper=0) at eval.c:5663
#10 0x405e01eb in rb_call (klass=1086135176, recv=1086135336, mid=10801,
argc=0, argv=0x0, scope=0) at eval.c:5756
#11 0x405daccf in rb_eval (self=1085632956, n=0x0) at ruby.h:631
#12 0x405da5b1 in rb_eval (self=1085632956, n=0x0) at eval.c:3427
#13 0x405dfad2 in rb_call0 (klass=1085632936, recv=1085632956, id=22953,
oid=0, argc=0, argv=0xbfffd2b8, body=0x40b60a50, nosuper=0) at
eval.c:5663
#14 0x405e01eb in rb_call (klass=1085632936, recv=1085632956, mid=22953,
---Type <return> to continue, or q <return> to quit---
argc=2, argv=0xbfffd2b0, scope=1) at eval.c:5756
#15 0x405e060e in rb_funcall2 (recv=321, mid=0, argc=0, argv=0x0) at
ruby.h:631
#16 0x4001a875 in do_funcall (args=135795528)
at /home/dilinger/src/modxmlrpc2--mainline--0--
patch-18/mod_xmlrpc_rb.c:73
#17 0x405df059 in rb_protect (proc=0x4001a800 <do_funcall>, data=0,
state=0xbfffd4f8) at eval.c:5184
#18 0x4001a8f7 in protected_funcall2 (obj=0, method=2, err=0xbfffd4f8,
argc=2,
args=0xbfffd4d4)
at /home/dilinger/src/modxmlrpc2--mainline--0--
patch-18/mod_xmlrpc_rb.c:91
#19 0x4001b0ea in do_callback (env=0xbfffd580, param=0x8358188,
n=0x8272e90)
at /home/dilinger/src/modxmlrpc2--mainline--0--
patch-18/mod_xmlrpc_rb.c:301
#20 0x405951de in xmlrpc_registry_set_default_method ()
from /usr/lib/libxmlrpc.so.3
#21 0x405952b6 in xmlrpc_registry_process_call ()
from /usr/lib/libxmlrpc.so.3
#22 0x4001b96a in mod_xmlrpc_server_parse (registry=0x0, data=0x0,
len=0,
r=0x0)
at /home/dilinger/src/modxmlrpc2--mainline--0--
patch-18/mod_xmlrpc_server.c:47
#23 0x4001a0b1 in xmlrpc_handler (r=0x8322690)
at /home/dilinger/src/modxmlrpc2--mainline--0--
patch-18/mod_xmlrpc.c:108
#24 0x080782c5 in ap_run_handler ()
#25 0x080f1918 in ?? ()
#26 0x08106080 in ?? ()
---Type <return> to continue, or q <return> to quit---
#27 0x08322690 in ?? ()
#28 0x08322690 in ?? ()
#29 0x00000000 in ?? ()
#30 0xbffff698 in ?? ()
#31 0x080788d0 in ap_invoke_handler ()
Previous frame inner to this frame (corrupt stack?)
(gdb)


It looks to me like the klass that's being passed to search_method()
doesn't have a valid m_tbl. Here's the interpreter that I'm using; it's
an apache2 module that loads ruby scripts, and allows the ModXMLRPC
class methods to be called via xmlrpc:
http://www.acm.rpi.edu/~dilinger/modxmlrpc-s...

Any suggestions or tips on how to fix this would be appreciated. I'm
not sure whether the culprit is something in ruby, or in mod_xmlrpc.



--
Andres Salomon <dilinger@voxel.net>
2 Answers

Yukihiro Matsumoto

9/27/2004 11:43:00 PM

0

Hi,

In message "Re: segfaulting in IO.popen()"
on Tue, 28 Sep 2004 05:07:18 +0900, Andres Salomon <dilinger@voxel.net> writes:

|I'm having a problem w/ mod_xmlrpc segfaulting inside a call to
|IO.popen. The code snippet that's being run is:
|
|cmd = 'sudo ' + PRIV + ' /usr/bin/apt-get -u --trivial-only dist-upgrade'
|skip = 2
|
|f = IO.popen(cmd)
|output = f.readlines

Can you show us error reproducing script and how to run it? Code
snippet is not enough to detect bugs. Do I have to compile

|http://www.acm.rpi.edu/~dilinger/modxmlrpc-s...

to get an error?


matz.

Andres Salomon

9/28/2004 2:24:00 AM

0

On Tue, 2004-09-28 at 08:42 +0900, Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: segfaulting in IO.popen()"
> on Tue, 28 Sep 2004 05:07:18 +0900, Andres Salomon <dilinger@voxel.net> writes:
>
> |I'm having a problem w/ mod_xmlrpc segfaulting inside a call to
> |IO.popen. The code snippet that's being run is:
> |
> |cmd = 'sudo ' + PRIV + ' /usr/bin/apt-get -u --trivial-only dist-upgrade'
> |skip = 2
> |
> |f = IO.popen(cmd)
> |output = f.readlines
>
> Can you show us error reproducing script and how to run it? Code
> snippet is not enough to detect bugs. Do I have to compile
>

Unfortunately, I can't reproduce it with an individual script; I need
all the scripts together (this bug has been incredibly frustrating to
narrow down). I actually managed to make the bug go away by wrapping
dbi, openssl, and ipaddr requires w/ GC.disable/GC.enable (ie,
GC.disable
require 'ipaddr'
GC.enable).




> |http://www.acm.rpi.edu/~dilinger/modxmlrpc-s...
>
> to get an error?
>

Yes; the dependencies are kind of specific (apache2, xmlrpc-c, cmake..).
If you use debian, I can prepare packages for you (libapache2-mod-
xmlrpc2 is already in debian testing/unstable, but it's an older version
that doesn't have ruby support).

I'll try to narrow this down as much as possible, as I realize I'm not
giving you much to work w/; unfortunately, I've seen variations of this
bug (I think) before, and it's been randomly appearing/disappearing for
months.


--
Andres Salomon <dilinger@voxel.net>