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.
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?
Hope this is helpful
Dave
------------------------------------------------------------------------------
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
