Floating point exception while resizing a window on Debian Buster #846
Labels
bug
Something isn't working
Comments
|
I have seen both reports, but these were for the old versions and both are closed. It happened once and I did not manage to reproduce it. |
|
The stack dump unfortunately doesn't tell us where the issue is. So please try to reproduce this. We'll need to add some debug code once we have a decent way of testing things. |
|
This has been quiet for quite some time. Closing. |
|
Hello Pierre, I'm having this issue frequently on Red Hat Enterprise Linux Server release 7.7 (Maipo) running on vmware. Tried both 1.8.0 and 1.9.0. Was already mentioned in 2015 : https://bugzilla.redhat.com/show_bug.cgi?id=1282360 I tried to understand by attaching a gdb to 1.9.0 and it looks like a division by zero, you find below the gdb output, stack trace, and a disass showing an idiv %ebx with rbx zero. I can produce it by opening a server, inside the server open a viewer to another server, inside that nested viewer I use an emacs and select some text. Maybe you have an idea or you can suggest further experiments ? |
|
The failing insn can be found above : |
|
vmware is not involved, just had the issue again on a non-virtualized workstation |
|
Getting closer with debuginfo installed. gdb shows this is not the case One frame up this is a copy construct that seems to have noticed the empty rectangle: but it called changed.get_rects anyway: |
|
Right, the system assumes it won't be fed empty rects. So the bug is in |
|
Thanks, Pierre.
I’m on a breakpoint now in add_changed adding a zero x-dimension rect :
void vncAddChanged(int scrIdx, const struct UpdateRect *extents,
int nRects, const struct UpdateRect *rects)
{
Region reg;
reg.setExtentsAndOrderedRects((const ShortRect*)extents,
nRects, (const ShortRect*)rects);
desktop[scrIdx]->add_changed(reg);
}
Three non-singular rects go in :
(gdb) p nRects
$28 = 3
…
(gdb) p rects[0]
$31 = {
x1 = 41,
y1 = 24,
x2 = 1287,
y2 = 48
}
(gdb) p rects[1]
$32 = {
x1 = 41,
y1 = 48,
x2 = 48,
y2 = 1185
}
(gdb) p rects[2]
$33 = {
x1 = 1280,
y1 = 48,
x2 = 1287,
y2 = 1185
}
And the resulting reg.xrgn.extents is x-singular:
(gdb) p *reg.xrgn
$36 = {
size = 3,
numRects = 3,
rects = 0xe4dff0,
extents = {
x1 = 1287,
x2 = 1287,
y1 = 24,
y2 = 1185
}
}
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
We're mostly interested in where it comes from. Can you do a backtrace where that hits? |
|
Hi. I am the person who opened this issue. |
|
Sorry, was busy for a while, this is the backtrace where add_changed was called with extents.x1=extents.x2 :
(gdb) p *region.xrgn
$3 = (
size => 3,
numRects => 3,
rects => 0xe4dff0,
extents => (
x1 => 1287,
x2 => 1287,
y1 => 24,
y2 => 1185
)
)
(gdb) bt
#0 rfb::VNCServerST::add_changed (this=0x8a9910, region=...) at /usr/src/debug/tigervnc-1.8.0/common/rfb/VNCServerST.cxx:420
#1 0x000000000052a07e in XserverDesktop::add_changed (this=<optimized out>, region=...) at XserverDesktop.cc:383
#2 0x0000000000520dc7 in vncAddChanged (scrIdx=0, extents=extents@entry=0xe4dfb0, nRects=3, rects=0xe4e970) at vncExtInit.cc:368
#3 0x0000000000525252 in add_changed (reg=0xe4dfb0, pScreen=<optimized out>) at vncHooks.c:371
#4 vncHooksPolyFillRect (pDrawable=0xc29430, pGC=0x9219a0, nrects=3, rects=0xca7c60) at vncHooks.c:1810
#5 0x00000000004daaa6 in damagePolyFillRect (pDrawable=0xc29430, pGC=0x9219a0, nRects=3, pRects=<optimized out>) at damage.c:1204
#6 0x00000000005aee17 in miPaintWindow (pWin=<optimized out>, prgn=<optimized out>, what=<optimized out>) at miexpose.c:540
#7 0x00000000005aeb1d in miWindowExposures (pWin=0xc29430, prgn=0xca8980) at miexpose.c:394
#8 0x000000000051ca89 in compWindowExposures (pWin=0xc29430, reg=0xca8980) at compwindow.c:315
#9 0x00000000005bbf5c in miHandleValidateExposures (pWin=0x9256f0) at miwindow.c:226
#10 0x0000000000457055 in xf86SetRootClip (pScreen=pScreen@entry=0x89dc80, enable=enable@entry=1) at xvnc.c:1102
#11 0x0000000000457368 in vncRandRScreenSetSize (pScreen=0x89dc80, width=1920, height=1185, mmWidth=508, mmHeight=<optimized out>) at xvnc.c:1194
#12 0x0000000000522ac8 in vncHooksRandRScreenSetSize (pScreen=0x89dc80, width=<optimized out>, height=<optimized out>, mmWidth=508, mmHeight=314)
at vncHooks.c:929
#13 0x000000000052ae31 in XserverDesktop::setScreenLayout (this=0x8a9800, fb_width=1920, fb_height=1185, layout=...) at XserverDesktop.cc:630
#14 0x000000000054a408 in rfb::VNCSConnectionST::setDesktopSize (this=0xcb06e0, fb_width=1920, fb_height=1185, layout=...)
at /usr/src/debug/tigervnc-1.8.0/common/rfb/VNCSConnectionST.cxx:643
#15 0x000000000054029c in rfb::SMsgReader::readSetDesktopSize (this=0xca85e0) at /usr/src/debug/tigervnc-1.8.0/common/rfb/SMsgReader.cxx:132
#16 0x0000000000549e07 in rfb::VNCSConnectionST::processMessages (this=0xcb06e0)
at /usr/src/debug/tigervnc-1.8.0/common/rfb/VNCSConnectionST.cxx:168
#17 0x000000000052a2ce in XserverDesktop::handleSocketEvent (this=this@entry=0x8a9800, fd=fd@entry=12, sockserv=0x8a9920, read=read@entry=true,
write=write@entry=false) at XserverDesktop.cc:459
#18 0x000000000052a3bc in XserverDesktop::handleSocketEvent (this=0x8a9800, fd=12, read=<optimized out>, write=<optimized out>)
at XserverDesktop.cc:408
#19 0x00000000005c7632 in ospoll_wait (ospoll=0x893040, timeout=<optimized out>) at ospoll.c:651
#20 0x00000000005c116b in WaitForSomething (are_ready=0) at WaitFor.c:208
#21 0x000000000057382c in Dispatch () at dispatch.c:421
#22 0x000000000057799a in dix_main (argc=20, argv=0x7fffffff5cd8, envp=<optimized out>) at main.c:276
#23 0x00007ffff4f3b545 in __libc_start_main (main=0x454e20 <main>, argc=20, argv=0x7fffffff5cd8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffff5cc8) at ../csu/libc-start.c:266
#24 0x000000000045630e in _start ()
From: Pierre Ossman (Work account) <notifications@github.com>
Sent: 14 February 2020 15:32
To: TigerVNC/tigervnc <tigervnc@noreply.github.com>
Cc: VAN VLIERBERGHE Stef <stef.van-vlierberghe@eurocontrol.int>; Comment <comment@noreply.github.com>
Subject: Re: [TigerVNC/tigervnc] Floating point exception while resizing a window on Debian Buster (#846)
We're mostly interested in where it comes from. Can you do a backtrace where that hits?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#846?email_source=notifications&email_token=AH5WRHHOTTG26AACAJVD7STRC2TMRA5CNFSM4HYRMENKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELZGYGY#issuecomment-586312731>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH5WRHGDEEE7227BJHIYZNDRC2TMRANCNFSM4HYRMENA>.
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
Another difficulty is that I still cannot systematically reproduce the issue, sometimes it crashes after a few seconds sometimes it survives…
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
Hi Pierre,
Can’t make it crash any longer, but I can easily get in gdb on a breakpoint which shows wrong extents :
(gdb) p *reg
$109 = {
extents = {
x1 = 1332,
y1 = 36,
x2 = 1332,
y2 = 36
},
data = 0x8561c0 <RegionEmptyData>
}
Maybe adding some self-checking code could help identify the origins of such singular rectangles ?
Otherwise, if you can’t figure out where such values originate, an extra condition to skip singular values could avoid the crashes.
This is not ideal, I suppose it would be nice and more efficient to never create such rectangles, but it is surely better than the divide by zero…
(gdb) bt
#0 vncHooksPolyFillRect (pDrawable=0xc26630, pGC=0x9219a0, nrects=1, rects=0xbdbe18) at vncHooks.c:1808
#1 0x00000000004daaa6 in damagePolyFillRect (pDrawable=0xc26630, pGC=0x9219a0, nRects=1, pRects=<optimized out>) at damage.c:1204
#2 0x00000000004c6315 in miColorRects (pDst=pDst@entry=0xc99c80, color=color@entry=0xbdbe10, nRect=nRect@entry=1, rects=rects@entry=0xbdbe18,
xoff=xoff@entry=0, yoff=yoff@entry=0, pClipPict=0xc99c80) at mirect.c:77
#3 0x00000000004c63b0 in miCompositeRects (op=<optimized out>, pDst=0xc99c80, color=0xbdbe10, nRect=1, rects=0xbdbe18) at mirect.c:102
#4 0x00000000004ccc09 in ProcRenderFillRectangles (client=0xbd6000) at render.c:1414
#5 0x0000000000573a9d in Dispatch () at dispatch.c:478
#6 0x000000000057799a in dix_main (argc=20, argv=0x7fffffff5cd8, envp=<optimized out>) at main.c:276
#7 0x00007ffff4f3b545 in __libc_start_main (main=0x454e20 <main>, argc=20, argv=0x7fffffff5cd8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffff5cc8) at ../csu/libc-start.c:266
#8 0x000000000045630e in _start ()
From: Pierre Ossman (Work account) <notifications@github.com>
Sent: 14 February 2020 15:32
To: TigerVNC/tigervnc <tigervnc@noreply.github.com>
Cc: VAN VLIERBERGHE Stef <stef.van-vlierberghe@eurocontrol.int>; Comment <comment@noreply.github.com>
Subject: Re: [TigerVNC/tigervnc] Floating point exception while resizing a window on Debian Buster (#846)
We're mostly interested in where it comes from. Can you do a backtrace where that hits?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#846?email_source=notifications&email_token=AH5WRHHOTTG26AACAJVD7STRC2TMRA5CNFSM4HYRMENKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELZGYGY#issuecomment-586312731>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH5WRHGDEEE7227BJHIYZNDRC2TMRANCNFSM4HYRMENA>.
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
Hi Pierre,
FYI, we are also getting feedback from RedHat support about this issue :
The coredumps match exactly the issue reported at
https://bugzilla.redhat.com/show_bug.cgi?id=1753158 and
https://bugzilla.redhat.com/show_bug.cgi?id=1670342
(tigervnc crashes whenever xfreerdp client is closed (faults in DamageUnregister unless backingstore is disabled))
A fix should be available soon, and requires updating to
xorg-x11-server-1.20.4-9.el7 (released) and tigervnc-1.8.0-18.el7 (not yet released).
Until the new tigervnc is released, the know workarounds are to downgrade to tigervnc-1.8.0-5.el7 or use the -bs option, for example:
# vncserver :5 -bs
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
(tigervnc crashes whenever xfreerdp client > is closed (faults in
DamageUnregister
unless backingstore is disabled))
That’s interesting because it sounds like #368, which we’ve never been able
to pin down the exact cause of.
-brian
On Fri, Feb 14, 2020 at 4:00 PM stefvanvlierberghe ***@***.***> wrote:
Hi Pierre,
FYI, we are also getting feedback from RedHat support about this issue :
The coredumps match exactly the issue reported at
https://bugzilla.redhat.com/show_bug.cgi?id=1753158 and
https://bugzilla.redhat.com/show_bug.cgi?id=1670342
(tigervnc crashes whenever xfreerdp client is closed (faults in
DamageUnregister unless backingstore is disabled))
A fix should be available soon, and requires updating to
xorg-x11-server-1.20.4-9.el7 (released) and tigervnc-1.8.0-18.el7 (not yet
released).
Until the new tigervnc is released, the know workarounds are to downgrade
to tigervnc-1.8.0-5.el7 or use the -bs option, for example:
# vncserver :5 -bs
____
This message and any files transmitted with it are legally privileged and
intended for the sole use of the individual(s) or entity to whom they are
addressed. If you are not the intended recipient, please notify the sender
by reply and delete the message and any attachments from your system. Any
unauthorised use or disclosure of the content of this message is strictly
prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal
commitment on the part of EUROCONTROL, unless it is confirmed by
appropriately signed hard copy.
Any views expressed in this message are those of the sender.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#846?email_source=notifications&email_token=AB45M3J2TN5VM7TS6OZJNELRC4A7TA5CNFSM4HYRMENKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL2NKGI#issuecomment-586470681>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB45M3IQHHGXYAWEOMJLUQLRC4A7TANCNFSM4HYRMENA>
.
--
Sent from Gmail Mobile
|
|
Does this patch help: diff --git a/unix/xserver/hw/vnc/vncHooks.c b/unix/xserver/hw/vnc/vncHooks.c
index 5cf2c0d1..d3428788 100644
--- a/unix/xserver/hw/vnc/vncHooks.c
+++ b/unix/xserver/hw/vnc/vncHooks.c
@@ -388,6 +388,8 @@ static inline void add_changed(ScreenPtr pScreen, RegionPtr reg)
vncHooksScreenPtr vncHooksScreen = vncHooksScreenPrivate(pScreen);
if (vncHooksScreen->ignoreHooks)
return;
+ if (REGION_NIL(reg))
+ return;
vncAddChanged(pScreen->myNum,
(const struct UpdateRect*)REGION_EXTENTS(pScreen, reg),
REGION_NUM_RECTS(reg),
@@ -400,6 +402,8 @@ static inline void add_copied(ScreenPtr pScreen, RegionPtr dst,
vncHooksScreenPtr vncHooksScreen = vncHooksScreenPrivate(pScreen);
if (vncHooksScreen->ignoreHooks)
return;
+ if (REGION_NIL(dst))
+ return;
vncAddCopied(pScreen->myNum,
(const struct UpdateRect*)REGION_EXTENTS(pScreen, dst),
REGION_NUM_RECTS(dst),
@@ -562,8 +566,7 @@ static void vncHooksCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
(*pScreen->CopyWindow) (pWin, ptOldOrg, pOldRegion);
- if (REGION_NOTEMPTY(pScreen, &copied))
- add_copied(pScreen, &copied, dx, dy);
+ add_copied(pScreen, &copied, dx, dy);
REGION_UNINIT(pScreen, &copied);
REGION_UNINIT(pScreen, &screen_rgn);
@@ -807,8 +810,7 @@ static void vncHooksComposite(CARD8 op, PicturePtr pSrc, PicturePtr pMask,
(*ps->Composite)(op, pSrc, pMask, pDst, xSrc, ySrc,
xMask, yMask, xDst, yDst, width, height);
- if (REGION_NOTEMPTY(pScreen, &changed))
- add_changed(pScreen, &changed);
+ add_changed(pScreen, &changed);
REGION_UNINIT(pScreen, &changed);
@@ -910,8 +912,7 @@ static void vncHooksGlyphs(CARD8 op, PicturePtr pSrc, PicturePtr pDst,
(*ps->Glyphs)(op, pSrc, pDst, maskFormat, xSrc, ySrc, nlists, lists, glyphs);
- if (REGION_NOTEMPTY(pScreen, changed))
- add_changed(pScreen, changed);
+ add_changed(pScreen, changed);
REGION_DESTROY(pScreen, changed);
@@ -933,8 +934,7 @@ static void vncHooksCompositeRects(CARD8 op, PicturePtr pDst,
(*ps->CompositeRects)(op, pDst, color, nRect, rects);
- if (REGION_NOTEMPTY(pScreen, changed))
- add_changed(pScreen, changed);
+ add_changed(pScreen, changed);
REGION_DESTROY(pScreen, changed);
@@ -1001,8 +1001,7 @@ static void vncHooksTrapezoids(CARD8 op, PicturePtr pSrc, PicturePtr pDst,
(*ps->Trapezoids)(op, pSrc, pDst, maskFormat, xSrc, ySrc, ntrap, traps);
- if (REGION_NOTEMPTY(pScreen, &changed))
- add_changed(pScreen, &changed);
+ add_changed(pScreen, &changed);
REGION_UNINIT(pScreen, &changed);
@@ -1067,8 +1066,7 @@ static void vncHooksTriangles(CARD8 op, PicturePtr pSrc, PicturePtr pDst,
(*ps->Triangles)(op, pSrc, pDst, maskFormat, xSrc, ySrc, ntri, tris);
- if (REGION_NOTEMPTY(pScreen, &changed))
- add_changed(pScreen, &changed);
+ add_changed(pScreen, &changed);
REGION_UNINIT(pScreen, &changed);
@@ -1128,8 +1126,7 @@ static void vncHooksTriStrip(CARD8 op, PicturePtr pSrc, PicturePtr pDst,
(*ps->TriStrip)(op, pSrc, pDst, maskFormat, xSrc, ySrc, npoint, points);
- if (REGION_NOTEMPTY(pScreen, &changed))
- add_changed(pScreen, &changed);
+ add_changed(pScreen, &changed);
REGION_UNINIT(pScreen, &changed);
@@ -1187,8 +1184,7 @@ static void vncHooksTriFan(CARD8 op, PicturePtr pSrc, PicturePtr pDst,
(*ps->TriFan)(op, pSrc, pDst, maskFormat, xSrc, ySrc, npoint, points);
- if (REGION_NOTEMPTY(pScreen, &changed))
- add_changed(pScreen, &changed);
+ add_changed(pScreen, &changed);
REGION_UNINIT(pScreen, &changed);
@@ -1509,13 +1505,11 @@ static RegionPtr vncHooksCopyArea(DrawablePtr pSrc, DrawablePtr pDst,
ret = (*pGC->ops->CopyArea) (pSrc, pDst, pGC, srcx, srcy, w, h, dstx, dsty);
- if (REGION_NOTEMPTY(pScreen, &dst))
- add_copied(pGC->pScreen, &dst,
- dstx + pDst->x - srcx - pSrc->x,
- dsty + pDst->y - srcy - pSrc->y);
+ add_copied(pGC->pScreen, &dst,
+ dstx + pDst->x - srcx - pSrc->x,
+ dsty + pDst->y - srcy - pSrc->y);
- if (REGION_NOTEMPTY(pScreen, &changed))
- add_changed(pGC->pScreen, &changed);
+ add_changed(pGC->pScreen, &changed);
REGION_UNINIT(pGC->pScreen, &dst);
REGION_UNINIT(pGC->pScreen, &src);It should cover the simple cases more consistently at least. |
|
Hi Pierre,
Thanks for your help, but unfortunately I have not been able any more to reproduce the issue, it went away as mysteriously as it came…
I also failed to recompile Xvnc from sources, I made a request to get the rhel7 X sources installed which will hopefully make this possible.
Will try your patch if/when I get the issue back.
P.S. I still think It would be good practice to check that x2 != x1 before dividing by (x2-x1), maybe you can think of some “central” place where you could assert this invariant.
All the best,
Stef
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
I will try to test it with RTL Compiler next week since that was a very
reproducible crash.
…On Thu, Feb 27, 2020 at 1:35 PM stefvanvlierberghe ***@***.***> wrote:
Hi Pierre,
Thanks for your help, but unfortunately I have not been able any more to
reproduce the issue, it went away as mysteriously as it came…
I also failed to recompile Xvnc from sources, I made a request to get the
rhel7 X sources installed which will hopefully make this possible.
Will try your patch if/when I get the issue back.
P.S. I still think It would be good practice to check that x2 != x1 before
dividing by (x2-x1), maybe you can think of some “central” place where you
could assert this invariant.
All the best,
Stef
____
This message and any files transmitted with it are legally privileged and
intended for the sole use of the individual(s) or entity to whom they are
addressed. If you are not the intended recipient, please notify the sender
by reply and delete the message and any attachments from your system. Any
unauthorised use or disclosure of the content of this message is strictly
prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal
commitment on the part of EUROCONTROL, unless it is confirmed by
appropriately signed hard copy.
Any views expressed in this message are those of the sender.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#846?email_source=notifications&email_token=AB45M3LRLEHNEZG2CXORJ4LRFABVJA5CNFSM4HYRMENKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENFOKRY#issuecomment-592110919>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB45M3JQNNVS6ZPBXACST6DRFABVJANCNFSM4HYRMENA>
.
|
|
Finally got this patch built from source on rhel7.7, took me 7 hours, if you are not familiar with building X from source then this is not an easy job. I ended up with the ugly contraption below, but at least I can use it now. We are not yet capable of reproducing the issue but one team member if getting it frequently, so hopefully we will find that this patched Xvnc no longer suffers from the SIGSEGV. We hope you and Redhat can work together to produce a fixed rpm, because the below is really a bit of a mess. ~vvl/tigervnc/PAD is the patch you provided above. Any advise about how to get a cleaner build procedure or official RedHat rpm is welcome. |
|
Great. Let us know how testing goes. |
|
Hi Pierre,
So far no more issues with the zero dimension divide by zero.
We did hit another issue
(EE)
(EE) Backtrace:
(EE) 0: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (OsSigHandler+0x29) [0x5c3169]
(EE) 1: /lib64/libpthread.so.0 (_L_unlock_13+0x34) [0x7ffff7763663]
(EE) 2: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (DamageUnregister+0x10) [0x4d27f0]
(EE) 3: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (compSetParentPixmap+0x37) [0x517117]
(EE) 4: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (compFreeClientWindow+0x201) [0x517381]
(EE) 5: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (FreeCompositeClientWindow+0x9) [0x5120a9]
(EE) 6: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (doFreeResource+0x62) [0x595172]
(EE) 7: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (FreeResource+0xde) [0x595cae]
(EE) 8: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (compUnredirectWindow+0xb1) [0x5167b1]
(EE) 9: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (compChangeWindowAttributes+0x193) [0x513233]
(EE) 10: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (compDestroyWindow+0x179) [0x514c99]
(EE) 11: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (damageDestroyWindow+0x9e) [0x4d2a7e]
(EE) 12: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (DbeDestroyWindow+0xd0) [0x487670]
(EE) 13: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (present_destroy_window+0x24e) [0x4ccc0e]
(EE) 14: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (FreeWindowResources+0x114) [0x5999e4]
(EE) 15: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (DeleteWindow+0x236) [0x59c686]
(EE) 16: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (doFreeResource+0x62) [0x595172]
(EE) 17: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (FreeResource+0xde) [0x595cae]
(EE) 18: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (ProcDestroyWindow+0x77) [0x56cd77]
(EE) 19: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (Dispatch+0x31d) [0x57221d]
(EE) 20: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (dix_main+0x38a) [0x575f2a]
(EE) 21: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7ffff4e19545]
(EE) 22: /auto/local_build/dhws028/disk1/vnc/exec_prefix/bin/Xvnc (_start+0x29) [0x4568ce]
We also noticed that the above was frequently triggered when using other viewers running on Mac, but also triggered (just once) using tiger vncviewer.
The above seems to match : see : https://bugzilla.redhat.com/show_bug.cgi?id=1438898
So I suspect redhat has a patch in their tigervnc for that which was not applied in their x server sources.
I also managed to rebuild their rpm from source with your patch (with a few less of the factorized/now obsolete checks before the calls to the 2 central checking procedures be removed).
This also worked ok and did not yet reproduce the issue above, so rebuilding vnc from source on redhat should also include the redhat patches (which can be extracted from their src.rpm).
After having seen your patch I can’t imagine how it could do harm, so looks safe to commit and hope it finds its way to the redhat rpm.
Thanks for your help, and good health to you.
____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
Hi Pierre,
That other issue wasn’t produced again since we used a rebuild of the tigervnc-1.8.0-19.el7.src.rpm with your patch added.
Also we do have libjpeg-turbo installed, so don’t see the link with #939<#939>
rpm -ql libjpeg-turbo-1.2.90-8.el7.x86_64
/usr/lib64/libjpeg.so.62
/usr/lib64/libjpeg.so.62.1.0
All the best,
Stef
From: Pierre Ossman (Work account) <notifications@github.com>
Sent: 20 April 2020 08:58
To: TigerVNC/tigervnc <tigervnc@noreply.github.com>
Cc: VAN VLIERBERGHE Stef <stef.van-vlierberghe@eurocontrol.int>; Comment <comment@noreply.github.com>
Subject: Re: [TigerVNC/tigervnc] Floating point exception while resizing a window on Debian Buster (#846)
That looks like #939<#939>, so let's please discuss that issue there. It is currently stalled waiting for a test case.
Thank you for testing the patch for this issue. I've committed it as f59e964<f59e964> so this should be fixed once we roll out a new release.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#846 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH5WRHFB5ZCOAO6SA4ZFTGTRNPW7VANCNFSM4HYRMENA>.
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
Sorry, wrong issue. It was supposed to be #979. |
|
Sorry to bring bad news but the fix of Feb 27th above does not suffice, I just got the issue again with the patch included (I double checked). This is what I see in gdb : |
So singular in both dimensions and this .changed was definitely not added by the patched function: static inline void add_changed(ScreenPtr pScreen, RegionPtr reg)
{
vncHooksScreenPtr vncHooksScreen = vncHooksScreenPrivate(pScreen);
if (vncHooksScreen->ignoreHooks)
return;
if (REGION_NIL(reg))
return;
vncAddChanged(pScreen->myNum,
(const struct UpdateRect*)REGION_EXTENTS(pScreen, reg),
REGION_NUM_RECTS(reg),
(const struct UpdateRect*)REGION_RECTS(reg));
}The core dump happened when I was typing a mail in Outlook running in an xfreerdp session which was itself running in the tigervnc (which I've done a lot for years). What also might have had an influence is that I was using the option -compareFB=1 after somebody suggested that when teleworking over a WAN it was better to spend some more CPU in the server than to waste bandwidth by changes that could have been optimized out. I looked around a bit in the code (not understanding most of it) but possibly these singular rectangles are produced by this bit of code that looks to implement this compareFB: Region newChanged;
for (i = rects.begin(); i != rects.end(); i++)
compareRect(*i, &newChanged);
changed.get_rects(&rects);
for (i = rects.begin(); i != rects.end(); i++)
totalPixels += i->area();
newChanged.get_rects(&rects);
for (i = rects.begin(); i != rects.end(); i++)
missedPixels += i->area();
if (changed.equals(newChanged))
return false;
changed = newChanged;That last assignment to changed did not explicitly check for singular rectangles, so could that be another source of the same divide by zero ? Was also wondering if any methods inherited from SimpleUpdateTracker could directly access the changes member and produce singular rectanges (I'm an Ada developer with limited C++ knowledge). Also, could you think of a way to avoid the divide by zero as long as there is no proof of the absence of singular rectangles (which looks very far away to me) ? int h = maxArea / (xrgn->rects[i].x2 - xrgn->rects[i].x1);
if (!h) h = xrgn->rects[i].y2 - y;
do {
if (h > xrgn->rects[i].y2 - y)
h = xrgn->rects[i].y2 - y;
Rect r(xrgn->rects[i].x1, y, xrgn->rects[i].x2, y+h);
rects->push_back(r);
y += h;
} while (y < xrgn->rects[i].y2);This protection would destroy the "feedback loop" which uses the reported crashes as a mechanism to detect the presence of singular rectangles, but this is a lot of trouble for the user providing marginal benefit for the development. Producing a warning in the log (once) would be an alternative (although I understand people will not be motivated to report such warnings). For me robustness is far more important than the desire to get a solution that gets as close to perfection as possible based on crash reports. If you want I can upload build and core dump (but the core is 1.2 Gb). Awaiting advice I will stop using -compareFB=1 |
|
Alas, just had another divide by zero similar to the above. My boss also had the same crash with the compareFB=1 active and he remarked that the issues always seem to occur when there is another layer of pixel buffering present. My most recent crash was also triggered by using a vncviewer inside the vncviewer and many earlier failures happened using vncviewer or xfreerdp inside the vncviewer... Maybe that means something to you ? |
|
I tried to implement a detector/repearer combination in Region.cxx, runs ok so far. Below the patch I'm testing now : *** tigervnc-1.8.0/common/rfb/Region.h.org Sun Apr 26 02:09:07 2020
--- tigervnc-1.8.0/common/rfb/Region.h Sun Apr 26 02:09:12 2020
***************
*** 73,78 ****
--- 73,79 ----
Rect get_bounding_rect() const;
void debug_print(const char *prefix) const;
+ void check_for_singular_rectangles();
protected:
*** tigervnc-1.8.0/common/rfb/ComparingUpdateTracker.cxx.org Sun Apr 26 02:20:13 2020
--- tigervnc-1.8.0/common/rfb/ComparingUpdateTracker.cxx Sun Apr 26 02:27:42 2020
***************
*** 1,15 ****
/* Copyright (C) 2002-2005 RealVNC Ltd. All Rights Reserved.
! *
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
! *
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
! *
* You should have received a copy of the GNU General Public License
* along with this software; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
--- 1,15 ----
/* Copyright (C) 2002-2005 RealVNC Ltd. All Rights Reserved.
! *
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
! *
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
! *
* You should have received a copy of the GNU General Public License
* along with this software; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
***************
*** 32,37 ****
--- 32,38 ----
enabled(true), totalPixels(0), missedPixels(0)
{
changed.assign_union(fb->getRect());
+ changed.check_for_singular_rectangles();
}
ComparingUpdateTracker::~ComparingUpdateTracker()
***************
*** 70,81 ****
--- 71,84 ----
for (i = rects.begin(); i != rects.end(); i++)
oldFb.copyRect(*i, copy_delta);
+ changed.check_for_singular_rectangles();
changed.get_rects(&rects);
Region newChanged;
for (i = rects.begin(); i != rects.end(); i++)
compareRect(*i, &newChanged);
+ changed.check_for_singular_rectangles();
changed.get_rects(&rects);
for (i = rects.begin(); i != rects.end(); i++)
totalPixels += i->area();
***************
*** 87,92 ****
--- 90,96 ----
return false;
changed = newChanged;
+ changed.check_for_singular_rectangles();
return true;
}
*** tigervnc-1.8.0/common/rfb/Region.cxx.org Sun Apr 26 02:07:18 2020
--- tigervnc-1.8.0/common/rfb/Region.cxx Sun Apr 26 02:32:35 2020
***************
*** 145,162 ****
--- 145,166 ----
void rfb::Region::copyFrom(const rfb::Region& r) {
XUnionRegion(r.xrgn, r.xrgn, xrgn);
+ check_for_singular_rectangles();
}
void rfb::Region::assign_intersect(const rfb::Region& r) {
XIntersectRegion(xrgn, r.xrgn, xrgn);
+ check_for_singular_rectangles();
}
void rfb::Region::assign_union(const rfb::Region& r) {
XUnionRegion(xrgn, r.xrgn, xrgn);
+ check_for_singular_rectangles();
}
void rfb::Region::assign_subtract(const rfb::Region& r) {
XSubtractRegion(xrgn, r.xrgn, xrgn);
+ check_for_singular_rectangles();
}
rfb::Region rfb::Region::intersect(const rfb::Region& r) const {
***************
*** 250,252 ****
--- 254,290 ----
xrgn->rects[i].y2-xrgn->rects[i].y1);
}
}
+
+
+ extern void xorg_backtrace(void);
+ //?? Not sure how to include tigervnc-master/unix/xserver/include/os.h
+ //?? Not sure how to call a backtrace here, make fails Linking CXX executable x0vncserver
+ //? Region.cxx:282: undefined reference to `xorg_backtrace()'
+
+ void rfb::Region::check_for_singular_rectangles() {
+ int Number_Of_Singular = 0;
+ for (int i = 0; i < xrgn->numRects; i++) {
+ if (( xrgn->rects[i].x1 >= xrgn->rects[i].x2 ) || ( xrgn->rects[i].y1 >= xrgn->rects[i].y2 ))
+ { Number_Of_Singular++;
+ // This rectangle is singular, remove it
+ fprintf (stderr,
+ "Region::check_for_singular_rectangles skipping x1=%d, x2=%d, y1=%d, y2=%d\n",
+ xrgn->rects[i].x1,
+ xrgn->rects[i].x2,
+ xrgn->rects[i].y1,
+ xrgn->rects[i].y2);
+ }
+ else if ( Number_Of_Singular > 0 )
+ { // This is a non-sigular rectangle preceded by singular ones, needs to be copied to an earlier component
+ xrgn->rects[i-Number_Of_Singular].x1 = xrgn->rects[i].x1;
+ xrgn->rects[i-Number_Of_Singular].x2 = xrgn->rects[i].x2;
+ xrgn->rects[i-Number_Of_Singular].y1 = xrgn->rects[i].y1;
+ xrgn->rects[i-Number_Of_Singular].y2 = xrgn->rects[i].y2;
+ }
+ }
+ if ( Number_Of_Singular > 0 )
+ {
+ xrgn->numRects = xrgn->numRects - Number_Of_Singular;
+ // xorg_backtrace();
+ }
+ }
*** tigervnc-1.8.0/common/rfb/UpdateTracker.cxx.org Sun Apr 26 02:30:40 2020
--- tigervnc-1.8.0/common/rfb/UpdateTracker.cxx Sun Apr 26 02:33:59 2020
***************
*** 1,15 ****
/* Copyright (C) 2002-2005 RealVNC Ltd. All Rights Reserved.
! *
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
! *
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
! *
* You should have received a copy of the GNU General Public License
* along with this software; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
--- 1,15 ----
/* Copyright (C) 2002-2005 RealVNC Ltd. All Rights Reserved.
! *
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
! *
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
! *
* You should have received a copy of the GNU General Public License
* along with this software; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
***************
*** 77,82 ****
--- 77,83 ----
void SimpleUpdateTracker::add_changed(const Region ®ion) {
changed.assign_union(region);
+ changed.check_for_singular_rectangles();
}
void SimpleUpdateTracker::add_copied(const Region &dest, const Point &delta) {
***************
*** 121,127 ****
Region invalid_src = overlap.intersect(changed);
invalid_src.translate(delta);
changed.assign_union(invalid_src);
!
overlap.translate(delta);
Region nonoverlapped_copied = dest.union_(copied).subtract(overlap);
--- 122,128 ----
Region invalid_src = overlap.intersect(changed);
invalid_src.translate(delta);
changed.assign_union(invalid_src);
!
overlap.translate(delta);
Region nonoverlapped_copied = dest.union_(copied).subtract(overlap);
***************
*** 142,147 ****
--- 143,150 ----
{
copied.assign_subtract(changed);
info->changed = changed.intersect(clip);
+ info->changed.check_for_singular_rectangles();
+
info->copied = copied.intersect(clip);
info->copy_delta = copy_delta;
} |
|
I've put a construct in the detect and repair function check_for_singular_rectangles to dump core and continue, which is a bit heavy but provides a lot more info than just a backtrace. One of my Eurocontrol collegues had a core dump with this modification to the patch above, and now I understand better what was the root cause of this issue and why the patch did not protect us. First the root cause (they may be others): When the Dispatch calls ProcRenderComposite the function receives a rather bizarre render request: The zero width and height is not being tested and this leads eventually to the singular rectangle resulting to the divide by zero in the official version, and to the repair and core dump in my version. Below a gdb sesstion inspecting frames 4 to 10 (where, as usual, plenty of parameters are optimized out). In frame 4 we can see the singular single rectangle region : Then all is optimized out until we see the region again in frame 8 vncAddChanged Here is gets interesting because in frame 9 we see the protection you added: So this code clearly did not consider this region to be NIL I guess the function calling the the fix attempt came from regionstr.h: And clearly this code is not checking for singular rectangles, it just assumes that if the numRects is larger than zero (1 in our case) then all is well. This also shows the challenge for this approach to fixing the issue : A region could contain any number of rectangles and some of these could be singular, in that case a protection simply discarding the entire region would lead to a partial rendering, while one accepting the entire region would lead to the divide by zero. So I believe my detect and repair is a better approach as it discards only the singular rectangles. I will proceed with building and testing another patch with:
|
|
Hi Pierre, can you open the #846 again ?
I’ve added comments to explain what the root cause was, why the patch failed, how I repaired (a?) root cause and how to recover from possible other sources.
Will comment with a new patch that should fix everything (but as I said, I’m not a C++ programmer so hopefully you can review the changes and build a better patch).
All the best and good health,
Stef
From: Pierre Ossman (Work account) <notifications@github.com>
Sent: 20 April 2020 08:58
To: TigerVNC/tigervnc <tigervnc@noreply.github.com>
Cc: VAN VLIERBERGHE Stef <stef.van-vlierberghe@eurocontrol.int>; Comment <comment@noreply.github.com>
Subject: Re: [TigerVNC/tigervnc] Floating point exception while resizing a window on Debian Buster (#846)
Closed #846<#846>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#846 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH5WRHFEKPBA3BKV4VPBAN3RNPW7XANCNFSM4HYRMENA>.
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
The new patch as described above: |
|
Thanks for your hard work. It's a shame the first fix did not solve things. It looks like |
|
Yeah, I think the best method is simply avoiding |
|
Hi Pierre,
Thanks for reopening #846.
Yes, the REGION_NIL(reg) checks didn’t protect, I would recommend to rollback that fix attempt.
I don’t see where this REGION_INIT() happens, for me the “main” fix is the first line in damageComposite :
damageComposite(CARD8 op,
PicturePtr pSrc,
PicturePtr pMask,
PicturePtr pDst,
INT16 xSrc,
INT16 ySrc,
INT16 xMask,
INT16 yMask,
INT16 xDst, INT16 yDst, CARD16 width, CARD16 height)
{ if ( width > 0 && height > 0 ) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<MAIN FIX
If this were an Ada program I would have changed the type CARD16 to Positive to indicate that a caller passing zero for width or height must be doing something wrong.
But as far as I understand this is a message decoded from the X protocol, and therefore such a stricter convention would need to be enforced in the software writing these messages, which is unfortunately not a single implementation shared by all tools.
So it seemed to me that this protection would stop such “nonsensical” singleton rectangles are early as possible.
We have not had any new core dumps since the MAIN FIX above, and I don’t see how it could harm.
But I’d like to also keep the detect and repair code in case there would be yet another source of singular rectangles (possibly the system(gcore) can only be preserved in Linux implementations, or possibly there is a central implementation to do a core dump and survive), because from a user’s perspective losing the Xvnc and everything that was running in the desktop is a real nightmare.
Would that be acceptable for you ?
All the best,
Stef
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#846 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH5WRHAQQ6MSVQ7NTNG66T3RPLEBJANCNFSM4HYRMENA>.
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
The problem is that everything in Region is coded with the assumption that it doesn't have empty rects in it, so it is a bit like putting a band aid on a severed arm. Please have a look at #1009. It should fix this issue more properly. It's a rather large diff though, so if it's too complex then hold off until it's been merged and you can try a nightly build. |
KireinaHoro
pushed a commit
to KireinaHoro/jsteward
that referenced
this issue
Feb 26, 2021
This version checks in fix from upstream to address the Floating Point Exception bugs. See: TigerVNC/tigervnc#846 Package-Manager: Portage-3.0.13, Repoman-3.0.2
|
I have that too. It happens when i open LibreOffice Draw |
|
It would be wise to report such issues together with the version of tigervnc you are using.
The issue is fixed in the latest release so try using that one.
All the best,
Stef
From: DocMAX ***@***.***>
Sent: 12 June 2021 15:45
To: TigerVNC/tigervnc ***@***.***>
Cc: VAN VLIERBERGHE Stef ***@***.***>; Comment ***@***.***>
Subject: Re: [TigerVNC/tigervnc] Floating point exception while resizing a window on Debian Buster (#846)
I have that too. It happens when i open LibreOffice Draw
(EE) Backtrace:
(EE) 0: /usr/bin/Xvnc (xorg_backtrace+0x5b) [0x564b0885907b]
(EE) 1: /usr/bin/Xvnc (0x564b08687000+0x1d5a15) [0x564b0885ca15]
(EE) 2: /lib64/libpthread.so.0 (0x7f6d419a5000+0x121f0) [0x7f6d419b71f0]
(EE) 3: /usr/bin/Xvnc (_ZNK3rfb6Region9get_rectsEPSt6vectorINS_4RectESaIS2_EEbbi+0x146) [0x564b087cdad6]
(EE) 4: /usr/bin/Xvnc (_ZN3rfb22ComparingUpdateTracker7compareEv+0x1b5) [0x564b087d2275]
(EE) 5: /usr/bin/Xvnc (_ZN3rfb11VNCServerST11writeUpdateEv+0x1fd) [0x564b087d036d]
(EE) 6: /usr/bin/Xvnc (_ZN3rfb11VNCServerST13handleTimeoutEPNS_5TimerE+0x61) [0x564b087d0571]
(EE) 7: /usr/bin/Xvnc (_ZN3rfb5Timer13checkTimeoutsEv+0x8c) [0x564b087ce35c]
(EE) 8: /usr/bin/Xvnc (_ZN3rfb11VNCServerST13checkTimeoutsEv+0x17) [0x564b087cea47]
(EE) 9: /usr/bin/Xvnc (_ZN14XserverDesktop12blockHandlerEPi+0x253) [0x564b087c2733]
(EE) 10: /usr/bin/Xvnc (vncCallBlockHandlers+0x28) [0x564b087b6518]
(EE) 11: /usr/bin/Xvnc (BlockHandler+0x3e) [0x564b0880d1ee]
(EE) 12: /usr/bin/Xvnc (WaitForSomething+0x116) [0x564b08856d86]
(EE) 13: /usr/bin/Xvnc (Dispatch+0xa7) [0x564b088086d7]
(EE) 14: /usr/bin/Xvnc (dix_main+0x374) [0x564b0880c894]
(EE) 15: /lib64/libc.so.6 (__libc_start_main+0xcd) [0x7f6d410447ed]
(EE) 16: /usr/bin/Xvnc (_start+0x2a) [0x564b086f092a]
(EE)
(EE) Floating point exception at address 0x564b087cdad6
(EE)
Fatal server error:
(EE) Caught signal 8 (Floating point exception). Server aborting
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#846 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH5WRHESYB24EIO5DNG36LDTSNQEBANCNFSM4HYRMENA>.
…____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I had a vncviewer connection (on machine A) to a vncserver (on machine B), which in turn has a long-running vncviewer session to vncserver (on machine C).
vncserver on machine B crashed while I was resizing vncviewer window to machine C. I don't know if it has anything to do that the resized window was itself an instance of vncviewer, but such crash has happened before to me.
OS: A: Arch Linux, B & C: Debian Buster
Version 1.9 everywhere
Desktop Manager on B: LxQt
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: