| Summary: | net-im/zoom-5.3.472687.1012 crashing since recent world update | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Etienne Lorriaux <etienne.lorriaux> |
| Component: | Current packages | Assignee: | Ulrich Müller <ulm> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | barnoid, bruce, dct23, dilfridge, douzzer, kkrizka, mva, ostroffjh, pacho, paul, qt, sam, zigford |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=904958 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 726178 | ||
| Attachments: |
Ebuilds which have been updated
Emerge info Terminal output after a crash |
||
|
Description
Etienne Lorriaux
2020-10-20 15:26:58 UTC
Created attachment 667553 [details]
Ebuilds which have been updated
List of ebuild which have been updated between the moment zoom was working fine and the moment I've noticed it was crashing (unfortunately I've not used zoom a few days so I cannot spot exactly after which update it started to crash)
Created attachment 667556 [details]
Emerge info
Created attachment 667559 [details]
Terminal output after a crash
I'm seeing a possibly related bug here -- infinite loops of "Qt Quick Layouts: Polish loop detected. Aborting after two iterations.". First happened on a mouse gesture while creating a meeting, now happens immediately on startup and prevents window creation. I'm currently on net-im/zoom-5.3.472687.1012 (latest), and tried downgrade to zoom-5.2.458699.0906.ebuild. No difference. The workaround was to downgrade Qt from 5.15.1 to 5.14.2. An older runtime with Qt 5.15.0 showed the same bug. The problem didn't present immediately on Qt upgrade. In particular, I upgraded to 5.15.0 on 2020-May-27, to 5.15.1 on Sept 11, and to 5.15.1-r1 on Oct 11, but didn't see a problem until Oct 16, which was the first occasion to use Zoom after the Oct 11 upgrade to 5.15.1-r1. The rest of my runtime is up-to-date ~amd64. For now, I've added this to package.mask, until a substantive cure is on offer: # 2020-10-16 # Zoom is currently broken on qt 5.15: # (probably relevant: https://codereview.qt-project.org/c/qt/qtdeclarative/+/300946) >=dev-qt/linguist-tools-5.15.0 >=dev-qt/qtcore-5.15.0 >=dev-qt/qtdbus-5.15.0 >=dev-qt/qtdeclarative-5.15.0 >=dev-qt/qtdiag-5.15.0 >=dev-qt/qtgraphicaleffects-5.15.0 >=dev-qt/qtgui-5.15.0 >=dev-qt/qthelp-5.15.0 >=dev-qt/qtmultimedia-5.15.0 >=dev-qt/qtnetwork-5.15.0 >=dev-qt/qtopengl-5.15.0 >=dev-qt/qtpositioning-5.15.0 >=dev-qt/qtprintsupport-5.15.0 >=dev-qt/qtquickcontrols-5.15.0 >=dev-qt/qtscript-5.15.0 >=dev-qt/qtsensors-5.15.0 >=dev-qt/qtsql-5.15.0 >=dev-qt/qtsvg-5.15.0 >=dev-qt/qttest-5.15.0 >=dev-qt/qtwebchannel-5.15.0 >=dev-qt/qtwidgets-5.15.0 >=dev-qt/qtx11extras-5.15.0 >=dev-qt/qtxml-5.15.0 >=dev-qt/qtxmlpatterns-5.15.0 Hi Daniel, thanks for the contribution. You're confirming my doubts about qt-5.15.1, but I could not downgrade as previous ebuilds have been removed. How did you proceed? I downgraded in the nick of time while 5.14.2 was still in the tree, and I just finished copying the ebuilds and patch files to my /etc/portage/overlay using a system snapshot. But I think we can expect that the port maintainers will either add a patch to 5.15.1, or (less likely and not ideal) add 5.14.2 back. I don't really have the time to wait as I use zoom intensively for home working. Qt 5.14 ebuilds can be found in portage snapshot from 10/13. You also need to get qt5-build eclass from that archive otherwise you won't be able to recompile qtcore-5.14.2 (and probably other qt packages) as some compile options have changed in qt 5.15, qtcore-5.14.2 does not build anymore with current qt5 eclass. Is there any additional output like "Segmentation Fault", Signal ..., or similar? Do you have core dumps enabled, and if yes, does the crash produce one? (That's of limited usefulness for a commercial binary, but we might at least see which part of Qt is involved.) (In reply to Andreas K. Hüttel from comment #8) > Is there any additional output like "Segmentation Fault", Signal ..., or > similar? > > Do you have core dumps enabled, and if yes, does the crash produce one? > > (That's of limited usefulness for a commercial binary, but we might at least > see which part of Qt is involved.) (Just for the record, I have Qt 5.15.1-r1 and zoom works fine, so there must be some additional factor...) (In reply to Andreas K. Hüttel from comment #8) > Is there any additional output like "Segmentation Fault", Signal ..., or > similar? > > Do you have core dumps enabled, and if yes, does the crash produce one? > > (That's of limited usefulness for a commercial binary, but we might at least > see which part of Qt is involved.) The zoomcrash.log I've attached corresponds to the output of the terminal for 1 zoom session ending in a crash, no segmentation fault. I have core dumps enabled but I did not get any core. (In reply to Daniel Pouzzner from comment #4) > The workaround was to downgrade Qt from 5.15.1 to 5.14.2. An older runtime > with Qt 5.15.0 showed the same bug. That would indicate that the "polish loop detection" cannot be the problem. That commit has a date of 2020-05-21 whereas 5.15.0 was tagged on 2020-05-11. > The problem didn't present immediately on Qt upgrade. In particular, I > upgraded to 5.15.0 on 2020-May-27, to 5.15.1 on Sept 11, and to 5.15.1-r1 on > Oct 11, but didn't see a problem until Oct 16, which was the first occasion > to use Zoom after the Oct 11 upgrade to 5.15.1-r1. The rest of my runtime > is up-to-date ~amd64. If we assume that Qt 5.15.1 is the only culprit, then something doesn't fit here. Chances are that you would have seen the problem earlier and not 5 months later. So I suspect that it's (In reply to Andreas K. Hüttel from comment #9) > (Just for the record, I have Qt 5.15.1-r1 and zoom works fine, so there must > be some additional factor...) Same here. I cannot reproduce the problem with 5.3.472687.1012 and Qt 5.15.1. (In reply to Ulrich Müller from comment #11) > If we assume that Qt 5.15.1 is the only culprit, then something doesn't fit > here. Chances are that you would have seen the problem earlier and not > 5 months later. So I suspect that it's Oops, something got truncated there. I suspect that it's interaction of Qt with something else, maybe a recently updated dependency. (In reply to Ulrich Müller from comment #12) > (In reply to Ulrich Müller from comment #11) > > If we assume that Qt 5.15.1 is the only culprit, then something doesn't fit > > here. Chances are that you would have seen the problem earlier and not > > 5 months later. So I suspect that it's > > Oops, something got truncated there. > > I suspect that it's interaction of Qt with something else, maybe a recently > updated dependency. Then the guilty must be in genlop.log, I'm sure zoom was working fine before these updates. The only strange thing is that I thing it was working on 10/16 (and I restarted my laptop in the morning after 10/16 updates). So it's possible that the guilty is in 10/19 updates. I've downgraded to Qt-5.14.2 and no crash since the downgrade. (In reply to Etienne Lorriaux from comment #1) > Created attachment 667553 [details] > Ebuilds which have been updated > > List of ebuild which have been updated between the moment zoom was working > fine and the moment I've noticed it was crashing (unfortunately I've not > used zoom a few days so I cannot spot exactly after which update it started > to crash) I went through that list, and the only package that is a dependency of Qt and where I have a version different from yours is media-libs/mesa, where you have 20.1.10 (updated on 2020-10-19) and I have 20.2.1. However, after downgrading to mesa-20.1.10, I still couldn't reproduce the problem. (In reply to Ulrich Müller from comment #14) > > I went through that list, and the only package that is a dependency of Qt > and where I have a version different from yours is media-libs/mesa, where > you have 20.1.10 (updated on 2020-10-19) and I have 20.2.1. > > However, after downgrading to mesa-20.1.10, I still couldn't reproduce the > problem. I was also thinking to mesa, I'll do the test to re-updrage to qt 5.15.2 and downgrade mesa to 20.1.8 or upgrade to 20.2 as soon as I can find the time. For now I need a working zoom during working days. (In reply to Etienne Lorriaux from comment #15) > (In reply to Ulrich Müller from comment #14) > > > > I went through that list, and the only package that is a dependency of Qt > > and where I have a version different from yours is media-libs/mesa, where > > you have 20.1.10 (updated on 2020-10-19) and I have 20.2.1. > > > > However, after downgrading to mesa-20.1.10, I still couldn't reproduce the > > problem. > > I was also thinking to mesa, I'll do the test to re-updrage to qt 5.15.2 and > downgrade mesa to 20.1.8 or upgrade to 20.2 as soon as I can find the time. > For now I need a working zoom during working days. Just make sure that you restart zoom (or even better restart the entire laptop) such that the latest libraries are actually used... :) I have seen the same problem (endless Polish loop) on two Linux boxes; one with Zoom v5.1.422789.0705 the other with v5.3.472687.1012. I can also confirm that the problem seems to coincide with the upgrade to Qt 5.15.1-r1. All other versions have been removed from Portage, so I cannot test a downgrade. In my case, the problem manifests intermittently. If it does, however, then consistently on both systems and Zoom versions. This first made me think that there was some problem with the network or Zoom's servers, but the in-browser version (on one of the affected boxes) and the Android app (on the same wireless network) worked just fine. The last time I had the problem was last night. Reboots, etc wouldn't help. Today, Zoom works fine on both computers....go figure. (In reply to Barnoid from comment #17) > I have seen the same problem (endless Polish loop) on two Linux boxes; one > with Zoom v5.1.422789.0705 the other with v5.3.472687.1012. > > I can also confirm that the problem seems to coincide with the upgrade to Qt > 5.15.1-r1. All other versions have been removed from Portage, so I cannot > test a downgrade. > > In my case, the problem manifests intermittently. If it does, however, then > consistently on both systems and Zoom versions. This first made me think > that there was some problem with the network or Zoom's servers, but the > in-browser version (on one of the affected boxes) and the Android app (on > the same wireless network) worked just fine. > > The last time I had the problem was last night. Reboots, etc wouldn't help. > Today, Zoom works fine on both computers....go figure. Sorry, hit 'Submit' too early. To be more exact, the problem seems to manifest after an upgrade to qt-webengine-5.15.1-r1 AND mesa-20.1.10. The next time the problem occurs, I will upgrade to mesa-20.2.1 and report back. This is probably irrelevant, but the upgrade to Qt 5.15.1 last week broke my laptop with a message about the cpu not supporting rdrand. IIUC there was a bug in its AMD cpu that was "fixed" by the kernel denying the rdrand support (unless you include a boot-time override, which I now do). That fix was some time back, but Qt only spotted the change recently when it's determination of cpu feature support was in turn "fixed", presumably to believe the kernel. CLearly none of the above has the same symptoms, but I wonder if this change to cpu feature support is embroiled in the zoom crash. (FWIW, I ran zoom successfully this week using Qt 5.15.1.) Is this still a problem with zoom-5.4.53268.1025? Yes, I am able to reproduce this issue with 5.4.53268.1025 and both mesa-20.1.10/mesa-20.2.1. This may be irrelevant but the zoom 5.4.53268.1025 tarball downloaded from their website runs fine. I understand they use all bundled libraries so that probably explains why. (In reply to Devrin Talen from comment #22) > This may be irrelevant but the zoom 5.4.53268.1025 tarball downloaded from > their website runs fine. I understand they use all bundled libraries so > that probably explains why. They bundle the Qt 5.12.9 libs. We already know that the problem first occured with either version 5.15.0 or 5.15.1. This issue hit me today. I downgraded mesa from 20.1.10 to 20.1.8 and it is functioning fine with qtcore-5.15.1-r1. So starting from a working configuration with zoom 5.3.472687.1012, qt 5.14.2, mesa 20.1.10: - I removed my mask on qt 5.15 and updated my world. Zoom started to crash again. - Downgraded mesa from 20.1.10 to 20.1.8, closed zoom, rebooted my laptop... Zoom is still crashing Hi all, please post your gcc and glibc versions (used to build qt, in case of doubt) and whether you are affected by the crash or not. Thanks! Example (me): * gcc 9.3.0-r1 * glibc 2.31-r7 * not affected gcc-9.3.0-r1 , glibc-2.31-r6 and affected. gcc version 10.2.0 (Gentoo 10.2.0-r2 p3) sys-libs/glibc-2.32-r2 media-libs/mesa-20.2.1 Affected iff dev-qt/* are >= 5.15.0, unaffected iff dev-qt/* are 5.14.2. Updated Zoom today to net-im/zoom-5.4.53350.1027. Works fine on 5.14.2. gcc-9.3.0-r1, glibc-2.32-r2, not affected gcc-9.3.0-r1
sys-libs/glibc-2.31-r6
dev-qt/qtcore-5.15.1-r1
media-libs/mesa-20.1.8
net-im/zoom-5.4.53268.1025
Correction from my previous comment. I was not having a zoom crash on mesa 2.1.10, but I have the UI lockup with the error:
Qt Quick Layouts: Polish loop detected. Aborting after two iterations.
Upon downgrading mesa to 20.1.8, I no longer have ui lockup and zoom works again.
Polish loop and UI freeze confirmed on two machines: gcc-9.3.0-r1 glibc-2.31-r6 qtcore-5.15.1-r1 mesa-20.1.10 zoom-5.1.422789.0705 and gcc-9.3.0-r1 glibc-2.31-r6 qtcore-5.15.1-r1 mesa-20.2.1 zoom-5.4.53268.1025 The same version downloaded from zoom.us works fine when run with the bundled libraries (Qt 5.12.9). (In reply to Jesse Harris from comment #30) > gcc-9.3.0-r1 > sys-libs/glibc-2.31-r6 > dev-qt/qtcore-5.15.1-r1 > media-libs/mesa-20.1.8 > net-im/zoom-5.4.53268.1025 > > Correction from my previous comment. I was not having a zoom crash on mesa > 2.1.10, but I have the UI lockup with the error: > > Qt Quick Layouts: Polish loop detected. Aborting after two iterations. > > Upon downgrading mesa to 20.1.8, I no longer have ui lockup and zoom works > again. Correction again (apologies for my hasty reply). This morning it locked up again (on mesa 20.1.8). Will do some more testing later to find the conditions where it doesn't lock up. (In reply to Andreas K. Hüttel from comment #26) > Hi all, please post your gcc and glibc versions (used to build qt, in case > of doubt) and whether you are affected by the crash or not. Thanks! > > Example (me): > > * gcc 9.3.0-r1 > * glibc 2.31-r7 > * not affected Correction. Crashes when clicking Q&A button. Thread 1 "zoom" received signal SIGSEGV, Segmentation fault.
0x00007f24dfe9b054 in QTextEngine::itemize (this=this@entry=0x558ffb86f170)
at /var/tmp/portage/dev-qt/qtgui-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/gui/text/qtextengine.cpp:2081
(gdb) bt
#0 QTextEngine::itemize (this=this@entry=0x563c99ba5510) at /var/tmp/portage/dev-qt/qtgui-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/gui/text/qtextengine.cpp:2082
#1 0x00007fb6620bd210 in QTextEngine::findItem (this=this@entry=0x563c99ba5510, strPos=0, firstItem=firstItem@entry=0)
at /var/tmp/portage/dev-qt/qtgui-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/gui/text/qtextengine.cpp:2237
#2 0x00007fb6620c75c9 in QTextLine::layout_helper (this=this@entry=0x7ffec42c1e40, maxGlyphs=maxGlyphs@entry=2147483647)
at /var/tmp/portage/dev-qt/qtgui-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/gui/text/qtextlayout.cpp:1830
#3 0x00007fb6620c966b in QTextLine::setLineWidth (this=this@entry=0x7ffec42c1e40, width=<optimized out>)
at /var/tmp/portage/dev-qt/qtgui-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/gui/text/qtextlayout.cpp:1605
#4 0x00007fb662d8c05e in QQuickTextPrivate::setLineGeometry (this=this@entry=0x563c99a4adf0, line=..., lineWidth=<optimized out>, height=@0x7ffec42c1e28: 0)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/quick/items/qquicktext.cpp:1201
#5 0x00007fb662d8cf01 in QQuickTextPrivate::setupTextLayout (this=this@entry=0x563c99a4adf0, baseline=baseline@entry=0x7ffec42c1fa0)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/quick/items/qquicktext.cpp:822
#6 0x00007fb662d8f03f in QQuickTextPrivate::updateSize (this=this@entry=0x563c99a4adf0)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/quick/items/qquicktext.cpp:411
#7 0x00007fb662d92e9a in QQuickText::geometryChanged (this=0x563c99ba5450, newGeometry=..., oldGeometry=...)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/quick/items/qquicktext.cpp:2436
#8 0x00007fb662d58229 in QQuickItem::setSize (this=0x563c99ba5450, size=...) at /usr/include/qt5/QtCore/qrect.h:644
#9 0x00007fb65404d1ba in QQuickGridLayoutItem::setGeometry (this=0x563c99c1d6f0, rect=...)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/imports/layouts/qquickgridlayoutengine_p.h:121
#10 0x00007fb6622b726b in QGridLayoutEngine::setGeometries (this=this@entry=0x563c994f4660, contentsGeometry=..., styleInfo=<optimized out>)
at /var/tmp/portage/dev-qt/qtgui-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/gui/util/qgridlayoutengine.cpp:1062
#11 0x00007fb65404b463 in QQuickGridLayoutBase::rearrange (this=0x563c981856c0, size=...) at /usr/include/qt5/QtCore/qsize.h:315
#12 0x00007fb654048de2 in QQuickLayout::geometryChanged (this=0x563c981856c0, newGeometry=..., oldGeometry=...) at /usr/include/qt5/QtCore/qarraydata.h:236
#13 0x00007fb662d57408 in QQuickItem::setX (this=0x563c981856c0, v=<optimized out>) at /usr/include/qt5/QtCore/qrect.h:644
#14 0x00007fb662d4a854 in QQuickAnchorsPrivate::setItemX (v=<optimized out>, this=0x563c99ba6d40)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/quick/items/qquickanchors.cpp:414
#15 QQuickAnchorsPrivate::updateHorizontalAnchors (this=this@entry=0x563c99ba6d40)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/quick/items/qquickanchors.cpp:789
#16 0x00007fb662d4ab56 in QQuickAnchorsPrivate::update (this=0x563c99ba6d40)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/quick/items/qquickanchors.cpp:489
#17 QQuickAnchorsPrivate::update (this=0x563c99ba6d40)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/quick/items/qquickanchors.cpp:478
#18 0x00007fb662d5da9d in QQuickItem::geometryChanged (this=this@entry=0x563c981856c0, newGeometry=..., oldGeometry=...) at /usr/include/qt5/QtCore/qobject.h:132
#19 0x00007fb654048c20 in QQuickLayout::geometryChanged (this=0x563c981856c0, newGeometry=..., oldGeometry=...)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/imports/layouts/qquicklayout.cpp:883
#20 0x00007fb662d57ef2 in QQuickItem::setImplicitSize (this=this@entry=0x563c981856c0, w=w@entry=371, h=h@entry=83) at /usr/include/qt5/QtCore/qrect.h:644
#21 0x00007fb654045dce in QQuickLayoutPrivate::applySizeHints (this=<optimized out>) at /usr/include/qt5/QtCore/qsize.h:315
#22 0x00007fb654045e17 in QQuickLayout::ensureLayoutItemsUpdated (this=this@entry=0x563c981856c0)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/imports/layouts/qquicklayout.cpp:854
#23 0x00007fb65404b390 in QQuickGridLayoutBase::rearrange (this=0x563c981856c0, size=...)
at /var/tmp/portage/dev-qt/qtdeclarative-5.15.1/work/qtdeclarative-everywhere-src-5.15.1/src/imports/layouts/qquicklinearlayout.cpp:473
#24 0x00007fb654048de2 in QQuickLayout::geometryChanged (this=0x563c981856c0, newGeometry=..., oldGeometry=...) at /usr/include/qt5/QtCore/qarraydata.h:236
#25 0x00007fb662d57ef2 in QQuickItem::setImplicitSize (this=this@entry=0x563c981856c0, w=w@entry=171, h=h@entry=51) at /usr/include/qt5/QtCore/qrect.h:644
The total gdb backtrace is >50000 calls deep, so this looks like an infinite recursion somewhere.
Just hit this today, polish loop and UI freeze confirmed: gcc-9.3.0-r1 glibc-2.32-r2 qtcore-5.15.1-r1 mesa-20.1.10 zoom-5.4.53350.1027-r1 I have had one successful (no crash or UI freeze) Zoom session for an hour after world update on 10/31. For me, it appears to be fixed (so far). gcc-10.2.0-r2 glibc-2.32-r2 qtcore-5.15.1-r1 mesa-20.2.1 zoom-5.4.53350.1027-r1 I have accepted the ~amd64 keyword for mesa 20.2.1 and zoom is no longer hanging. gcc-9.3.0-r1 glibc-2.32-r2 qtcore-5.15.1-r1 mesa-20.2.1 zoom-5.4.53350.1027-r1 Polish loop detected again this morning. Noticed this message in the terminal mixed with Polish loop detected: qrc:/qml/UpcomingMeetingTopBarDelegate.qml:22:5: QML RowLayout: RowLayout called polish() inside updatePolish() of RowLayout I disconnected my outlook calendar from my zoom account and it hasn't locked up again (yet) I think (a) the polish loop combined with UI freeze and (b) the crash on Q&A are two different issues... NOT FIXED Polish loop continues. Impossible to log into most meetings except after fresh restart of Qt. Previous Qt version dropped from portage. [IP-] [ ] sys-devel/gcc-9.3.0-r1:9.3.0 [IP-] [ ] sys-libs/glibc-2.32-r2:2.2 [IP-] [ ] dev-qt/qtcore-5.15.1-r1:5/5.15.1 [IP-] [ ] media-libs/mesa-20.2.1:0 [IP-] [ ] net-im/zoom-5.4.53350.1027-r1:0 Note that the polish loop is *not* the original issue reported in this bug. Zoom is a somewhat critical application these days, you may have noticed. (In reply to Jonathan Snow from comment #41) > Note that the polish loop is *not* the original issue reported in this bug. > Zoom is a somewhat critical application these days, you may have noticed. Indeed, I don't have any freeze issue. The application just crashes, maximum 1 hour between 2 crashes and most of the time it will crash minimum 10 times per hour. Consequently it's almost impossible to work with it and I have to maintain qt-5.14 ebuilds and related ebuilds in a local overlay. This also makes tests quite difficult as I have to recompile qt-5.15 stuff, and then recompile 5.14 for home working. I have not tested zoom 5.4 as it relies on an ebuild only available with qt 5.15. I'm just rebuilding my world after the recent glibc update in portage and then I'll give another try to qt-5.15, latest ~amd64 mesa and zoom 5.4. (In reply to Etienne Lorriaux from comment #42) > Indeed, I don't have any freeze issue. The application just crashes, maximum > 1 hour between 2 crashes and most of the time it will crash minimum 10 times > per hour. Consequently it's almost impossible to work with it and I have to > maintain qt-5.14 ebuilds and related ebuilds in a local overlay. > > This also makes tests quite difficult as I have to recompile qt-5.15 stuff, > and then recompile 5.14 for home working. > > I have not tested zoom 5.4 as it relies on an ebuild only available with qt > 5.15. I'm just rebuilding my world after the recent glibc update in portage > and then I'll give another try to qt-5.15, latest ~amd64 mesa and zoom 5.4. As a temporary workaround I am running Zoom with the bundled Qt libraries and have not had any problems so far on a system with Qt 5.15. Download the tarball directly from Zoom, unpack, and run with $ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./zoom I suggest you do the same. Since Zoom itself is a binary package, running it with the bundled Qt 5.12 libraries won't make much of a difference. Also, you won't have to keep Qt 5.14 around. So... I rebuilt my world without success... But.... zoom-5.4.53391.1108 seems to be stable on my laptop today, not a crash (yet???...) I don't really know if it's related to zoom update because in the mean time other packages have been updated and I've modified my ruby and python targets to limit the number of python and ruby install on my laptop, and get rid of older ones. The LD_LIBRARY_PATH work-around does work but makes assumptions so this comment improves on the provided work-around in a way that does not use the '.' (current directory) to invoke Zoom.
Ideally one prefers to have zoom able to be invoked from any directory. This can be done with a simple script:
#!/bin/bash
ZOOM_DIR=$HOME/sw/zoom/zoom-5.4.54779.1115_x86_64
LD_LIBRARY_PATH=$ZOOM_DIR:$LD_LIBRARY_PATH $ZOOM_DIR/zoom
where $HOME/sw/zoom/zoom-5.4.54779.1115_x86_64 is the top zoom directory, i.e., the executables zoom and zoom.sh should be in this directory. (The tarball untars to a top directory called 'zoom' which I renamed to be 'zoom-5.4.54779.1115_x86_64' in the above example.) This should work with any version of Zoom.
(In reply to Etienne Lorriaux from comment #44) > zoom-5.4.53391.1108 seems to be stable on my laptop today, not a crash > (yet???...) Wrong conclusion, crashed this morning in background, without any particular action. Not sure it helps any, but I have not noticed any crashes or freezes, but perhaps my usage is too light (rarely use chat, have not used Q&A). My current zoom 5.4.54779.1115 seems to have been removed from the tree, leaving 5.4.53391.1108 as highest available. I'll avoid downgrading unless something fails or a newer version shows up. mesa 20.1.10 qtcore 5.15.1-r1 qtwebengine 5.15.1 gcc 10.2.0-r3 (In reply to Jack from comment #47) > Not sure it helps any, but I have not noticed any crashes or freezes, but > perhaps my usage is too light (rarely use chat, have not used Q&A). My > current zoom 5.4.54779.1115 seems to have been removed from the tree, > leaving 5.4.53391.1108 as highest available. I'll avoid downgrading unless > something fails or a newer version shows up. > > mesa 20.1.10 > qtcore 5.15.1-r1 > qtwebengine 5.15.1 > gcc 10.2.0-r3 What desktop environment do you use? In the original reporter's log it says that it's XFCE for him. Sorry, I'm on KDE/Plasma. However, when I went to start zoom yesterday, the task bar and systray icons showed up, but not the program window itself. I downgraded to 5.4.53391.1108 and it worked fine. Not much of a test, as the meeting itself never happened, but that's not zoom's fault. I have had issues with Zoom under KDE with the last two most recent releases. With earlier releases Zoom would sometimes freeze (randomly) after a certain amount of time. The fix for me is the script in Comment 45 + still having Zoom emerged so web links work. The trick I use is to manually run the Zoom script before clicking on a Zoom link so the emerged zoom is not used. Please test if net-im/zoom-5.4.54779.1115-r1 (with USE=bundled-qt, which is enabled by default) fixes the issue. (In reply to Ulrich Müller from comment #51) > Please test if net-im/zoom-5.4.54779.1115-r1 (with USE=bundled-qt, which is > enabled by default) fixes the issue. It worked for me. I just used this version to host a meeting complete with screen sharing, etc. :-) (In reply to Ulrich Müller from comment #51) > Please test if net-im/zoom-5.4.54779.1115-r1 (with USE=bundled-qt, which is > enabled by default) fixes the issue. Thank you for your efforts. I have observed a few problems with this version * the portage version doesn't respect the custom DPI setting (I am using XFCE on a HiDPI display with a custom DPI setting of 144), i.e., the Zoom window is oversize. This problem does not exist when using Zoom downloaded directly from their servers and started with their bundled libraries. * a dependency to dev-qt/qtsql seems missing. After upgrading, emerge -av --depclean removed qtquickcontrols, qtlocation, qtscript, qtdiag, qtgraphicaleffects, qtconcurrent, and qtsql. qtsql then becomes a preserved library that also remains after running revdep-rebuild * the portage version has, so far, not crashed on me, but in my case the problem is intermittent, so I will keep observing. (In reply to Barnoid from comment #53) > Thank you for your efforts. I have observed a few problems with this version > > * the portage version doesn't respect the custom DPI setting (I am using > XFCE on a HiDPI display with a custom DPI setting of 144), i.e., the Zoom > window is oversize. This problem does not exist when using Zoom downloaded > directly from their servers and started with their bundled libraries. > > * a dependency to dev-qt/qtsql seems missing. After upgrading, emerge -av > --depclean removed qtquickcontrols, qtlocation, qtscript, qtdiag, > qtgraphicaleffects, qtconcurrent, and qtsql. qtsql then becomes a preserved > library that also remains after running revdep-rebuild > > * the portage version has, so far, not crashed on me, but in my case the > problem is intermittent, so I will keep observing. Is this with USE="bundled-qt"? Because it shouldn't have any dependencies on system Qt libs in this case. (In reply to Ulrich Müller from comment #54) > Is this with USE="bundled-qt"? Because it shouldn't have any dependencies on > system Qt libs in this case. Yes. I have been able to reproduce it on another machine. There, the missing dependencies include dev-qt/qtdeclarative-5.15.1. Here is the output after emerge depclean & @preserved-rebuild: > !!! existing preserved libs: > >>> package: dev-qt/qtdeclarative-5.15.1 > * - /usr/lib64/libQt5QuickParticles.so.5 > * - /usr/lib64/libQt5QuickParticles.so.5.15.1 > * used by /opt/zoom/QtQuick/Particles.2/libparticlesplugin.so (net-im/zoom-5.4.54779.1115-r1) > * - /usr/lib64/libQt5QmlModels.so.5 > * - /usr/lib64/libQt5QmlModels.so.5.15.1 > * - /usr/lib64/libQt5Quick.so.5 > * - /usr/lib64/libQt5Quick.so.5.15.1 > * - /usr/lib64/libQt5Qml.so.5 > * - /usr/lib64/libQt5Qml.so.5.15.1 > * - /usr/lib64/libQt5QuickShapes.so.5 > * - /usr/lib64/libQt5QuickShapes.so.5.15.1 > * used by /opt/zoom/QtQuick/Shapes/libqmlshapesplugin.so (net-im/zoom-5.4.54779.1115-r1) > >>> package: dev-qt/qtsql-5.15.1 > * - /usr/lib64/libQt5Sql.so.5 > * - /usr/lib64/libQt5Sql.so.5.15.1 > * used by /opt/zoom/QtQuick/LocalStorage/libqmllocalstorageplugin.so (net-im/zoom-5.4.54779.1115-r1) (In reply to Barnoid from comment #55) Please try again with -r2. (In reply to Ulrich Müller from comment #51) > Please test if net-im/zoom-5.4.54779.1115-r1 (with USE=bundled-qt, which is > enabled by default) fixes the issue. I'm running it today and (still) no crash up to now with +bundled-qt The only strange thing is without bundled-qt, I have my zoom icon in the tray, I can right click on it, log out exit and so on, but no way to get the window. (In reply to Etienne Lorriaux from comment #57) > (In reply to Ulrich Müller from comment #51) > > Please test if net-im/zoom-5.4.54779.1115-r1 (with USE=bundled-qt, which is > > enabled by default) fixes the issue. > > I'm running it today and (still) no crash up to now with +bundled-qt OK, closing then. Feel free to reopen if the problem should reappear. > The only strange thing is without bundled-qt, I have my zoom icon in the > tray, I can right click on it, log out exit and so on, but no way to get the > window. (In reply to Ulrich Müller from comment #56) > (In reply to Barnoid from comment #55) > > Please try again with -r2. Works like a charm, thanks a lot. The only issue remaining is that zoom from portage still doesn't scale properly on HiDPI screens with custom DIP settings (XCFC) as opposed to a version downloaded directly from zoom. I will try to figure out what causes that over the weekend and report back. You can also test with Qt 5.15.2 now that it is in tree. No other reports of runtime issues with 5.15.1 though. (In reply to Barnoid from comment #59) > The only issue remaining is that zoom from portage still doesn't scale > properly on HiDPI screens with custom DIP settings (XCFC) as opposed to a > version downloaded directly from zoom. I will try to figure out what causes > that over the weekend and report back. How do you start the version downloaded from upstream? With ZoomLauncher or directly by executing the zoom binary? Starting with net-im/zoom-5.4.54779.1115-r1, we start zoom via upstream's ZoomLauncher while in previous versions we used our own shell wrapper. One of the differences is that ZoomLauncher passes QT_AUTO_SCREEN_SCALE_FACTOR=1 in the environment. See https://doc.qt.io/qt-5/highdpi.html for an explanation. If that turns out to be detrimental, we could always revert to our own wrapper script. (In reply to Ulrich Müller from comment #61) > How do you start the version downloaded from upstream? With ZoomLauncher or > directly by executing the zoom binary? > > Starting with net-im/zoom-5.4.54779.1115-r1, we start zoom via upstream's > ZoomLauncher while in previous versions we used our own shell wrapper. One > of the differences is that ZoomLauncher passes QT_AUTO_SCREEN_SCALE_FACTOR=1 > in the environment. See https://doc.qt.io/qt-5/highdpi.html for an > explanation. > > If that turns out to be detrimental, we could always revert to our own > wrapper script. Indeed, this is the culprit. No need to revert though - this seems to caused by my XFCE setup. In the interest that this helps someone else, here we go: Since XFCE doesn't support HiDPI very well, I use a custom DPI setting (144dpi) without window scaling on a 2x4K system. Starting Zoom via ZoomLauncher causes an oversized Zoom window both for the downloaded and the -r2 portage version. Starting zoom directly works fine. On another system (1x4K, also XFCE) 2x window scaling is used at the standard DPI. On that system, QT_SCALE_FACTOR is set to 2 to get Qt applications to display properly. This configuration works fine with the version in portage the one downloaded from Zoom, and the executables zoom and ZoomLauncher. (In reply to Barnoid from comment #62) IMHO, sufficient reason to revert to the shell wrapper. Besides, there haven't been any complaints about it in previous versions. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=de94b5f4f881df01cb0639491c4dcc8e428568ad commit de94b5f4f881df01cb0639491c4dcc8e428568ad Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2020-11-28 13:01:35 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2020-11-28 13:10:01 +0000 net-im/zoom: Revert from ZoomLauncher to shell wrapper. Bug: https://bugs.gentoo.org/750437#c59 Package-Manager: Portage-3.0.10, Repoman-3.0.2 Signed-off-by: Ulrich Müller <ulm@gentoo.org> .../{zoom-5.4.54779.1115-r2.ebuild => zoom-5.4.54779.1115-r3.ebuild} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (In reply to Andreas Sturmlechner from comment #60) > You can also test with Qt 5.15.2 now that it is in tree. No other reports of > runtime issues with 5.15.1 though. No luck with 5.15.2 either. I guess Qt packages have subslots for a reason, though from a purist's point of view, the same library soname (.5) should guarantee a backward-compatible ABI. (In reply to Ulrich Müller from comment #65) > [...] from a purist's point of view, the same library soname (.5) should > guarantee a backward-compatible ABI. In fact, Qt upstream makes this promise: "Minor releases are backwards binary and source compatible." https://wiki.qt.io/Qt-Version-Compatibility Subslots are there for one reason:
> <slots>
> <subslots>
> Must only be used by packages that are known to use private parts of the Qt API.
> </subslots>
> </slots>
(In reply to Andreas Sturmlechner from comment #67) > Subslots are there for one reason: > > > <slots> > > <subslots> > > Must only be used by packages that are known to use private parts of the Qt API. > > </subslots> > > </slots> We can only guess because it's closed source, but Zoom might actually be using it: $ readelf -s -W /opt/zoom/zoom | grep Qt_5_PRIVATE 704: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN23QQuickFramebufferObject8RendererD2Ev@Qt_5_PRIVATE_API (29) 1459: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND _ZTIN23QQuickFramebufferObject8RendererE@Qt_5_PRIVATE_API (29) 1469: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN23QQuickFramebufferObject8Renderer11synchronizeEPS_@Qt_5_PRIVATE_API (29) 1839: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN23QQuickFramebufferObject8RendererC2Ev@Qt_5_PRIVATE_API (29) |
