Resize the OpenROAD GUI Window vigourously and the GUI locks up when run from docker #2675
Comments
|
I tried one design without reproducing it. Can you get a stack when it happens? |
oharboe
changed the title
|
@maliberty Managed to reproduce it using docker. |
|
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? |
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. |
|
@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. |
|
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. |
|
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 |
|
I opened ng45/gcd using qt5 and a local build. A minute of vigorous resizing produced no hang. |
I tried on Ubuntu 22. You? |
|
centos7 |
|
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. |
|
I have ubuntu 22 under WSL on my windows laptop. I can try that but I'm dubious it will matter. |
|
gcd is small enough I can run it in the debugger. Stay tuned. |
|
Fwiw I'm using Qt 5.9.7 |
$ lsb_release -a $ qmake --version |
|
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. |
|
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. |
|
Yes OL=OpenLane. spm is their small test - what you get if you do 'make test'. |
|
So:
|
|
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. |
|
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. |
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: The-OpenROAD-Project/OpenROAD-flow-scripts#746 #2689 |
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. |
|
Some more tests:
|
|
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 d297c5b, which doesn't seem like it should fix a crash in resizing. |
|
@maliberty I'll file a fresh github issue if it starts happening again with link to this one. |
|
It still happens, but very rarely, e.g. when I was running a ctrl-f, it locked up: |
|
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. |
|
I don't think there are any GUI changes so it seems like something at your side |
|
@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? |
fixes The-OpenROAD-Project#2675 logging tried to render the log message synchronously, which caused a lockup as the main event loop was processed during the reporting of an Xcb error. With the upcoming The-OpenROAD-Project#3370 fix to rendering where rendering is cancelled and restarted when it takes to long, it's not too bad to wait until the GUI is idle before updating the log message in the GUI. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
|
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: |
I tried the latter, but it still locks up. |
|
Did you put it inside the container? |
Yes, used |
|
Trying: Same crash... |
fixes The-OpenROAD-Project#2675 logging tried to render the log message synchronously, which caused a lockup as the main event loop was processed during the reporting of an Xcb error. Skip update of the GUI if the error message contains a string from the Qt error handler. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
fixes The-OpenROAD-Project#2675 logging tried to render the log message synchronously, which caused a lockup as the main event loop was processed during the reporting of an Xcb error. Skip update of the GUI if the error message contains a string from the Qt error handler. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
fixes The-OpenROAD-Project#2675 logging tried to render the log message synchronously, which caused a lockup as the main event loop was processed during the reporting of an Xcb error. With the upcoming The-OpenROAD-Project#3370 fix to rendering where rendering is cancelled and restarted when it takes to long, it's not too bad to wait until the GUI is idle before updating the log message in the GUI. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
fixes The-OpenROAD-Project#2675 logging tried to render the log message synchronously, which caused a lockup as the main event loop was processed during the reporting of an Xcb error. Skip update of the GUI if the error message contains a string from the Qt error handler. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
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
To Reproduce
./or "make DESIGN_CONFIG=designs/asap7/gcd/config.mk floorplan && make DESIGN_CONFIG=designs/asap7/gcd/config.mk gui_floorplan"[WARNING GUI-0076] QXcbConnection: XCB error: 2 (BadValue), sequence: 1709, resource id: 1108, major code: 130 (Unknown), minor code: 3and the GUI freezes.Relevant log output
No response
Screenshots
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: