Error Signal 11

[gthd]

Hi Stephen,

I receive error signal 11 whith the following traceback:
Error: signal 11:

/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libv_rep.so.1(_Z11_segHandleri+0x2b)[0x7f3c5d5d00eb]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7f3c7efdbf20]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Core.so.5(_ZN6QMutex4lockEv+0x15)[0x7f3c5b0ca0b5]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(+0x379f7e)[0x7f3c5c0eff7e]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(+0x37183f)[0x7f3c5c0e783f]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(_ZN18QRasterPaintEngine11updateBrushERK6QBrush+0x87)[0x7f3c5c0eacd7]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(_ZN18QRasterPaintEngine8fillRectERK6QRectFRK6QBrush+0x2a)[0x7f3c5c0eb7aa]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(_ZN8QPainter8fillRectERK5QRectRK6QBrush+0xc5)[0x7f3c5c0fe5d5]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Widgets.so.5(_ZNK12QFusionStyle11drawControlEN6QStyle14ControlElementEPK12QStyleOptionP8QPainterPK7QWidget+0x2da7)[0x7f3c5c7cdb67]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Widgets.so.5(+0x208c89)[0x7f3c5c7a4c89]
QMutex: destroying locked mutex

Thank you,
Georgios

[stepjam]

Hi.
Could you try: sudo apt-get install qt5-default

If that doesn't work, could you give me some more info about when you get this error? And do you still get it when launching V-REP without using PyRep?

[gthd]

Hi Stephen,

Thank you for your quick reply.
The error occurs once I launch the .ttt file:
pr = PyRep()
pr.launch(SCENE_FILE, headless=False)

If I don't use PyRep then I don't get this error.

[gthd]

Is it possible that is related with the fact that I am using Wayland ?

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway

But I don't get any error when using the V-REP without PyRep.

If it is related do you know how to fix this warning.

Thank you

[stepjam]

Is it possible that is related with the fact that I am using Wayland ?

Yes it could be. Can you tell me the output of echo $QT_QPA_PLATFORM_PLUGIN_PATH please?

[gthd]

/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04

[stepjam]

OK. I'm not sure what is happening.
Could you try running PyRep in blocking mode and see if that launches?

pr = PyRep()
pr.launch(blocking=True, headless=False)

[gthd]

I get following message:

File "/home/george/.local/lib/python3.6/site-packages/pyrep/pyrep.py", line 162, in start
raise PyRepError('V-REP has not been launched. Call launch first.')
pyrep.errors.PyRepError: V-REP has not been launched. Call launch first.
QObject::~QObject: Timers cannot be stopped from another thread

[stepjam]

That can't be right. When launching pyrep in blocking mode, the launch function does not return, so how are you calling start?

[stepjam]

Everything is running on one thread/process, right?

[gthd]

pr = PyRep()
print('hello2')
pr.launch(SCENE_FILE, blocking=True, headless=False)
print('hello1')
pr.start()

When running the above code, then it is stuck on the 3rd line. However, when closing the v-rep manually, then I get the above posted message in the terminal.

Can you please tell me how do I check whether it is running on one thread ?

[stepjam]

When you launch in blocking mode, it is as if you are launching V-REP from the terminal as normal. So calling start after closing in 'blocking' mode doesn't make sense (as you have already killed V-REP).

So after running launch (in blocking mode), V-REP appears with no errors?

[gthd]

Yes V-REP appears with no errors, however some methods that are later defined, for example add object to the scene, are not getting executed,

[stepjam]

however some methods that are later defined, for example add object to the scene, are not getting executed

Yes that is expected behaviour when running in blocking mode. The function will never return (until you close V-REP).
Your error is very strange in that case; I would have expected it to crash in the same way (with the error signal 11).

Going back to running in non-blocking mode: you are certain that it is crashing during the call to launch?

[gthd]

well I run the below segment of code:
SCENE_FILE = join(dirname(abspath(file)), 'my_scene3.ttt')
pr = PyRep()
pr.launch(SCENE_FILE, headless=False)

And at the traceback I have either:
QObject::~QObject: Timers cannot be stopped from another thread
QMutex: destroying locked mutex

or

Error: signal 11:

/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libv_rep.so.1(_Z11_segHandleri+0x2b)[0x7ff87b2810eb]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7ff89cc8cf20]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Core.so.5(_ZN6QMutex4lockEv+0x15)[0x7ff878d7b0b5]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(+0x379f7e)[0x7ff879da0f7e]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(+0x37183f)[0x7ff879d9883f]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(_ZN18QRasterPaintEngine11updateBrushERK6QBrush+0x87)[0x7ff879d9bcd7]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(_ZN18QRasterPaintEngine8fillRectERK6QRectFRK6QBrush+0x2a)[0x7ff879d9c7aa]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Gui.so.5(_ZN8QPainter8fillRectERK5QRectRK6QBrush+0xc5)[0x7ff879daf5d5]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Widgets.so.5(_ZNK12QFusionStyle18drawComplexControlEN6QStyle14ComplexControlEPK19QStyleOptionComplexP8QPainterPK7QWidget+0x31a7)[0x7ff87a488ea7]
/home/george/Desktop/V-REP_PRO_EDU_V3_6_2_Ubuntu18_04/libQt5Widgets.so.5(+0x202bdb)[0x7ff87a44fbdb]
QMutex: destroying locked mutex

I am not sure why there are 2 different error messages but I am sure that is provoked during the launch.

[stepjam]

Yes, but if that is all you have in your Python file then the behaviour is undefined. You are opening PyRep and then the python program is quitting because it reached the end of the program. Each launch should eventually be followed by a shutdown.
Have you tried running the example in the examples folder?