Created attachment 705976 [details]
Xorg.0.log

In X log I see:

[ 52097.883] (EE) 
[ 52097.883] (EE) Backtrace:
[ 52097.883] (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x588a18]
[ 52097.883] (EE) 1: /usr/bin/X (0x400000+0x18cd59) [0x58cd59]
[ 52097.883] (EE) 2: /lib64/libc.so.6 (0x7fc7c4a65000+0x34950) [0x7fc7c4a99950]
[ 52097.883] (EE) 3: /usr/bin/X (FreePicture+0xd0) [0x5041f0]
[ 52097.883] (EE) 4: /usr/bin/X (0x400000+0x5cec2) [0x45cec2]
[ 52097.883] (EE) 5: /usr/bin/X (FreeResource+0xde) [0x45da9e]
[ 52097.883] (EE) 6: /usr/bin/X (0x400000+0x1092b4) [0x5092b4]
[ 52097.883] (EE) 7: /usr/bin/X (0x400000+0x393be) [0x4393be]
[ 52097.883] (EE) 8: /usr/bin/X (0x400000+0x3d0fb) [0x43d0fb]
[ 52097.883] (EE) 9: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fc7c4a856e5]
[ 52097.883] (EE) 10: /usr/bin/X (_start+0x29) [0x428679]
[ 52097.883] (EE) 
[ 52097.883] (EE) Segmentation fault at address 0x0
[ 52097.883] (EE) 
Fatal server error:
[ 52097.883] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 52097.883] (EE)

Hmm. Could you install -debuginfo/-debugsource packages for xserver and drivers?

I updated kernel (via online updates) to 4.4.36-8 version, also installed 
xf86-video-fbdev-debuginfo
xf86-video-fbdev-debugsource
xf86-video-intel-debuginfo
xf86-video-intel-debugsource
xf86-video-vesa-debuginfo
xf86-video-vesa-debugsource
Mesa-debuginfo
Mesa-debugsource
xorg-x11-server-debuginfo
xorg-x11-server-debugsource

But  today I did not reproduced crash of X (only LibreOffice crash) twice, 
but tried time X crashed. Previous I could consistently reproduce bug.

I was able to reproduce it on my device. Going to look into it...

The crash I see is a bit different, but it probably has the same root cause.

I get following messages in Xorg log:
  Fatal server error:
  (EE) EXA: malloc failed for size -1190238536 bytes

Backtrace:
#0  0x00000000005958d0 in FatalError ()
#1  0x00007f2bdc09f2e0 in exaPrepareAccessReg_mixed (pPixmap=0x34089e0, index=0, pReg=0x7ffe4e444f30) at exa_migration_mixed.c:211
#2  0x00007f2bdc0a7880 in ExaCheckCopyNtoN (pSrc=0x310a860, pDst=0x34089e0, pGC=0x3408b50, pbox=0x7ffe4e445070, nbox=1, dx=0, dy=0, reverse=0, upsidedown=0, bitplane=0, closure=0x0) at exa_unaccel.c:152
#3  0x000000000056954a in miCopyRegion ()
#4  0x0000000000569ac6 in miDoCopy ()
#5  0x00007f2bdc09f776 in exaCopyArea (pSrcDrawable=<optimized out>, pDstDrawable=<optimized out>, pGC=<optimized out>, srcx=<optimized out>, srcy=<optimized out>, width=<optimized out>, height=32599, dstx=0, dsty=0) at exa_accel.c:608


The negative number is only in the error message, the code uses xallocarray so there isn't any overflow there. It is however trying to allocate storage for 23810 x 32599 pixmap and I don't have enough memory for that.

The main bug is in LibreOffice, it should not attempt to work with pixmap of such size.

Anyway X server usually handles out-of-memory by reporting BadAlloc back to client, not by aborting with FatalError. So this should be probably corrected in X server as well.

From Xlib Programming Manual:
"BadAlloc: The server fails to allocate the requested resource. Note that the explicit listing of BadAlloc errors in requests only covers allocation errors at a very coarse level and is not intended to (nor can it in practice hope to) cover all cases of a server running out of allocation space in the middle of service. The semantics when a server runs out of allocation space are left unspecified, but a server may generate a BadAlloc error on any request for this reason, and clients should be prepared to receive such errors and handle or discard them."

https://tronche.com/gui/x/xlib/event-handling/protocol-errors/default-handlers.html

The acceleration code is pretty complex and there is currently no way to report the information about allocation error back to the client. Doing so would require big rewrite that would touch all accelerations backends in X server. So quitting the X server with FatalError seems to be the best option in this case.

I am still going to investigate if there is any potential for security error when the allocation succeeds (because the backtrace in comment 1 looks different from mine).

I have observed this issue only in KDE 5. In Gnome or when running without any window manager nothing attempts to copy such huge image and so X server does not crash. However LibreOffice crashes every time. I will create separate bug for LibreOffice maintainers to work on it.

Created attachment 706625 [details]
LibreOffice backtrace at interupt while exporting to PDF

Strange, now I can not reproduce X crash; now after pressing button to export to PDF, computer slows down, X process eats 25% (all resources of 1 CPU of all 4 CPU), after several minutes LibreOffice crash without any backtrace in GDB. 
I also use KDE Plasma.
But if I run in GDB and try interupt, I can get LibreOffice backtrace

Now after LibreOffice crash, at best I can see in Konsole message:

X IO Error

The conclusion is that under some out-of-memory conditions X server can not simply report the error to the client and must completely abort.

Libreoffice is requesting copy of too big area. The libreoffice bug is being worked on in bug #1015777. There doesn't seem to be anything we can do from X server side.