Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expected FPS? #10

Closed
gkahn13 opened this issue Nov 7, 2017 · 26 comments
Closed

Expected FPS? #10

gkahn13 opened this issue Nov 7, 2017 · 26 comments
Assignees
Labels

Comments

@gkahn13
Copy link

gkahn13 commented Nov 7, 2017

I am trying to see how fast I can get CARLA to run with minimal settings. For only receiving small images, I can get about 10 fps, which is a bit slower than real-time. Is this the expected speed? Details to reproduce are below.

Server:

./CarlaUE4.sh /Game/Maps/Town01 -benchmark -fps=15 -carla-no-hud

Client:

$ python carla_example.py localhost 2000

CarlaSettings.ini

[CARLA/Server]
UseNetworking=true
SynchronousMode = true
SendNonPlayerAgentsInfo= false

[CARLA/LevelSettings]
NumberOfVehicles=10
NumberOfPedestrians=10
WeatherId=1

[CARLA/SceneCapture]
Cameras=RGB
ImageSizeX=160
ImageSizeY=120
CameraFOV=100
CameraPositionX=200
CameraPositionY=0
CameraPositionZ=140
CameraRotationPitch=-15.0
CameraRotationRoll=0
CameraRotationYaw=0


[CARLA/SceneCapture/RGB]
PostProcessing=SceneFinal
CameraPositionY=0
CameraRotationYaw=0

Machine specs:

  • Intel Core i7-6800K
  • 64 GB RAM
  • Nvidia GTX 1080
@nsubiron
Copy link
Collaborator

nsubiron commented Nov 7, 2017

Yes, unfortunately that's about as fast as it gets if you add cameras to the car. I'm getting similar FPS with similar settings.

The main performance hit are the cameras you attach to the car, just adding one, even with very small resolution, drops the frame-rate significantly (you can reach up to 30 fps without cameras). This is very inconvenient because I'm guessing almost every use of CARLA will require cameras attached to the car.

This is a known issue of these cameras (UE4's SceneCapture2D), and there are several forum threads on the issue but so far I haven't seen any solution.


Now if you really need to go as fast as possible, there are couple of things you can do, however this will not get you a significant improvement, perhaps a couple of FPS more

And if you don't need a great time resolution, you can also run it at a lower fixed frame-rate, -benchmark -fps=3, this won't improve the actual FPS but since the server renders less frames the in-game time will go much faster.

@NikolausDemmel
Copy link

I am getting around 3-5 fps with a Quadro K620 and one camera. I thought the card was too old, but it seems that even with more powerful models the expected speedup is not as substantial as I would have hoped. Thanks for the info, this is good to know (maybe you could convert this to a note in the docs at some point).

@felipecode
Copy link
Contributor

I would like to add that Town02 is like 50% faster to render than Town01.
To run town 02:
./CarlaUE4.sh /Game/Maps/Town02 -benchmark -fps=15

@Tak-Au
Copy link

Tak-Au commented Nov 17, 2017

Question what’s the min requirement to run this with one camera? My laptop has gtx 1060 on i7. I tried to run server and client on the same laptop and I keep getting drop after few sec on the road

@mesuvash
Copy link

mesuvash commented Nov 18, 2017

Got 15 FPS using Titan X Maxwell. Don't know why it's ridiculously slow.

@benibienz
Copy link

I get very low FPS even without a camera and tiny resolution. I think this issue goes beyond UE4's SceneCapture2D. Are there any plans to optimise the performance?

@nsubiron
Copy link
Collaborator

Without cameras we get more than 20 FPS on full-screen (1080GTX). This would be acceptable for most CARLA applications if worked with cameras. Speed optimisation is among our priorities, but we have very limited resources.

@benibienz
Copy link

OK, thanks for your response.

@WenchaoDing
Copy link

Hi,

I find that calling read data at Python client side is very time-consuming when I have multiple cameras. For my setup (6700K + 10800GTX), I typically need 110 ms to read data from 3 cameras, which is the bottleneck. Is there any way to improve the FPS at client side? Such as some parallelism.

@nsubiron
Copy link
Collaborator

nsubiron commented Dec 1, 2017

Hi @WenchaoDing,

Take into account that the read function waits for the server, if the server is slow this function will wait. We cannot go faster than the server.

Measuring inside the "read_data()" function gives me about 200ms to read the data from the socket + 5ms to process the data. The 200ms is mostly waiting for the server to produce the data.

There is a debugging trick that helps figuring this out, if you disable the synchronous mode, the server will print "Warning: No control received from the client this frame!" every time the client doesn't send the vehicle control on time, meaning the server is faster than the client. If it doesn't print that, then the client is fast enough.

We already considered making this function asynchronous in the client, but that adds quite some complexity to the API while not really speeding it up in most common uses. In case someone needs to parallelise reading the data, she/he will be better off adding this on top of our API to have more control of where to put the parsing of data specific for the case.

@WenchaoDing
Copy link

Hi @nsubiron ,

Thanks for your answer! I got it.

@tomchen1000
Copy link

If the issue is caused by UE4's SceneCapture2D, why Town02 is faster than Town01 (with one camera)?

@juaxix
Copy link
Contributor

juaxix commented Feb 26, 2018

Scenecapture2D is now using the renderqueue ,that, togehter with the settings in the optimization branch (DefaultEngine.ini) you will gain some fps. Also, the problem is to have an optimized scene, we are working on a simple scene to reduce the amount of objects to be rendered.

@simmates
Copy link

I would definitely want to use CARLA, but it gets slow if you add cameras and the suggestion is to remove cameras? This is a simulator for autonomous driving... I'd rather add cameras than remove them.

@juaxix
Copy link
Contributor

juaxix commented Mar 1, 2018

@simmates : It's normal that when you add a camera, any rendering program will slow down a little bit, anyway, we are not saying that you need to remove them, in fact, we are optimizing this together with EPIC team, using the special render code in ASceneCapture2D in the render queue of the engine. A lot of new optimizations will come with the new update (0.8.0) ,you can watch the progress here
Thanks

@bhairavmehta95
Copy link

What is the expected FPS of the Optimizations branch that was just pulled into the master branch? Haven't had a chance to check so I figured someone on this thread might have that answer handy.

@nsubiron
Copy link
Collaborator

We are working on a more detailed benchmark of the speed, but here some preliminary results.

All of these on a GTX1080 on Ubuntu 16.04 on a typical use on Town01 with 20 vehicles and 30 pedestrians.

Scenario 0.7.1 (prev. version) 0.8.0 Epic mode 0.8.0 Low mode
no cameras 22 FPS 26 FPS 60 FPS
one camera 9 FPS 13 FPS 45 FPS
three cameras 4 FPS 6 FPS 15 FPS

Still a lot of room for improvement, but definitively much better than previous version 😄

@joethompson1961
Copy link

What is the difference between Epic and Low Mode?

@nsubiron
Copy link
Collaborator

@joethompson1961 Epic and Low modes refer to the graphics quality of render, you can see an example in this video https://youtu.be/S_XbKHC_hN0?t=1m4s

@germanros1987
Copy link
Member

Should we close this issue?

@nsubiron
Copy link
Collaborator

I guess most of the things here are no longer relevant with the latest improvements. We'll keep opening more issues with specific actions to improve performance.

@SummerHelen
Copy link

How can I check the fps in the simulation process?

@tanghui0102
Copy link

Hello!
I met one problem:
Low FPS when I run manual_control_sreeringwheel.py in ubuntu 16.04,and the driving wheel is Logitech G920
system:Ubuntu 16.04
gpu:GTX1060
version:CARLA 0.9.5

Description:
One map of carla is running at other conputer,the Logitech G920 driving force wheel is plugged into my computer ,when I run manual_control_steeringwheel.py,the FPS of Sever and Client is so low that the car's running is not smooth enough.FPS of them is respectively about 16,16.
I am full of confusion.Can anyone give some suggestion?Thanks in advance.

image

@soulslicer
Copy link

We are working on a more detailed benchmark of the speed, but here some preliminary results.

All of these on a GTX1080 on Ubuntu 16.04 on a typical use on Town01 with 20 vehicles and 30 pedestrians.

Scenario 0.7.1 (prev. version) 0.8.0 Epic mode 0.8.0 Low mode
no cameras 22 FPS 26 FPS 60 FPS
one camera 9 FPS 13 FPS 45 FPS
three cameras 4 FPS 6 FPS 15 FPS
Still a lot of room for improvement, but definitively much better than previous version

If I have a better GPU will this improve?

@MasterTigress
Copy link

We are working on a more detailed benchmark of the speed, but here some preliminary results.

All of these on a GTX1080 on Ubuntu 16.04 on a typical use on Town01 with 20 vehicles and 30 pedestrians.

Scenario 0.7.1 (prev. version) 0.8.0 Epic mode 0.8.0 Low mode
no cameras 22 FPS 26 FPS 60 FPS
one camera 9 FPS 13 FPS 45 FPS
three cameras 4 FPS 6 FPS 15 FPS
Still a lot of room for improvement, but definitively much better than previous version 😄

How can I run one camera to achieve 45 FPS, what does no camera mean ? Are there sample code for "one camera" and "no camera"? Can you please share

@MasterTigress
Copy link

I tried a lot to look around for one camera code but couldn't find it. I tried developing one myself but still unable to achieve the fps listed for one camera, can someone please share code of one camera?

wentasah added a commit to wentasah/carla that referenced this issue Aug 16, 2023
When using CARLA with Python 3.10, I'm getting a segfault in
GetAvailableMaps. The problem disappears when PyList manipulation does
not happen with GIL unlocked, as done in this commit.

The initial part of crash backtrace (from GDB) is below:

    Program terminated with signal SIGSEGV, Segmentation fault.

    warning: Section `.reg-xstate/49253' in core file too small.
    #0  _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:117
    117	   return tstate->interp;
    [Current thread is 1 (Thread 0x7fe6fe48f740 (LWP 49253))]
    (gdb) bt
    #0  _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:117
    matejm42#1  get_list_state () at Objects/listobject.c:26
    carla-simulator#2  PyList_New (size=0) at Objects/listobject.c:159
    carla-simulator#3  0x00007fe6fdc0dab0 in boost::python::detail::list_base::list_base() () from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    carla-simulator#4  0x00007fe6ef9ecfc4 in boost::python::list::list (this=0x7ffd8a8aae28) at include/boost/python/list.hpp:61
    carla-simulator#5  GetAvailableMaps (self=...) at source/libcarla/Client.cpp:26
    carla-simulator#6  0x00007fe6efb6a8fe in boost::python::detail::invoke<boost::python::to_python_value<boost::python::list const&>, boost::python::list (*)(carla::client::Client const&), boost::python::arg_from_python<carla::client::Client const&> > (rc=..., f=<optimized out>, ac0=...)
        at include/boost/python/detail/invoke.hpp:73
    carla-simulator#7  boost::python::detail::caller_arity<1u>::impl<boost::python::list (*)(carla::client::Client const&), boost::python::default_call_policies, boost::mpl::vector2<boost::python::list, carla::client::Client const&> >::operator() (args_=<optimized out>, this=<optimized out>)
        at include/boost/python/detail/caller.hpp:233
    carla-simulator#8  boost::python::objects::caller_py_function_impl<boost::python::detail::caller<boost::python::list (*)(carla::client::Client const&), boost::python::default_call_policies, boost::mpl::vector2<boost::python::list, carla::client::Client const&> > >::operator() (
        this=<optimized out>, args=<optimized out>, kw=<optimized out>) at include/boost/python/object/py_function.hpp:38
    carla-simulator#9  0x00007fe6fdc1b4dd in boost::python::objects::function::call(_object*, _object*) const () from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    carla-simulator#10 0x00007fe6fdc1b6a8 in boost::detail::function::void_function_ref_invoker0<boost::python::objects::(anonymous namespace)::bind_return, void>::invoke(boost::detail::function::function_buffer&) ()
       from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    ...
wentasah added a commit to wentasah/carla that referenced this issue Sep 3, 2023
When using CARLA with Python 3.10, I'm getting a segfault in
GetAvailableMaps. The problem disappears when PyList manipulation does
not happen with GIL unlocked, as done in this commit.

The initial part of crash backtrace (from GDB) is below:

    Program terminated with signal SIGSEGV, Segmentation fault.

    warning: Section `.reg-xstate/49253' in core file too small.
    #0  _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:117
    117	   return tstate->interp;
    [Current thread is 1 (Thread 0x7fe6fe48f740 (LWP 49253))]
    (gdb) bt
    #0  _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:117
    matejm42#1  get_list_state () at Objects/listobject.c:26
    carla-simulator#2  PyList_New (size=0) at Objects/listobject.c:159
    carla-simulator#3  0x00007fe6fdc0dab0 in boost::python::detail::list_base::list_base() () from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    carla-simulator#4  0x00007fe6ef9ecfc4 in boost::python::list::list (this=0x7ffd8a8aae28) at include/boost/python/list.hpp:61
    carla-simulator#5  GetAvailableMaps (self=...) at source/libcarla/Client.cpp:26
    carla-simulator#6  0x00007fe6efb6a8fe in boost::python::detail::invoke<boost::python::to_python_value<boost::python::list const&>, boost::python::list (*)(carla::client::Client const&), boost::python::arg_from_python<carla::client::Client const&> > (rc=..., f=<optimized out>, ac0=...)
        at include/boost/python/detail/invoke.hpp:73
    carla-simulator#7  boost::python::detail::caller_arity<1u>::impl<boost::python::list (*)(carla::client::Client const&), boost::python::default_call_policies, boost::mpl::vector2<boost::python::list, carla::client::Client const&> >::operator() (args_=<optimized out>, this=<optimized out>)
        at include/boost/python/detail/caller.hpp:233
    carla-simulator#8  boost::python::objects::caller_py_function_impl<boost::python::detail::caller<boost::python::list (*)(carla::client::Client const&), boost::python::default_call_policies, boost::mpl::vector2<boost::python::list, carla::client::Client const&> > >::operator() (
        this=<optimized out>, args=<optimized out>, kw=<optimized out>) at include/boost/python/object/py_function.hpp:38
    carla-simulator#9  0x00007fe6fdc1b4dd in boost::python::objects::function::call(_object*, _object*) const () from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    carla-simulator#10 0x00007fe6fdc1b6a8 in boost::detail::function::void_function_ref_invoker0<boost::python::objects::(anonymous namespace)::bind_return, void>::invoke(boost::detail::function::function_buffer&) ()
       from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    ...
wentasah added a commit to wentasah/carla that referenced this issue Sep 25, 2023
When I run generate_traffic.py under Python 3.10, I get a segfault at
line:

    loc = world.get_random_location_from_navigation()

The backtrace from gdb looks like this:

    #0  0x00007f04552ad7e7 in new_threadstate () from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/libpython3.10.so.1.0
    matejm42#1  0x00007f04552adaa1 in PyGILState_Ensure () from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/libpython3.10.so.1.0
    carla-simulator#2  0x00007f040afd4f32 in std::_Function_handler<void (carla::client::WorldSnapshot), MakeCallback(boost::python::api::object)::{lambda(auto:1)matejm42#1}>::_M_invoke(std::_Any_data const&, carla::client::WorldSnapshot&&) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    carla-simulator#3  0x00007f040b1d4ab1 in carla::client::detail::CallbackList<carla::client::WorldSnapshot>::Call(carla::client::WorldSnapshot) const () from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    carla-simulator#4  0x00007f040b1d424a in std::_Function_handler<void (carla::Buffer), carla::client::detail::Episode::Listen()::{lambda(auto:1)matejm42#1}>::_M_invoke(std::_Any_data const&, carla::Buffer&&) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    carla-simulator#5  0x00007f040b23fc41 in boost::asio::detail::completion_handler<boost::asio::detail::binder0<carla::streaming::detail::tcp::Client::ReadData()::{lambda()matejm42#1}::operator()() const::{lambda(boost::system::error_code, unsigned long)matejm42#1}::operator()(boost::system::error_code, unsigned long) const::{lambda()matejm42#1}>, boost::asio::io_context::basic_executor_type<std::allocator<void>, 0ul> >::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    carla-simulator#6  0x00007f040b24ae85 in boost::asio::detail::strand_service::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    carla-simulator#7  0x00007f040b1a94f5 in boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    carla-simulator#8  0x00007f040b199351 in boost::asio::detail::scheduler::run(boost::system::error_code&) [clone .isra.0] () from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    carla-simulator#9  0x00007f040b1ac1cb in std::thread::_State_impl<std::thread::_Invoker<std::tuple<carla::ThreadPool::AsyncRun(unsigned long)::{lambda()matejm42#1}> > >::_M_run() ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    carla-simulator#10 0x00007f040bce05c3 in execute_native_thread_routine () from /nix/store/2fpmbk0g0ggm9zq89af7phvvvv8dnm7n-gcc-12.3.0-lib/lib/libstdc++.so.6
    carla-simulator#11 0x00007f045509fdd4 in start_thread () from /nix/store/1x4ijm9r1a88qk7zcmbbfza324gx1aac-glibc-2.37-8/lib/libc.so.6
    carla-simulator#12 0x00007f04551219b0 in clone3 () from /nix/store/1x4ijm9r1a88qk7zcmbbfza324gx1aac-glibc-2.37-8/lib/libc.so.6

It turns out that its caused by releasing GIL for too long. We fix it
by releasing the GIL only for the actual libcarla call and
constructing Python objects with GIL locked.
bernatx added a commit that referenced this issue Oct 27, 2023
* PythonAPI: Fix segfault in GetAvailableMaps

When using CARLA with Python 3.10, I'm getting a segfault in
GetAvailableMaps. The problem disappears when PyList manipulation does
not happen with GIL unlocked, as done in this commit.

The initial part of crash backtrace (from GDB) is below:

    Program terminated with signal SIGSEGV, Segmentation fault.

    warning: Section `.reg-xstate/49253' in core file too small.
    #0  _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:117
    117	   return tstate->interp;
    [Current thread is 1 (Thread 0x7fe6fe48f740 (LWP 49253))]
    (gdb) bt
    #0  _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:117
    #1  get_list_state () at Objects/listobject.c:26
    #2  PyList_New (size=0) at Objects/listobject.c:159
    #3  0x00007fe6fdc0dab0 in boost::python::detail::list_base::list_base() () from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    #4  0x00007fe6ef9ecfc4 in boost::python::list::list (this=0x7ffd8a8aae28) at include/boost/python/list.hpp:61
    #5  GetAvailableMaps (self=...) at source/libcarla/Client.cpp:26
    #6  0x00007fe6efb6a8fe in boost::python::detail::invoke<boost::python::to_python_value<boost::python::list const&>, boost::python::list (*)(carla::client::Client const&), boost::python::arg_from_python<carla::client::Client const&> > (rc=..., f=<optimized out>, ac0=...)
        at include/boost/python/detail/invoke.hpp:73
    #7  boost::python::detail::caller_arity<1u>::impl<boost::python::list (*)(carla::client::Client const&), boost::python::default_call_policies, boost::mpl::vector2<boost::python::list, carla::client::Client const&> >::operator() (args_=<optimized out>, this=<optimized out>)
        at include/boost/python/detail/caller.hpp:233
    #8  boost::python::objects::caller_py_function_impl<boost::python::detail::caller<boost::python::list (*)(carla::client::Client const&), boost::python::default_call_policies, boost::mpl::vector2<boost::python::list, carla::client::Client const&> > >::operator() (
        this=<optimized out>, args=<optimized out>, kw=<optimized out>) at include/boost/python/object/py_function.hpp:38
    #9  0x00007fe6fdc1b4dd in boost::python::objects::function::call(_object*, _object*) const () from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    #10 0x00007fe6fdc1b6a8 in boost::detail::function::void_function_ref_invoker0<boost::python::objects::(anonymous namespace)::bind_return, void>::invoke(boost::detail::function::function_buffer&) ()
       from /nix/store/c95f3nrkz3sflvycihyw1c8q4nk47p4m-boost-1.79.0/lib/libboost_python310.so.1.79.0
    ...

* PythonAPI: Fix segfault in get_random_location_from_navigation()

When I run generate_traffic.py under Python 3.10, I get a segfault at
line:

    loc = world.get_random_location_from_navigation()

The backtrace from gdb looks like this:

    #0  0x00007f04552ad7e7 in new_threadstate () from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/libpython3.10.so.1.0
    #1  0x00007f04552adaa1 in PyGILState_Ensure () from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/libpython3.10.so.1.0
    #2  0x00007f040afd4f32 in std::_Function_handler<void (carla::client::WorldSnapshot), MakeCallback(boost::python::api::object)::{lambda(auto:1)#1}>::_M_invoke(std::_Any_data const&, carla::client::WorldSnapshot&&) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    #3  0x00007f040b1d4ab1 in carla::client::detail::CallbackList<carla::client::WorldSnapshot>::Call(carla::client::WorldSnapshot) const () from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    #4  0x00007f040b1d424a in std::_Function_handler<void (carla::Buffer), carla::client::detail::Episode::Listen()::{lambda(auto:1)#1}>::_M_invoke(std::_Any_data const&, carla::Buffer&&) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    #5  0x00007f040b23fc41 in boost::asio::detail::completion_handler<boost::asio::detail::binder0<carla::streaming::detail::tcp::Client::ReadData()::{lambda()#1}::operator()() const::{lambda(boost::system::error_code, unsigned long)#1}::operator()(boost::system::error_code, unsigned long) const::{lambda()#1}>, boost::asio::io_context::basic_executor_type<std::allocator<void>, 0ul> >::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    #6  0x00007f040b24ae85 in boost::asio::detail::strand_service::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    #7  0x00007f040b1a94f5 in boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&) ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    #8  0x00007f040b199351 in boost::asio::detail::scheduler::run(boost::system::error_code&) [clone .isra.0] () from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    #9  0x00007f040b1ac1cb in std::thread::_State_impl<std::thread::_Invoker<std::tuple<carla::ThreadPool::AsyncRun(unsigned long)::{lambda()#1}> > >::_M_run() ()
       from /nix/store/zqj9irpw63pal9r4671p1gjd9jiw5sid-ros-env/lib/python3.10/site-packages/carla/libcarla.cpython-310-x86_64-linux-gnu.so
    #10 0x00007f040bce05c3 in execute_native_thread_routine () from /nix/store/2fpmbk0g0ggm9zq89af7phvvvv8dnm7n-gcc-12.3.0-lib/lib/libstdc++.so.6
    #11 0x00007f045509fdd4 in start_thread () from /nix/store/1x4ijm9r1a88qk7zcmbbfza324gx1aac-glibc-2.37-8/lib/libc.so.6
    #12 0x00007f04551219b0 in clone3 () from /nix/store/1x4ijm9r1a88qk7zcmbbfza324gx1aac-glibc-2.37-8/lib/libc.so.6

It turns out that its caused by releasing GIL for too long. We fix it
by releasing the GIL only for the actual libcarla call and
constructing Python objects with GIL locked.

---------

Co-authored-by: bernat <bernatx@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests