Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 750437 - net-im/zoom-5.3.472687.1012 crashing since recent world update
Summary: net-im/zoom-5.3.472687.1012 crashing since recent world update
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Ulrich Müller
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: qt-5.15
  Show dependency tree
 
Reported: 2020-10-20 15:26 UTC by Etienne Lorriaux
Modified: 2020-11-28 22:33 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Ebuilds which have been updated (genlop.log,2.91 KB, text/plain)
2020-10-20 15:29 UTC, Etienne Lorriaux
Details
Emerge info (emerge-info.log,5.61 KB, text/plain)
2020-10-20 15:30 UTC, Etienne Lorriaux
Details
Terminal output after a crash (zoomcrash.log,27.51 KB, text/plain)
2020-10-20 15:31 UTC, Etienne Lorriaux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Etienne Lorriaux 2020-10-20 15:26:58 UTC
Since 2 days zoom keeps crashing on my laptop, most of the time when clicking on tabs, sometimes just after a notification arrives when someone talks to me in the chat.

This problem appeared recently after world updates. I will provide the list of possible guilties attached the the bug.
I have already tried to:
- downgrade to zoom 5.3.469451.0927: without success
- use bundled libjpeg-turbo (as it is a recent update) instead of system one: without success. I could not revert libjpeg-turbo update as the previous version ebuild disappeared.

I'm also strongly suspecting qt*-1.15 update but I can't test it as former ebuilds are not there anymore.

I would be curious to know if I'm the only one to have this issue with an up to date gentoo system.

Reproducible: Sometimes

Steps to Reproduce:
- Switching between Chat and Meetings tabs sometimes trigger the crash (Meetings button is really a good candidate generally)
- Sometimes it crashes without any particular event
- Switching between windows?
- Sometimes it crashes when a message arrives, I don't see the message nor the notification but if I reconnect right after I can see that I have a message.
Actual Results:  
Application crashes

Expected Results:  
Application does not crash
Comment 1 Etienne Lorriaux 2020-10-20 15:29:45 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)
Comment 2 Etienne Lorriaux 2020-10-20 15:30:17 UTC
Created attachment 667556 [details]
Emerge info
Comment 3 Etienne Lorriaux 2020-10-20 15:31:08 UTC
Created attachment 667559 [details]
Terminal output after a crash
Comment 4 Daniel Pouzzner 2020-10-20 16:29:32 UTC
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
Comment 5 Etienne Lorriaux 2020-10-20 16:42:54 UTC
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?
Comment 6 Daniel Pouzzner 2020-10-20 17:07:41 UTC
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.
Comment 7 Etienne Lorriaux 2020-10-21 09:24:35 UTC
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.
Comment 8 Andreas K. Hüttel gentoo-dev 2020-10-21 10:14:05 UTC
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.)
Comment 9 Andreas K. Hüttel gentoo-dev 2020-10-21 10:17:51 UTC
(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...)
Comment 10 Etienne Lorriaux 2020-10-21 10:20:48 UTC
(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.
Comment 11 Ulrich Müller gentoo-dev 2020-10-21 11:15:30 UTC
(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.
Comment 12 Ulrich Müller gentoo-dev 2020-10-21 11:21:35 UTC
(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.
Comment 13 Etienne Lorriaux 2020-10-21 11:41:34 UTC
(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.
Comment 14 Ulrich Müller gentoo-dev 2020-10-21 11:51:53 UTC
(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.
Comment 15 Etienne Lorriaux 2020-10-21 12:11:41 UTC
(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.
Comment 16 Andreas K. Hüttel gentoo-dev 2020-10-21 12:18:57 UTC
(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... :)
Comment 17 Barnoid 2020-10-22 05:49:54 UTC
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.
Comment 18 Barnoid 2020-10-22 06:00:31 UTC
(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.
Comment 19 Paul Gover 2020-10-22 10:19:17 UTC
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.)
Comment 20 Ulrich Müller gentoo-dev 2020-10-27 11:12:00 UTC
Is this still a problem with zoom-5.4.53268.1025?
Comment 21 Devrin Talen 2020-10-27 15:30:15 UTC
Yes, I am able to reproduce this issue with 5.4.53268.1025 and both mesa-20.1.10/mesa-20.2.1.
Comment 22 Devrin Talen 2020-10-27 15:35:17 UTC
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.
Comment 23 Ulrich Müller gentoo-dev 2020-10-27 18:13:32 UTC
(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.
Comment 24 Jesse Harris 2020-10-28 13:42:38 UTC
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.
Comment 25 Etienne Lorriaux 2020-10-28 13:46:51 UTC
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
Comment 26 Andreas K. Hüttel gentoo-dev 2020-10-28 18:23:24 UTC
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
Comment 27 Etienne Lorriaux 2020-10-28 18:26:34 UTC
gcc-9.3.0-r1 , glibc-2.31-r6 and affected.
Comment 28 Daniel Pouzzner 2020-10-28 18:29:47 UTC
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.
Comment 29 Ulrich Müller gentoo-dev 2020-10-28 21:27:48 UTC
gcc-9.3.0-r1, glibc-2.32-r2, not affected
Comment 30 Jesse Harris 2020-10-28 21:37:22 UTC
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.
Comment 31 Barnoid 2020-10-29 00:02:24 UTC
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).
Comment 32 Jesse Harris 2020-10-29 00:19:53 UTC
(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.
Comment 33 Andreas K. Hüttel gentoo-dev 2020-10-29 10:36:40 UTC
(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.
Comment 34 Andreas K. Hüttel gentoo-dev 2020-10-29 10:42:33 UTC
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
Comment 35 Andreas K. Hüttel gentoo-dev 2020-10-29 10:53:12 UTC
(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.
Comment 36 Jari_42 2020-11-02 14:58:45 UTC
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
Comment 37 O. William McClung 2020-11-02 15:20:40 UTC
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
Comment 38 Jesse Harris 2020-11-03 23:43:58 UTC
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
Comment 39 Jesse Harris 2020-11-04 23:22:52 UTC
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)
Comment 40 Andreas K. Hüttel gentoo-dev 2020-11-05 00:33:10 UTC
I think 

(a) the polish loop combined with UI freeze and 
(b) the crash on Q&A 

are two different issues...
Comment 41 Jonathan Snow 2020-11-09 14:13:20 UTC
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.
Comment 42 Etienne Lorriaux 2020-11-10 14:38:06 UTC
(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.
Comment 43 Barnoid 2020-11-10 15:12:10 UTC
(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.
Comment 44 Etienne Lorriaux 2020-11-17 18:07:59 UTC
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.
Comment 45 Paul Preney 2020-11-17 20:36:59 UTC
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.
Comment 46 Etienne Lorriaux 2020-11-18 11:17:02 UTC
(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.
Comment 47 Jack 2020-11-18 18:50:31 UTC
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
Comment 48 Ulrich Müller gentoo-dev 2020-11-19 07:54:15 UTC
(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.
Comment 49 Jack 2020-11-19 15:43:11 UTC
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.
Comment 50 Paul Preney 2020-11-19 16:02:15 UTC
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.
Comment 51 Ulrich Müller gentoo-dev 2020-11-25 11:20:25 UTC
Please test if net-im/zoom-5.4.54779.1115-r1 (with USE=bundled-qt, which is enabled by default) fixes the issue.
Comment 52 Paul Preney 2020-11-25 18:58:33 UTC
(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. :-)
Comment 53 Barnoid 2020-11-26 01:51:43 UTC
(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.
Comment 54 Ulrich Müller gentoo-dev 2020-11-26 09:20:44 UTC
(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.
Comment 55 Barnoid 2020-11-26 11:46:24 UTC
(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)
Comment 56 Ulrich Müller gentoo-dev 2020-11-26 15:40:19 UTC
(In reply to Barnoid from comment #55)

Please try again with -r2.
Comment 57 Etienne Lorriaux 2020-11-26 15:47:30 UTC
(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.
Comment 58 Ulrich Müller gentoo-dev 2020-11-26 20:03:41 UTC
(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.
Comment 59 Barnoid 2020-11-27 01:02:26 UTC
(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.
Comment 60 Andreas Sturmlechner gentoo-dev 2020-11-27 09:39:28 UTC
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.
Comment 61 Ulrich Müller gentoo-dev 2020-11-27 10:52:20 UTC
(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.
Comment 62 Barnoid 2020-11-28 04:58:42 UTC
(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.
Comment 63 Ulrich Müller gentoo-dev 2020-11-28 12:57:08 UTC
(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.
Comment 64 Larry the Git Cow gentoo-dev 2020-11-28 13:10:54 UTC
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(-)
Comment 65 Ulrich Müller gentoo-dev 2020-11-28 13:45:44 UTC
(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.
Comment 66 Ulrich Müller gentoo-dev 2020-11-28 13:52:37 UTC
(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
Comment 67 Andreas Sturmlechner gentoo-dev 2020-11-28 21:36:29 UTC
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>
Comment 68 Ulrich Müller gentoo-dev 2020-11-28 22:33:39 UTC
(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)