Issue #2531 resolved
Samuel Ong created an issue

Hi guys, I have recently updated my MacOS to Mojave from High Sierra, running Gazebo 9.
Gazebo seems to be working but the display is really off, and I have no idea how I should fix it. Any advice would be great!! Resizing doesn't help at all, and please let me know what information do you need me to provide.

Thanks in advance.

Screenshot 2018-10-01 at 8.49.30 AM.png

Comments (22)

  1. Frank Carey

    I can confirm that while it took over 3 hrs to compile qt via homebrew, it did fix the issue immediately (no reboot or reinstall or anything required)

  2. Steven Peters

    I'm still running high sierra on my primary mac machine, but I have confirmed the error on a mac mini running mojave.

    @Frank Carey great news that it is fixed in qt 5.12, but 5.12 does not yet have a release candidate; it is still on beta3:

    So I would guess it will be at least a few weeks before this fix is released, possibly more than a month.

    If the unreleased patch that fixes this can be identified, we could try submitting it to homebrew as a patch on the current release of 5.11.2. It might not be accepted, but it could be worth a shot.

  3. Steven Peters

    5.12.0 has been released; I'm testing it now and will submit a homebrew pull request unless someone else beats me to it

  4. Steven Peters

    well, qt 5.12.0 is now released into homebrew and bottles are available, but gazebo on mojave still looks broken to me, though it doesn't look scaled; it just looks like nothing is appearing in the 3d window.

    I'll ask @Ian Chen to take a look on one of our test machines.

  5. Theppasith Nisitsukcharoen

    Same to me as well , After using QT 5.12 the scale rendering issue seems to disappear but there's nothing in 3d windows. It's just a grey screen with no ground plane and sun.

    and when you click the sun in the object window on the left , app crashed.

  6. Steven Peters

    Ooh, thanks for the tip! I've collected a backtrace from gzclient:

    an excerpt that implicates gazebo::rendering::Light::FillMsg, called by gazebo::gui::ModelListWidget::OnSetSelectedEntity:

    2018-12-11 10:47:17.248610-0800 gzclient[14108:3462293] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=14108
    2018-12-11 10:47:17.248693-0800 gzclient[14108:3462293] SecTaskCopyDebugDescription: gzclient-9.5.0[14108]/0#-1 LF=0
    [Wrn] [] Failed to get QCocoaScreen for NSObject(0x0)
    Process 14108 stopped
    * thread #1, name = 'ZMQbg/1', queue = '', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
        frame #0: 0x0000000101414495 libgazebo_rendering.9.dylib`gazebo::rendering::Light::FillMsg(gazebo::msgs::Light&) const + 21
    ->  0x101414495 <+21>: movq   0x18(%r14), %rax
        0x101414499 <+25>: movq   0x20(%rax), %rsi
        0x10141449d <+29>: xorps  %xmm0, %xmm0
        0x1014144a0 <+32>: leaq   -0x40(%rbp), %rdx
    Target 0: (gzclient) stopped.
    (lldb) bt
    * thread #1, name = 'ZMQbg/1', queue = '', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
      * frame #0: 0x0000000101414495 libgazebo_rendering.9.dylib`gazebo::rendering::Light::FillMsg(gazebo::msgs::Light&) const + 21
        frame #1: 0x00000001007a154f libgazebo_gui.9.dylib`gazebo::gui::ModelListWidget::OnSetSelectedEntity(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 389

    The bottle doesn't have debug symbols, so I'm building again from source to get a better backtrace.

  7. Steven Peters

    Now in debug mode, the backtrace points at gazebo::gui::ModelListWidget::OnSetSelectedEntity at It seems we don't check the light pointer before dereferencing it.

    [Wrn] [] Failed to get QCocoaScreen for NSObject(0x0)
    Assertion failed: (px != 0), function operator->, file /usr/local/include/boost/smart_ptr/shared_ptr.hpp, line 734.
    Process 34110 stopped
    * thread #1, name = 'ZMQbg/1', queue = '', stop reason = signal SIGABRT
        frame #0: 0x00007fff65e7123e libsystem_kernel.dylib`__pthread_kill + 10
    ->  0x7fff65e7123e <+10>: jae    0x7fff65e71248            ; <+20>
        0x7fff65e71240 <+12>: movq   %rax, %rdi
        0x7fff65e71243 <+15>: jmp    0x7fff65e6b3b7            ; cerror_nocancel
        0x7fff65e71248 <+20>: retq   
    Target 0: (gzclient) stopped.
    (lldb) bt
    * thread #1, name = 'ZMQbg/1', queue = '', stop reason = signal SIGABRT
      * frame #0: 0x00007fff65e7123e libsystem_kernel.dylib`__pthread_kill + 10
        frame #1: 0x00007fff65f27c1c libsystem_pthread.dylib`pthread_kill + 285
        frame #2: 0x00007fff65dda1c9 libsystem_c.dylib`abort + 127
        frame #3: 0x00007fff65da2868 libsystem_c.dylib`__assert_rtn + 320
        frame #4: 0x00000001008d7e99 libgazebo_gui.9.dylib`boost::shared_ptr<gazebo::rendering::Light>::operator->(this=0x00007ffeefbfb948) const at shared_ptr.hpp:734
        frame #5: 0x0000000100968533 libgazebo_gui.9.dylib`gazebo::gui::ModelListWidget::OnSetSelectedEntity(this=0x00000001180cb7b0, _name="sun", (null)="normal") at
  8. Steven Peters

    The following patch fixes the seg-fault:

    diff -r 297d6947eb79 gazebo/gui/
    --- a/gazebo/gui/ Mon Dec 10 18:47:47 2018 +0000
    +++ b/gazebo/gui/ Tue Dec 11 13:11:47 2018 -0800
    @@ -288,7 +288,17 @@
    -      light->FillMsg(this->dataPtr->lightMsg);
    +      if (light)
    +      {
    +        light->FillMsg(this->dataPtr->lightMsg);
    +      }
    +      else
    +      {
    +        gzerr << "Unable to get Light ["
    +              << this->dataPtr->selectedEntityName
    +              << "]."
    +              << std::endl;
    +      }
  9. Steven Peters

    @Ian Chen discovered that minimizing the gzclient window and then restoring it causes rendering to turn on. We first tested with a laptop with retina display, and it was only rendering to 25% of the window, which we have seen before in #2070. I tested also with a mac mini, which does not have this issue.

    So, there are two issues:

    • minimize then restore window necessary for rendering to start
    • 1/4 rendering on retina displays
  10. Ian Chen

    Actually on retina displays, it's rendering to the entire window but the camera orbit control mouse positions are scaled to 25% of the window. I have a fix for the camera control issue but have not figured out how to get the render window to start painting without the minimize + restore workaround

  11. Steven Peters

    I just tested gazebo7 as well, and it has a blank screen as well. I'm inclined to leave this broken and only support gazebo8+ on mojave.

  12. S Albert

    @Steven Peters Thanks for the info about gazebo7. I upgraded to Mojave on my MacBook Pro 2015, uninstalled Homebrew entirely, and reinstalled Homebrew and gazebo7. It works fine, including rendering and correct scaling.

    But I also attempted to do a fresh install on a new system (MacBook Pro 2018) that shipped with Mojave. That shows the blank screen you're describing (actually it's transparent, showing whatever's behind the window).

    Is there any info I can give you about my working system that would be helpful? We are probably moving to gazebo9 soon, but this would be helpful in the short-term.

  13. Log in to comment