| Subject: | Re: [yast-devel] yast-python-bindings issues |
|---|---|
| Date: | Mon, 9 Oct 2017 09:22:43 -0600 |
| From: | David Mulder <dmulder@suse.com> |
| To: | Josef Reidinger <jreidinger@suse.cz> |
If you install my python bindings, it's easy to reproduce. To install the bindings, first install these dependencies: yast2-ycp-ui-bindings autoconf-archive swig yast2-core-devel Clone the repo: git clone https://github.com/dmulder/yast-python-bindings2.git Build/install: cd yast-python-bindings2 autoreconf -if ./configure make && sudo make install Then you'll need to add libpy2UI to your path: LD_LIBRARY_PATH=$LD_LIBRARY_PATHPATH:/usr/lib64/YaST2/plugin Then to reproduce the failure, run `python` to open the interpreter, and run: import yast yast.init_ui('ncurses') yast.Wizard.CreateDialog() yast.UI.CloseDialog() It segfaults and generates a core dump. On 10/09/2017 09:08 AM, Josef Reidinger wrote: > V Mon, 9 Oct 2017 08:54:35 -0600 > David Mulder <dmulder@suse.com> napsáno: > >>> Problem is that you do not use Yast component system. In general all >>> yast modules is attached to component system and you can call it >>> with it. Old python bindings implement it properly with >>> >>> https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc >> I added in use of the yast component system, for calling into the >> Wizard class in the ruby code (branch ruby_bind on the same project). >> This works, but there is now blatant stack corruption (crashing, UI >> artifacts, etc). >> Here is the crash at shutdown: >> >> #0 0x00007f7a704ad855 in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #1 0x00007f7a70389c4b in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #2 0x00007f7a7044029e in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #3 <signal handler called> >> #4 0x0000000000000000 in ?? () >> #5 0x00007f7a732e3643 in YUIComponent::result(YCPValue const&) () >> from /usr/lib64/YaST2/plugin/libpy2UI.so.2 > This crash looks like somewhere in ycp-ui-bindings. It looks like null > pointer access. we probably need exact location in where in result it > failed. Can you add there some trivial example of such crash so I can > try it myself with all debug packages? > > Josef > >> #6 0x00007f7a6c58b4f0 in ?? () from >> /usr/lib64/ruby/vendor_ruby/2.2.0/x86_64-linux-gnu/yastx.so >> #7 0x00007f7a70496b4d in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #8 0x00007f7a704a78ce in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #9 0x00007f7a7049b3eb in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #10 0x00007f7a704a1224 in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #11 0x00007f7a704a5ffc in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #12 0x00007f7a704a6323 in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #13 0x00007f7a704a63f8 in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #14 0x00007f7a7039573c in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #15 0x00007f7a704a27e3 in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #16 0x00007f7a704a3a92 in ?? () from /usr/lib64/libruby2.2.so.2.2 >> #17 0x00007f7a704a8bf0 in rb_eval_cmd () >> from /usr/lib64/libruby2.2.so.2.2 #18 0x00007f7a703a0003 in ?? () >> from /usr/lib64/libruby2.2.so.2.2 #19 0x00007f7a7038f55d in >> rb_protect () from /usr/lib64/libruby2.2.so.2.2 #20 >> 0x00007f7a703a1376 in ?? () from /usr/lib64/libruby2.2.so.2.2 #21 >> 0x00007f7a703ab3d4 in rb_gc_call_finalizer_at_exit () >> from /usr/lib64/libruby2.2.so.2.2 #22 0x00007f7a709bb80d in >> YRuby::~YRuby() () from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so >> #23 0x00007f7a709bb8ee in YRuby::destroy() () from >> /usr/lib64/YaST2/plugin/libpy2lang_ruby.so >> #24 0x00007f7a709b66cd in Y2RubyComponent::~Y2RubyComponent() () >> from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so >> #25 0x00007f7a709b67c9 in Y2RubyComponent::~Y2RubyComponent() () >> from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so >> #26 0x00007f7a709b5aa1 in Y2CCRuby::~Y2CCRuby() () from >> /usr/lib64/YaST2/plugin/libpy2lang_ruby.so >> #27 0x00007f7a84b4e638 in __run_exit_handlers () from /lib64/libc.so.6 >> #28 0x00007f7a84b4e68a in exit () from /lib64/libc.so.6 >> #29 0x00007f7a84b37471 in __libc_start_main () from /lib64/libc.so.6 >> #30 0x000055950bf6c7fa in _start () >> >> Any thoughts? >>> which adds to python ability to call rest of component system. >>> import is finding module like >>> >>> https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc#L107 >>> >>> and call it with >>> >>> https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc#L1238 >>> >>> so to call UI methods you need to import module "UI" and then with >>> that call use method you want from UI namespace. >>> >>> >>>>> 2. yast.py is basically reimplementation of yast stuff in python. >>>>> I am not sure if it is right way, as anything you will need you >>>>> have to reimplement >>>> Yes, the yast.py code is wrong. I'm trying to think of a good way >>>> to use the ruby Wizard code, etc. You mention there is a way to be >>>> able to call functions between yast modules? >>> yes, as I describe above. >>> >>>>> 3. your modules is not possible to call from rest of YaST. For >>>>> ycp, perl and ruby it is possible to call it from each other. >>>>> >>>>> So in short. Your approach is more like wrapper for c++ parts >>>>> ( currently only UI ) and rewrite for rest. >>>>> >>>>> In general if you need only UI from YaST, then I suggest to use >>>>> direct approach and use libyui python bindings - >>>>> https://github.com/libyui/libyui-bindings . But as I said this >>>>> approach prevent you to use any part written in ruby and also rest >>>>> of YaST cannot call your methods. >>>>> >>>>> It miss some layer from ycp-ui-bindings, but provide all needed to >>>>> build UI. >>>>> >>>>> Josef >>>>> -- David Mulder SUSE Labs Software Engineer - Samba dmulder@suse.com SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)