pypy on ubuntu segfault

[stuaxo]

This is an Ubuntu bug, not pgi - but maybe pgi could workaround it ?

Using pypy on ubuntu and import Gtk segfaults

>>>> import pgi
>>>> from pgi.repository import Gtk
Segmentation fault

IRCC* this happens because of a bug Ubuntu introduced to Gtk that means it is not re-enterant, I wonder if some caching could be done to avoid triggering this ?

*I need to go on the net and try and dig out more details of this.

[lazka]

Which Ubuntu version?

[stuaxo]

14.10 (Utopic)

[stuaxo]

14.10 64 bit.

I think there is an Ubuntu bug somewhere, I need to find it though ..

Here is the stacktrace from gdb

GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs
Copyright (C) 2014 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/data/home/stu/.virtualenvs/shoebot-pgi-pypy/bin/pypy...(no debugging symbols found)...done.
Starting program: /mnt/data/home/stu/.virtualenvs/shoebot-pgi-pypy/bin/pypy /mnt/data/home/stu/.virtualenvs/shoebot-pgi-pypy/bin/sbot -w examples/animation/hypnoval.bot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff51d6700 (LWP 18680)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff51d6700 (LWP 18680)]
0x00007fffe8aff86e in std::_Rb_tree<std::string, std::pair<std::string const, std::pair<void const*, int> >, std::_Select1st<std::pair<std::string const, std::pair<void const*, int> > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<void const*, int> > > >::_M_get_insert_unique_pos(std::string const&) ()
   from /usr/lib/x86_64-linux-gnu/libprotobuf.so.8
(gdb) bt
#0  0x00007fffe8aff86e in std::_Rb_tree<std::string, std::pair<std::string const, std::pair<void const*, int> >, std::_Select1st<std::pair<std::string const, std::pair<void const*, int> > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<void const*, int> > > >::_M_get_insert_unique_pos(std::string const&) ()
   from /usr/lib/x86_64-linux-gnu/libprotobuf.so.8
#1  0x00007fffe8affad1 in std::_Rb_tree<std::string, std::pair<std::string const, std::pair<void const*, int> >, std::_Select1st<std::pair<std::string const, std::pair<void const*, int> > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<void const*, int> > > >::_M_insert_unique(std::pair<std::string const, std::pair<void const*, int> > const&) () from /usr/lib/x86_64-linux-gnu/libprotobuf.so.8
#2  0x00007fffe8b00864 in google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void const*, int> >::AddFile(google::protobuf::FileDescriptorProto const&, std::pair<void const*, int>) () from /usr/lib/x86_64-linux-gnu/libprotobuf.so.8
#3  0x00007fffe8afd10b in google::protobuf::EncodedDescriptorDatabase::Add(void const*, int) () from /usr/lib/x86_64-linux-gnu/libprotobuf.so.8
#4  0x00007fffe8ac440a in google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) () from /usr/lib/x86_64-linux-gnu/libprotobuf.so.8
#5  0x00007fffe8f96a62 in mir::protobuf::wire::protobuf_AddDesc_mir_5fprotobuf_5fwire_2eproto() () from /usr/lib/x86_64-linux-gnu/libmircommon.so.2
#6  0x00007ffff7dea13a in call_init (l=<optimised out>, argc=argc@entry=4, argv=argv@entry=0x7fffffffdb68, env=env@entry=0x7fffffffdb90) at dl-init.c:78
#7  0x00007ffff7dea223 in call_init (env=<optimised out>, argv=<optimised out>, argc=<optimised out>, l=<optimised out>) at dl-init.c:36
#8  _dl_init (main_map=main_map@entry=0x7ffff08186a0, argc=4, argv=0x7fffffffdb68, env=0x7fffffffdb90) at dl-init.c:126
#9  0x00007ffff7deec6e in dl_open_worker (a=a@entry=0x7ffff51d1fc8) at dl-open.c:577
#10 0x00007ffff7de9ff4 in _dl_catch_error (objname=objname@entry=0x7ffff51d1fb8, errstring=errstring@entry=0x7ffff51d1fc0, mallocedp=mallocedp@entry=0x7ffff51d1fb0, 
    operate=operate@entry=0x7ffff7dee990 <dl_open_worker>, args=args@entry=0x7ffff51d1fc8) at dl-error.c:187
#11 0x00007ffff7dee3ab in _dl_open (file=0x7ffff1506c10 "libgtk-3.so.0", mode=-2147483391, caller_dlopen=<optimised out>, nsid=-2, argc=4, argv=0x7fffffffdb68, 
    env=0x7fffffffdb90) at dl-open.c:661
#12 0x00007ffff7bd702b in dlopen_doit (a=a@entry=0x7ffff51d21e0) at dlopen.c:66
#13 0x00007ffff7de9ff4 in _dl_catch_error (objname=0x7ffff02a4500, errstring=0x7ffff02a4508, mallocedp=0x7ffff02a44f8, operate=0x7ffff7bd6fd0 <dlopen_doit>, 
    args=0x7ffff51d21e0) at dl-error.c:187
#14 0x00007ffff7bd762d in _dlerror_run (operate=operate@entry=0x7ffff7bd6fd0 <dlopen_doit>, args=args@entry=0x7ffff51d21e0) at dlerror.c:163
#15 0x00007ffff7bd70c1 in __dlopen (file=<optimised out>, mode=<optimised out>) at dlopen.c:87
#16 0x00007fffed4ac942 in g_module_open () from /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
#17 0x00007fffed6c2775 in g_typelib_symbol () from /usr/lib/libgirepository-1.0.so.1
#18 0x00007fffed6bcaf7 in g_registered_type_info_get_g_type () from /usr/lib/libgirepository-1.0.so.1
#19 0x00007ffff65f8afe in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#20 0x00007ffff65f8568 in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#21 0x00000000010a169c in ?? ()
#22 0x0000000001f8b3c5 in ?? ()
#23 0x0000000001d4bfcc in ?? ()
#24 0x0000000001d4de13 in ?? ()
#25 0x00000000013cfd9e in ?? ()
#26 0x00000000013cb5bb in ?? ()
#27 0x0000000001296996 in ?? ()
#28 0x000000000128ddc2 in ?? ()
#29 0x00000000012bfb03 in ?? ()
#30 0x00000000012c45e8 in ?? ()
#31 0x00000000012c70b5 in ?? ()
#32 0x000000000175a48e in ?? ()
#33 0x0000000001c26221 in ?? ()```

[lazka]

pgi is far from ready for general usage, so it might as well that we do something stupid.

Since there are references to the mir API in the stacktrace: are you testing the new unity/mir/xmir?

[stuaxo]

No, I use gnome-shell, I haven't done anything to install mir stuff.

[stuaxo]

Have retested this on Ubuntu 15.10 and it seems OK now, I'll re-open if I see it again. (Tested on python 2.7.10 in a virtualenv and in pypy in a virtuaenv).