* David Malcolm <[email protected]> [2010-08-17 12:05:27]:
> On Tue, 2010-08-17 at 11:45 -0400, Jason Baron wrote:
> > On Tue, Aug 17, 2010 at 08:31:35PM +0530, Balbir Singh wrote:
> > > * Jason Baron <[email protected]> [2010-08-17 10:37:25]:
> > >
> > > > On Sat, Aug 14, 2010 at 10:38:27AM +0530, Balbir Singh wrote:
> > > > > >> I have the python wrapper working to a large degree
> > > > > >>
> > > > > >
> > > > > > cool!
> > > > > >
> > > > > >> 1. Please provide input if it works at your end
> > > > > >
> > > > > > hmmm...I'm getting a Segmentation fault, which is coming from
> > the inner
> > > > > > read stats loop. If I comment out the inner loop, I get a
> > correct
> > > > > > listing of the directories.
> > > > > >
> > > > > > Haven't been able to narrow it down more than that yet...using
> > libcgroup
> > > > > > libcgroup-0.36.2-2.fc15.i686. However, my python pkg might be
> > outdated
> > > > > > i'm using: Python 2.6.4. I'll re-test after upgrading.
> > > > > >
> > > > >
> > > > > Could you please narrow down using gdb and see where the dump is
> > > > > coming from. Are you suggesting that ret, p =
> > > > > cgroup_read_stats_next(p, cg_stat) in python code is causing the
> > > > > problem? python 2.6.4 is good, 2.7 would require movement to the
> > > > > capsule module in python. What version of swig are you using?
> > > > >
> > > > > Balbir
> > > >
> > > > Hi,
> > > >
> > > > so the output from the unmodified script is:
> > > >
> > > > "
> > > > $ ./try.py
> > > >
> > > > Directory /
> > > >
> > > > :
> > > > Segmentation fault (core dumped)
> > > > "
> > > >
> > > > running gdb on the resulting core:
> > > >
> > > > Core was generated by `/usr/bin/python ./try.py'.
> > > > Program terminated with signal 11, Segmentation fault.
> > > > #0 0x002c31b8 in _IO_getdelim (lineptr=0xbf9fb8dc, n=0xbf9fb8d8,
> > > > delimiter=10, fp=0xb776fb78) at iogetdelim.c:58
> > > > 58 _IO_acquire_lock (fp);
> > > > (gdb) bt
> > > > #0 0x002c31b8 in _IO_getdelim (lineptr=0xbf9fb8dc, n=0xbf9fb8d8,
> > > > delimiter=10, fp=0xb776fb78) at iogetdelim.c:58
> > >
> > > I am sure the fp here is invalid, does print *fp at frame 0 give
> > > anything useful?
> > >
> >
> > (gdb) p fp
> > $2 = (_IO_FILE *) 0xb776fb78
> > (gdb) p *fp
> > $3 = {_flags = 37, _IO_read_ptr = 0x738c20 "R", _IO_read_end = 0x1
> > <Address 0x1 out of bounds>,
> > _IO_read_base = 0x567ea871 <Address 0x567ea871 out of bounds>,
> > _IO_write_base = 0x1 <Address 0x1 out of bounds>,
> > _IO_write_ptr = 0x670070 "", _IO_write_end = 0x2 <Address 0x2 out of
> > bounds>, _IO_buf_base = 0x738c20 "R",
> > _IO_buf_end = 0x3 <Address 0x3 out of bounds>, _IO_save_base =
> > 0x1326ccc8 <Address 0x1326ccc8 out of bounds>,
> > _IO_backup_base = 0x1 <Address 0x1 out of bounds>, _IO_save_end =
> > 0x707574 "C\203\004\002O\n\r\004\306\303A\305\016\004A\v(",
> > _markers = 0x1, _chain = 0x738c20, _fileno = 2, _flags2 = -1,
> > _old_offset = 0, _cur_column = 256, _vtable_offset = 0 '\000',
> > _shortbuf = "", _lock = 0x3, _offset = 8597507104, _codecvt =
> > 0xaa3d09e9, _wide_data = 0x1, _freeres_list = 0x7273,
> > _freeres_buf = 0x1, _freeres_size = 7572512, _mode = 2,
> > _unused2 =
> > "\377\377\377\377\000\000\000\000\000\001\000\000\001\000\000\000
> > \214s\000\002\000\000\000??\376#\001\000\000\000bs\000\000\001\000
> > \000"}
> >
> >
> > > > #1 0x00761b33 in getline (fp=<value optimized out>,
> > > > cgroup_stat=0xa0c6950) at /usr/include/bits/stdio.h:118
> > > > #2 cg_read_stat (fp=<value optimized out>, cgroup_stat=0xa0c6950)
> > at
> > > > api.c:2786
> > > > #3 0x00765f65 in cgroup_read_stats_next (handle=0xbf9fb944,
> > > > cgroup_stat=0xa0c6950) at api.c:2836
> > > > Let me know what additional information I can provide. I did
> > update this
> > > > system to Python 2.7, but I was seeing the same crash with the
> > previous
> > > > 2.6.4. I'm using SWIG Version 2.0.0
> > > >
> > >
> > > I am using python 2.6.4 as well, but swig 1.3.40, I've not tried
> > swig
> > > 2.0.0. Could you please post the generated wrapper libcgroup_wrap.c?
> > >
> >
> >
> > /*
> > ----------------------------------------------------------------------------
> > * This file was automatically generated by SWIG
> > (http://www.swig.org).
> > * Version 2.0.0
>
> [snip]
>
>
> > SWIGINTERN PyObject *_wrap_cgroup_walk_tree_begin(PyObject
> > *SWIGUNUSEDPARM(self), PyObject *args) {
> > PyObject *resultobj = 0;
> > char *arg1 = (char *) 0 ;
> > char *arg2 = (char *) 0 ;
> > int arg3 ;
> > void **arg4 = (void **) 0 ;
> > struct cgroup_file_info *arg5 = (struct cgroup_file_info *) 0 ;
> > int *arg6 = (int *) 0 ;
> > int res1 ;
> > char *buf1 = 0 ;
> > int alloc1 = 0 ;
> > int res2 ;
> > char *buf2 = 0 ;
> > int alloc2 = 0 ;
> > int val3 ;
> > int ecode3 = 0 ;
> > void *temp4 ;
> [snip]
>
> > arg3 = (int)(val3);
> > {
> > void *arg;
> > if ((arg = PyCObject_AsVoidPtr(obj3)) != NULL) {
> > arg4 = &arg;
> > } else
> > arg4 = &temp4;
> > }
> [snip]
>
> I spent some time looking at this with Jason yesterday.
>
> If I'm reading things correctly the bug is above: "arg" here is a
> temporary on the stack within _wrap_cgroup_walk_tree_begin, so arg4
> points to the stack.
>
> > result = (int)cgroup_walk_tree_begin((char const *)arg1,(char const
> > *)arg2,arg3,arg4,arg5,arg6);
>
> so cgroup_walk_tree_begin is invoked with arg4 as a pointer to a void*
> on the stack; when _wrap_cgroup_walk_tree_begin returns, *arg4 is reused
> for other things on the stack; later attempts to dereference it lead to
> a crash.
>
arg4 points to obj3 converted to void pointer provided
cgroup_walk_tree_begin() had been called and set. arg4 is allocated
and not meant to be interpreted, where do you see it being reused?
Please see the return value being returned as a tuple, where we do
the reverse.
The expected usage is
tree_handle = c_void_p()
lvl = new_intp()
controller_info.name is set to the controller name
ret1, tree_handle = cgroup_walk_tree_begin(controller_info.name, "/",
0, tree_handle,
info, lvl)
> It looks like this parameter is intended as an opaque type for storing
> the state of an iteration. If that's the case it's probably much
> cleaner to introduce a struct for this (and only publish the layout of
> the struct internally to libcgroup). Doing so avoids the need to use
> ctypes. Is libcgroups's API set in stone yet, or can this be changed?
>
I'm running this on my machine all the time and it works without a
glitch.
--
Three Cheers,
Balbir
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel
