search

The-OpenROAD-Project / OpenROAD

OpenROAD's unified application implementing an RTL-to-GDS Flow. Documentation at https://openroad.readthedocs.io/en/latest/
https://theopenroadproject.org/
BSD 3-Clause "New" or "Revised" License
1.4k stars 491 forks source link

Resize the OpenROAD GUI Window vigourously and the GUI locks up when run from docker #2675

Closed oharboe closed 12 months ago

oharboe commented 1 year ago

Describe the bug

Resize the OpenROAD GUI Window vigourously and the GUI locks up when run from docker.

Does not appear to happen when the OpenROAD GUI is run locally.

It is incredibly useful to be able to run OpenROAD GUI from a docker image when deploying OpenROAD.

Expected Behavior

No lockup.

Environment

Git commit: cf9e3b282573a32a7ae3678cd97074a5697276ae
kernel: Linux 5.15.0-56-generic
os: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
cmake version 3.24.2
gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Ubuntu clang version 14.0.0-1ubuntu1

To Reproduce

  1. create the bash script below somewhere, call it "or"
  2. Run ./or "make DESIGN_CONFIG=designs/asap7/gcd/config.mk floorplan && make DESIGN_CONFIG=designs/asap7/gcd/config.mk gui_floorplan"
  3. Resize vigourosly, at which point you get an error [WARNING GUI-0076] QXcbConnection: XCB error: 2 (BadValue), sequence: 1709, resource id: 1108, major code: 130 (Unknown), minor code: 3 and the GUI freezes.
#!/bin/bash
set -ex
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth
xauth nlist :0 | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
ARGUMENTS=$@

if test -t 0; then
    DOCKER_INTERACTIVE=-ti
fi

docker run -u $(id -u ${USER}):$(id -g ${USER}) \
 -e "QT_X11_NO_MITSHM=1" \
 -e DISPLAY=$DISPLAY \
 -e QT_XKB_CONFIG_ROOT=/usr/share/X11/xkb \
 -v $XSOCK:$XSOCK -v $XAUTH:$XAUTH -e XAUTHORITY=$XAUTH \
 -v $DIR:$DIR \
 -v `pwd`:`pwd` \
 -v `pwd`/fakeram-results:/alpha-release/bsg_fakeram/results \
 -v `pwd`/reports:/OpenROAD-flow-scripts/flow/reports/ \
 -v `pwd`/objects:/OpenROAD-flow-scripts/flow/objects/ \
 -v `pwd`/results:/OpenROAD-flow-scripts/flow/results/ \
 -v `pwd`/logs:/OpenROAD-flow-scripts/flow/logs/ \
 -v `pwd`/designs:/OpenROAD-flow-scripts/flow/designs/ \
 $DOCKER_INTERACTIVE openroad/flow-scripts:latest \
 bash -c "set -ex
 . ./setup_env.sh
 cd flow
 export MAKE_DIR=$DIR
 $ARGUMENTS
"

Relevant log output

No response

Screenshots

No response

Additional Context

No response

maliberty commented 1 year ago

I tried one design without reproducing it. Can you get a stack when it happens?

oharboe commented 1 year ago

@maliberty Managed to reproduce it using docker.

maliberty commented 1 year ago

I would expect updateInsts to only happen once since resizing doesn't change odb. Are you seeing it happen more than once? Is it actually hung or just slow?

oharboe commented 1 year ago

I would expect updateInsts to only happen once since resizing doesn't change odb. Are you seeing it happen more than once? Is it actually hung or just slow?

@maliberty

I have narrowed this github issue down to dealing with the problem of a lockup in resizing when running OpenROAD GUI from docker. I deleted the cul de sacs I followed here.

We already know about that OpenROAD GUI can't deal with the pathological case of ASAP7 designs with millions of filler cells.

oharboe commented 1 year ago

@maliberty Hmmm.... Googled a bit. Didn't get much wiser. Could this be that the Docker image is running an older version of Qt and that latest Ubuntu has a fixed version?

Ubuntu 22 is running qt6 and the Docker image qt5.

maliberty commented 1 year ago

Based on your stack trace it isn't doesn't seem like a qt issue but more likely a boost version if anything

oharboe commented 1 year ago

Based on your stack trace it isn't doesn't seem like a qt issue but more likely a boost version if anything

The scaling issue is a separate issue. I am able to reproduce the lockup with tiny designs.

maliberty commented 1 year ago

What is your setup for a small design that shows the problem? I haven't reproduced it.

oharboe commented 1 year ago

What is your setup for a small design that shows the problem? I haven't reproduced it.

Any design, running the GUI from Docker with scripts above, I think. Above I use asap7/gvd.

Though, Docker may be a red herring. I googled and this may be fixed in qt6, which would explain why it works locally in Ubuntu 22

maliberty commented 1 year ago

I opened ng45/gcd using qt5 and a local build. A minute of vigorous resizing produced no hang.

oharboe commented 1 year ago

I opened ng45/gcd using qt5 and a local build. A minute of vigorous resizing produced no hang.

I tried on Ubuntu 22. You?

maliberty commented 1 year ago

centos7

oharboe commented 1 year ago

After studying the build files today I discovered that OpenROAD GUI is built against qt5 on Ubuntu 22 as well on CentOS 7. Meaning, the qt5 vs. qt6 was a red herring.

maliberty commented 1 year ago

I have ubuntu 22 under WSL on my windows laptop. I can try that but I'm dubious it will matter.

oharboe commented 1 year ago

gcd is small enough I can run it in the debugger. Stay tuned.

maliberty commented 1 year ago

Fwiw I'm using Qt 5.9.7

oharboe commented 1 year ago

Fwiw I'm using Qt 5.9.7

$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.10 Release: 22.10 Codename: kinetic

$ qmake --version QMake version 3.1 Using Qt version 5.15.6 in /usr/lib/x86_64-linux-gnu

oharboe commented 1 year ago

So. I can only reproduce the lockup with asap7/gcd on Ubuntu local using Docker.

Therefore, I think there are two issues:

Let's use this github issue to talk about a crash when running OpenROAD GUI from Docker and when I have more actionable information, I'll open a new issue ragarding problems with a large number of instances and the OpenROAD GUI.

maliberty commented 1 year ago

As a test of docker I opened spm from within the OL docker container. Resizing lead to no hang there either.

oharboe commented 1 year ago

As a test of docker I opened spm from within the OL docker container. Resizing lead to no hang there either.

Silly question. What is "spm"? "OL" is OpenLane, I presume.

maliberty commented 1 year ago

Yes OL=OpenLane. spm is their small test - what you get if you do 'make test'.

maliberty commented 1 year ago

https://github.com/The-OpenROAD-Project/OpenLane/tree/master/designs/spm

oharboe commented 1 year ago

@maliberty

So:

  1. it would appear that there is a scaling issue with millions of instances that can appear as a lockup. This issue is not about that, but about docker crashes. I have tried to make a .odb file with millions of instances crash in the the debugger and I have failed, though I can clearly observe scaling issues when I suspend the debugger during pauses and loading of the .odb file.
  2. We observe crashes when running OpenROAD GUI from docker on ubuntu 22, but not CentOS 7.
maliberty commented 1 year ago

I ran on Ubuntu22 under WSL on windows (no docker) and resizing is not hanging. I can't say "We observe ..." yet. I'm hoping you can do a bit of debugging as I'm not having any luck reproducing the issue.

QuantamHD commented 1 year ago

If I could make a suggestion.

It might be worth doing some scalability work first. As frame times increase it can often reveal or break graphics routines that expect faster update cycles. For example the user input queues can build up while frames are being drawn causing lock up like behavior.

If we improve performance we might solve this issue.

oharboe commented 1 year ago

I ran on Ubuntu22 under WSL on windows (no docker) and resizing is not hanging. I can't say "We observe ..." yet. I'm hoping you can do a bit of debugging as I'm not having any luck reproducing the issue.

Yep. Matches what I see. The lockup is only under Docker, in some circumstances.

I think the solution to this problem is to make a Debian installer. I've started some work on this: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/746 https://github.com/The-OpenROAD-Project/OpenROAD/pull/2689

oharboe commented 1 year ago

If I could make a suggestion.

It might be worth doing some scalability work first. As frame times increase it can often reveal or break graphics routines that expect faster update cycles. For example the user input queues can build up while frames are being drawn causing lock up like behavior.

If we improve performance we might solve this issue.

In the debugger makes the GUI run pathologically slow, but I have never seen a lockup. I think this is a problem with Docker(not the only one, we also see garbled graphics).

I think the solution is to have a Debian installer that can be used on Ubuntu for OpenROAD GUI.

oharboe commented 1 year ago

Some more tests:

oharboe commented 1 year ago

Huh.... Today I can resize the GUI when run from within docker without it crashing. I recently upgraded to the latest OpenROAD master....

Will test some more and if it is fixed, I'll close.

The only recent change in src/gui is d297c5b18d08684b550e74a3115d4c366bd92e01, which doesn't seem like it should fix a crash in resizing.

oharboe commented 1 year ago

@maliberty I'll file a fresh github issue if it starts happening again with link to this one.

oharboe commented 1 year ago

It still happens, but very rarely, e.g. when I was running a ctrl-f, it locked up:

[WARNING GUI-0076] QXcbConnection: XCB error: 3 (BadWindow), sequence: 1762, resource id: 12621573, major code: 40 (TranslateCoords), minor code: 0
[WARNING GUI-0076] QXcbConnection: XCB error: 3 (BadWindow), sequence: 11651, resource id: 12622023, major code: 40 (TranslateCoords), minor code: 0
maliberty commented 1 year ago

Those messages commonly print at startup but don't seem to mean much.

oharboe commented 1 year ago

Those messages commonly print at startup but don't seem to mean much.

When the GUI is run from docker, they consistently appear only when the GUI crashes.

Perhaps some sort of unfortunate sequence of events that end up in a crash, but where a native app dodges the bullit?

Perhaps those harmless warnings are worth chasing down?

Anyway: the OpenROAD gui is much, much, much more stable from docker now. Completely usable. A single crash in a day.

maliberty commented 1 year ago

I don't think there are any GUI changes so it seems like something at your side

oharboe commented 1 year ago

@maliberty After reproducing this and having a stack trace, I'm reopening this issue as now I think it should be actionable...

It looks like a deadlock of some sort. Perhaps because the logger is updating the logger widget synchronously and logging is caused from obscure Xcb warning corner cases in Docker?

+ bash
bash-4.2$ gdb --args openroad -gui
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 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-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad...(no debugging symbols found)...done.
(gdb) r
Starting program: /OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad -gui
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fcd5da61700 (LWP 18)]
[New Thread 0x7fcd5a541700 (LWP 19)]
[New Thread 0x7fcd594c3700 (LWP 20)]
[Detaching after fork from child process 21]
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
[New Thread 0x7fcd52b4a700 (LWP 23)]
OpenROAD HEAD-HASH-NOTFOUND
This program is licensed under the BSD-3 license. See the LICENSE file for details.
Components of this program may be licensed under more restrictive licenses which must be honored.
[New Thread 0x7fcd51a8b700 (LWP 24)]
[Thread 0x7fcd51a8b700 (LWP 24) exited]
[WARNING GUI-0077] Timing data is not stored in /home/oyvind/ascenium/ascenium2/hardware/openroad/results/asap7/ce-array_AptosCore/base/6_final.odb and must be loaded separately, if needed.
[WARNING GUI-0076] QXcbConnection: XCB error: 2 (BadValue), sequence: 2145, resource id: 1437, major code: 130 (Unknown), minor code: 3
^C
Program received signal SIGINT, Interrupt.
0x00007fcd64b69e29 in syscall () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 dbus-libs-1.10.24-15.el7.x86_64 elfutils-libelf-0.176-5.el7.x86_64 elfutils-libs-0.176-5.el7.x86_64 expat-2.1.0-15.el7_9.x86_64 fontconfig-2.13.0-4.3.el7.x86_64 freetype-2.8-14.el7_9.1.x86_64 glib2-2.56.1-9.el7_9.x86_64 glibc-2.17-326.el7_9.x86_64 graphite2-1.3.10-1.el7_3.x86_64 harfbuzz-1.7.5-2.el7.x86_64 jasper-libs-1.900.1-33.el7.x86_64 jbigkit-libs-2.0-11.el7.x86_64 libICE-1.0.9-9.el7.x86_64 libSM-1.2.2-2.el7.x86_64 libX11-1.6.7-4.el7_9.x86_64 libXau-1.0.8-2.1.el7.x86_64 libXcursor-1.1.15-1.el7.x86_64 libXdamage-1.1.4-4.1.el7.x86_64 libXext-1.3.3-3.el7.x86_64 libXfixes-5.0.3-1.el7.x86_64 libXi-1.7.9-1.el7.x86_64 libXrender-0.9.10-1.el7.x86_64 libXxf86vm-1.1.4-1.el7.x86_64 libattr-2.4.46-13.el7.x86_64 libcap-2.22-11.el7.x86_64 libdrm-2.4.97-2.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 libgcrypt-1.5.3-14.el7.x86_64 libglvnd-1.0.1-0.8.git5baa1e5.el7.x86_64 libglvnd-glx-1.0.1-0.8.git5baa1e5.el7.x86_64 libgomp-4.8.5-44.el7.x86_64 libgpg-error-1.12-3.el7.x86_64 libicu-50.2-4.el7_7.x86_64 libjpeg-turbo-1.2.90-8.el7.x86_64 libmng-1.0.10-14.el7.x86_64 libpng-1.5.13-8.el7.x86_64 libselinux-2.5-15.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 libtiff-4.0.3-35.el7.x86_64 libuuid-2.23.2-65.el7_9.1.x86_64 libxcb-1.13-1.el7.x86_64 libxshmfence-1.2-1.el7.x86_64 lz4-1.8.3-1.el7.x86_64 mesa-libGL-18.3.4-12.el7_9.x86_64 mesa-libglapi-18.3.4-12.el7_9.x86_64 ncurses-libs-5.9-14.20130511.el7_4.x86_64 pcre-8.32-17.el7.x86_64 pcre2-utf16-10.23-2.el7.x86_64 python3-libs-3.6.8-18.el7.x86_64 qt5-qtbase-5.9.7-5.el7_9.x86_64 qt5-qtbase-gui-5.9.7-5.el7_9.x86_64 qt5-qtimageformats-5.9.7-2.el7_9.x86_64 readline-6.2-11.el7.x86_64 systemd-libs-219-78.el7_9.7.x86_64 tcl-8.5.13-8.el7.x86_64 tcl-tclreadline-2.1.0-3.el7.x86_64 xcb-util-0.4.0-2.el7.x86_64 xcb-util-image-0.4.0-2.el7.x86_64 xcb-util-keysyms-0.4.0-1.el7.x86_64 xcb-util-renderutil-0.3.9-3.el7.x86_64 xcb-util-wm-0.4.1-5.el7.x86_64 xz-libs-5.2.2-2.el7_9.x86_64 zlib-1.2.7-21.el7_9.x86_64
(gdb) bt
#0  0x00007fcd64b69e29 in syscall () from /lib64/libc.so.6
#1  0x00007fcd65c27116 in QBasicMutex::lockInternal() ()
   from /lib64/libQt5Core.so.5
#2  0x00007fcd65c273e7 in QMutex::lock() () from /lib64/libQt5Core.so.5
#3  0x00007fcd5d16ebe4 in QXcbEventReader::lock() ()
   from /lib64/libQt5XcbQpa.so.5
#4  0x00007fcd5d16ef14 in QXcbConnection::processXcbEvents() ()
   from /lib64/libQt5XcbQpa.so.5
#5  0x00007fcd65e0212e in QObject::event(QEvent*) ()
   from /lib64/libQt5Core.so.5
#6  0x00007fcd66647d8c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /lib64/libQt5Widgets.so.5
#7  0x00007fcd6664ef68 in QApplication::notify(QObject*, QEvent*) ()
   from /lib64/libQt5Widgets.so.5
#8  0x00007fcd65dd8b36 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
    () from /lib64/libQt5Core.so.5
#9  0x00007fcd65ddb453 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5
#10 0x00007fcd65e27a03 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt5Core.so.5
#11 0x00007fcd61a23119 in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#12 0x00007fcd61a23478 in g_main_context_iterate.isra.19 ()
---Type <return> to continue, or q <return> to quit---
   from /lib64/libglib-2.0.so.0
#13 0x00007fcd61a2352c in g_main_context_iteration ()
   from /lib64/libglib-2.0.so.0
#14 0x00007fcd65e273ac in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#15 0x0000000001377fb6 in gui::ScriptWidget::outputChanged() ()
#16 0x00007fcd65e00b47 in QMetaObject::activate(QObject*, int, int, void**) ()
   from /lib64/libQt5Core.so.5
#17 0x00007fcd66808805 in QPlainTextEdit::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /lib64/libQt5Widgets.so.5
#18 0x00007fcd65e00b47 in QMetaObject::activate(QObject*, int, int, void**) ()
   from /lib64/libQt5Core.so.5
#19 0x00007fcd66827a65 in QWidgetTextControl::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /lib64/libQt5Widgets.so.5
#20 0x00007fcd66827f8b in QWidgetTextControl::qt_metacall(QMetaObject::Call, int, void**) () from /lib64/libQt5Widgets.so.5
#21 0x00007fcd65e01144 in QMetaObject::activate(QObject*, int, int, void**) ()
   from /lib64/libQt5Core.so.5
#22 0x00007fcd6621c574 in QTextDocumentPrivate::finishEdit() ()
   from /lib64/libQt5Gui.so.5
#23 0x00007fcd668238ab in QWidgetTextControlPrivate::append(QString const&, Qt::TextFormat) () from /lib64/libQt5Widgets.so.5
#24 0x00007fcd66804e95 in QPlainTextEditPrivate::append(QString const&, Qt::Text---Type <return> to continue, or q <return> to quit---
Format) () from /lib64/libQt5Widgets.so.5
#25 0x00000000013783b8 in gui::ScriptWidget::addTextToOutput(QString const&, QColor const&) ()
#26 0x00007fcd65e0212e in QObject::event(QEvent*) ()
   from /lib64/libQt5Core.so.5
#27 0x00007fcd666860db in QWidget::event(QEvent*) ()
   from /lib64/libQt5Widgets.so.5
#28 0x00007fcd6676c11b in QDockWidget::event(QEvent*) ()
   from /lib64/libQt5Widgets.so.5
#29 0x00007fcd66647d8c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /lib64/libQt5Widgets.so.5
#30 0x00007fcd6664ef68 in QApplication::notify(QObject*, QEvent*) ()
   from /lib64/libQt5Widgets.so.5
#31 0x00007fcd65dd8b36 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
    () from /lib64/libQt5Core.so.5
#32 0x00007fcd65ddb453 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5
#33 0x0000000001379484 in gui::ScriptWidget::GuiSink<spdlog::details::null_mutex>::sink_it_(spdlog::details::log_msg const&) ()
#34 0x0000000002cb1dc4 in spdlog::logger::sink_it_(spdlog::details::log_msg const&) ()
#35 0x0000000002cb26f2 in spdlog::logger::log_it_(spdlog::details::log_msg const&, bool, bool) ()
---Type <return> to continue, or q <return> to quit---
#36 0x0000000000cf666a in void spdlog::logger::log_<fmt::v7::basic_string_view<char>, char const*, char const*, int>(spdlog::source_loc, spdlog::level::level_enum, fmt::v7::basic_string_view<char> const&, char const* const&, char const* const&, int const&) ()
#37 0x0000000000cf9f4e in void utl::Logger::log<>(utl::ToolId, spdlog::level::level_enum, int, std::string const&) ()
#38 0x00000000012ea29a in gui::message_handler(QtMsgType, QMessageLogContext const&, QString const&) ()
#39 0x00007fcd65c1a2fa in qt_message_print(QtMsgType, QMessageLogContext const&, QString const&) () from /lib64/libQt5Core.so.5
#40 0x00007fcd65c1a474 in qt_message(QtMsgType, QMessageLogContext const&, char const*, __va_list_tag*) () from /lib64/libQt5Core.so.5
#41 0x00007fcd65c1b19b in QMessageLogger::warning(char const*, ...) const ()
   from /lib64/libQt5Core.so.5
#42 0x00007fcd5d168102 in QXcbConnection::handleXcbError(xcb_generic_error_t*)
    () from /lib64/libQt5XcbQpa.so.5
#43 0x00007fcd5d16ef4b in QXcbConnection::processXcbEvents() ()
   from /lib64/libQt5XcbQpa.so.5
#44 0x00007fcd65e0212e in QObject::event(QEvent*) ()
   from /lib64/libQt5Core.so.5
#45 0x00007fcd66647d8c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /lib64/libQt5Widgets.so.5
#46 0x00007fcd6664ef68 in QApplication::notify(QObject*, QEvent*) ()
---Type <return> to continue, or q <return> to quit---
   from /lib64/libQt5Widgets.so.5
#47 0x00007fcd65dd8b36 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
    () from /lib64/libQt5Core.so.5
#48 0x00007fcd65ddb453 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5
#49 0x00007fcd65e27a03 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt5Core.so.5
#50 0x00007fcd61a23119 in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#51 0x00007fcd61a23478 in g_main_context_iterate.isra.19 ()
   from /lib64/libglib-2.0.so.0
#52 0x00007fcd61a2352c in g_main_context_iteration ()
   from /lib64/libglib-2.0.so.0
#53 0x00007fcd65e273ac in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#54 0x00007fcd65dd762b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#55 0x00007fcd65ddfb54 in QCoreApplication::exec() ()
   from /lib64/libQt5Core.so.5
#56 0x00000000012ecfcd in gui::startGui(int&, char**, Tcl_Interp*, std::string const&, bool) ()
#57 0x0000000000cfac6a in ord::tclAppInit(Tcl_Interp*) ()
#58 0x00007fcd697e6475 in Tcl_Main () from /lib64/[libtcl8.5.so](http://libtcl8.5.so/)
---Type <return> to continue, or q <return> to quit---
#59 0x0000000000ccc744 in main ()
(gdb)
(gdb)
maliberty commented 1 year ago

I still have trouble reproducing this so I hope you can try this potential solution for me. Based on the comments in https://bugreports.qt.io/browse/QTBUG-55167 I made https://github.com/The-OpenROAD-Project/OpenROAD/pull/3466.

Hopefully that silences all xcb error messages. If not, please try the alternative:


To use this, I drop the following in /etc/xdg/QtProject/qtlogging.ini:

[Rules]
qt.qpa.xcb.xcberror=false```
oharboe commented 1 year ago

I still have trouble reproducing this so I hope you can try this potential solution for me. Based on the comments in https://bugreports.qt.io/browse/QTBUG-55167 I made #3466.

Hopefully that silences all xcb error messages. If not, please try the alternative:

To use this, I drop the following in /etc/xdg/QtProject/qtlogging.ini:

[Rules]
qt.qpa.xcb.xcberror=false```

I tried the latter, but it still locks up.

maliberty commented 1 year ago

Did you put it inside the container?

oharboe commented 1 year ago

Did you put it inside the container?

Yes, used -v and checked that it was mapped correctly.

oharboe commented 1 year ago

Trying:

$ git show
commit 85c5c806b15abcbb2d3e934ec4d76e611b2cc3ac (HEAD)
Merge: 6a4ea1ea5 8164ed0da
Author: Øyvind Harboe <oyvind.harboe@zylin.com>
Date:   Thu Jun 15 06:34:52 2023 +0200

    Merge commit 'refs/pull/3466/head' of https://github.com/The-OpenROAD-Project/OpenROAD into HEAD

Same crash...