search

nagyistge / pyv8

Automatically exported from code.google.com/p/pyv8
0 stars 0 forks source link

Segmentation fault (PyV8 480 and later) #160

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
While executing some Thug tests I got a strange segfault with the latest 
versions of both V8 (-r13589) and PyV8 (-r491). 
I tried to downgrade PyV8 and realized that the issue was introduced in -r480 
(downgrading to -r479 the issue just 
disappears). 

Following a detailed analysis of the  segfault. If additional details are 
needed please ask.

buffer@saiph ~/thug/src $ python thug.py -l testHTMLTableElement.html 
Segmentation fault

buffer@saiph ~/thug/src $ gdb python
GNU gdb (Gentoo 7.5 p1) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
(gdb) r thug.py -l testHTMLTableElement.html
Starting program: /usr/bin/python thug.py -l testHTMLTableElement.html
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
process 20048 is executing new program: /usr/bin/python2.7
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff7ff2700 (LWP 20051)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ab8580 in PyType_IsSubtype () from /usr/lib64/libpython2.7.so.1.0

(gdb) info stack
#0  0x00007ffff7ab8580 in PyType_IsSubtype () from 
/usr/lib64/libpython2.7.so.1.0
#1  0x00007fffeffb6aff in CPythonObject::NamedGetter(v8::Local<v8::String>, 
v8::AccessorInfo const&) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#2  0x00007ffff0201997 in 
v8::internal::JSObject::GetPropertyWithInterceptor(v8::internal::Object*, 
v8::internal::String*, PropertyAttributes*) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#3  0x00007ffff0202432 in 
v8::internal::Object::GetProperty(v8::internal::Handle<v8::internal::Object>, 
v8::internal::Handle<v8::internal::Object>, v8::internal::LookupResult*, 
v8::internal::Handle<v8::internal::String>, PropertyAttributes*) ()
   from /usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#4  
#5  0x00007ffff017ce22 in v8::internal::LoadIC_Miss(v8::internal::Arguments, 
v8::internal::Isolate*) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#6  0x00002859e3a062ee in ?? ()
#7  0x0000000000000000 in ?? ()

(gdb) info frame  
Stack level 0, frame at 0x7fffffff89d0:
 rip = 0x7ffff7ab8580 in PyType_IsSubtype; saved rip 0x7fffeffb6aff
 called by frame at 0x7fffffff8c20
 Arglist at 0x7fffffff89c0, args: 
 Locals at 0x7fffffff89c0, Previous frame's sp is 0x7fffffff89d0
 Saved registers:
  rip at 0x7fffffff89c8

Original issue reported on code.google.com by angelo.d...@gmail.com on 4 Feb 2013 at 2:34

GoogleCodeExporter commented 8 years ago 
Sorry, I'm porting PyV8 to Python 3.x, and I will fix it later

Original comment by flier...@gmail.com on 4 Feb 2013 at 2:40

GoogleCodeExporter commented 8 years ago 
That's perfectly ok with me. Just testing the new changes in order to help you 
some way... :) 

Thanks again for your great work.

Original comment by angelo.d...@gmail.com on 4 Feb 2013 at 2:46

GoogleCodeExporter commented 8 years ago 
Thanks, I'm not familiar with Python 3.x, so, sometimes we need rollback some 
code :(

Original comment by flier...@gmail.com on 4 Feb 2013 at 2:51

GoogleCodeExporter commented 8 years ago 
A quick update. Seems like problems exist even in -r479. No problems at all in 
-r478.

Original comment by angelo.d...@gmail.com on 4 Feb 2013 at 4:37

GoogleCodeExporter commented 8 years ago 
Just a quick fix to avoid the segmentation fault, please verify it with SVN 
trunk code after r494

Original comment by flier...@gmail.com on 5 Feb 2013 at 4:13

GoogleCodeExporter commented 8 years ago 
Unfortunately it seems like the patch didn't fix the issue

buffer@saiph ~/pyv8 $ python PyV8.py -v
2013-02-05 09:37:54,016 INFO testing PyV8 module 1.0 with V8 v3.16.13
testBlock (__main__.TestAST) ... ok
testCallStatements (__main__.TestAST) ... ok
testForStatement (__main__.TestAST) ... ok
testIfStatement (__main__.TestAST) ... ok
testLiterals (__main__.TestAST) ... ok
testOperations (__main__.TestAST) ... ok
testSwitchStatement (__main__.TestAST) ... ok
testTryStatements (__main__.TestAST) ... ok
testMultiNamespace (__main__.TestContext) ... ok
testEventDispatch (__main__.TestDebug) ... 2013-02-05 09:37:54,039 DEBUG 
receive debug event: before compile script: <script script  @ 0:0> : 'function 
test() { text = "1+2"; return eval(text) } test()'

2013-02-05 09:37:54,042 DEBUG receive debug event: after compile script: 
<script script  @ 0:0> : 'function test() { text = "1+2"; return eval(text) } 
test()'

2013-02-05 09:37:54,046 DEBUG receive debug event: before compile script: 
<script script None @ 0:0> : '1+2'
#00 test() [unnamed] line 1 column 45 (position 45)#01 [anonymous]() [unnamed] 
line 1 column 53 (position 53)
2013-02-05 09:37:54,049 DEBUG receive debug event: after compile script: 
<script script None @ 0:0> : '1+2'
#00 test() [unnamed] line 1 column 45 (position 45)#01 [anonymous]() [unnamed] 
line 1 column 53 (position 53)
ok
testClassProperties (__main__.TestEngine) ... ok
testCompile (__main__.TestEngine) ... ok
testEval (__main__.TestEngine) ... ok
testExtension (__main__.TestEngine) ... ok
testGlobal (__main__.TestEngine) ... ok
testNativeExtension (__main__.TestEngine) ... ok
testObjectBuildInMethods (__main__.TestEngine) ... ok
testPrecompile (__main__.TestEngine) ... ok
testPythonWrapper (__main__.TestEngine) ... ok
testThis (__main__.TestEngine) ... ok
testUnicodeSource (__main__.TestEngine) ... ok
testLocker (__main__.TestMultithread) ... ok
testMultiJavascriptThread (__main__.TestMultithread) ... ok
testMultiPythonThread (__main__.TestMultithread) ... ok
testArray (__main__.TestWrapper) ... ok
testAutoConverter (__main__.TestWrapper) ... ok
testCall (__main__.TestWrapper) ... ok
testClassicStyleObject (__main__.TestWrapper) ... ok
testConstructor (__main__.TestWrapper) ... ok
testDate (__main__.TestWrapper) ... ok
testDestructor (__main__.TestWrapper) ... Segmentation fault
buffer@saiph ~/thug/src $ python thug.py -l testHTMLTableElement.html 
Segmentation fault
buffer@saiph ~/thug/src $ gdb python
GNU gdb (Gentoo 7.5 p1) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
(gdb) r thug.py -l testHTMLTableElement.html
Starting program: /usr/bin/python thug.py -l testHTMLTableElement.html
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
process 21075 is executing new program: /usr/bin/python2.7
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff7ff2700 (LWP 21078)]

Program received signal SIGSEGV, Segmentation fault.
0x00007fffeff565ac in boost::python::api::object_base::ptr() const () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
(gdb) info stack
#0  0x00007fffeff565ac in boost::python::api::object_base::ptr() const () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#1  0x00007fffeffbf9ae in ObjectTracer::~ObjectTracer() () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#2  0x00007fffeffc3cb1 in std::auto_ptr<ObjectTracer>::~auto_ptr() () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#3  0x00007fffeffbfc4c in ObjectTracer::WeakCallback(v8::Persistent<v8::Value>, 
void*) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#4  0x00007ffff0115922 in 
v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::Garba
geCollector, v8::internal::GCTracer*) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#5  0x00007ffff01385c5 in 
v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, 
v8::internal::GCTracer*) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#6  0x00007ffff0138da2 in 
v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, 
v8::internal::GarbageCollector, char const*, char const*) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#7  0x00007ffff013926b in v8::internal::Heap::CollectAllGarbage(int, char 
const*) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#8  0x00007fffeff866d1 in CEngine::CollectAllGarbage(bool) () from 
/usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#9  0x00007fffeffaba16 in _object* boost::python::detail::invoke<int, void 
(*)(bool), boost::python::arg_from_python<bool> 
>(boost::python::detail::invoke_tag_<true, false>, int const&, void (*&)(bool), 
boost::python::arg_from_python<bool>&) ()
   from /usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#10 0x00007fffeffa7da4 in boost::python::detail::caller_arity<1u>::impl<void 
(*)(bool), boost::python::default_call_policies, boost::mpl::vector2<void, 
bool> >::operator()(_object*, _object*) ()
   from /usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#11 0x00007fffeffa2fdf in 
boost::python::objects::caller_py_function_impl<boost::python::detail::caller<vo
id (*)(bool), boost::python::default_call_policies, boost::mpl::vector2<void, 
bool> > >::operator()(_object*, _object*) ()
   from /usr/lib64/python2.7/site-packages/PyV8-1.0_dev-py2.7-linux-x86_64.egg/_PyV8.so
#12 0x00007fffef6e879f in boost::python::objects::function::call(_object*, 
_object*) const () from /usr/lib64/libboost_python-2.7.so.1.52.0
[..]

Original comment by angelo.d...@gmail.com on 5 Feb 2013 at 8:39

GoogleCodeExporter commented 8 years ago 
I have refactor the living mapping after r496, please verify the issue with 
latest SVN trunk code, thanks

Original comment by flier...@gmail.com on 5 Feb 2013 at 12:10

GoogleCodeExporter commented 8 years ago 
Seems like the segfault disappeared but I'm seeing a huge regression in 
performances. I attached just an example but can reproduce it with almost every 
Thug test case.

SVN -498
buffer@saiph ~/thug/src $ time python thug.py -l 
../samples/misc/PluginDetect-0.7.9.html 
real    0m23.259s
user    0m23.088s
sys     0m0.152s

SVN -r478
buffer@saiph ~/thug/src $ time python thug.py -l 
../samples/misc/PluginDetect-0.7.9.html 
real    0m1.741s
user    0m1.651s
sys     0m0.059s

Original comment by angelo.d...@gmail.com on 5 Feb 2013 at 1:07

GoogleCodeExporter commented 8 years ago 
ok, it seems the object tracer introduce some efforts, maybe you could submit a 
new issue, and I will follow up it tomorrow :) thanks

Original comment by flier...@gmail.com on 5 Feb 2013 at 1:11

GoogleCodeExporter commented 8 years ago 
Ok will do. Thanks

Original comment by angelo.d...@gmail.com on 5 Feb 2013 at 1:11