2 things to try:
1) apply https://wiki.documentfoundation.org/QA/FirstSteps

2) try this:
- open terminal/console
- export SAL_USE_VCLPLUGIN=gen && soffice
then try to reproduce this the pb.
The goal is to know if it's kf5/qt5 related.

Dear Mz. Nabet:
  I have applied the contents in https://wiki.documentfoundation.org/QA/FirstSteps. I had my user profile restored, but sadly this bug happened again. Also, I can be sure that this bug is not concerning OpenGL or OpenCL, since I was not using Calc and I am also observing this bug with OpenGL off.
  I have not tried the second method (export SAL_USE_VCLPLUGIN=gen). However, this time, a new and "useful" backtrace log had been generated. From the bug report, I can guess that this bug is somewhat related to Qt5 and/or Kf5 (I'm not a programmer myself so forgive my mistake). The newly-generated bug report is attached below.

[Backtrace log]
Application: soffice (soffice), signal: Segmentation fault
[KCrash Handler]
#4  0x00007f7090c215be in SdTransferable::ObjectReleased() () from /usr/lib64/libreoffice/program/../program/libsdlo.so
#5  0x00007f7090c2d555 in SdTransferable::~SdTransferable() () from /usr/lib64/libreoffice/program/../program/libsdlo.so
#6  0x00007f7090c2dbe9 in SdTransferable::~SdTransferable() () from /usr/lib64/libreoffice/program/../program/libsdlo.so
#7  0x00007f70d8792737 in Qt5MimeData::~Qt5MimeData() () from /usr/lib64/libreoffice/program/libvclplug_qt5lo.so
#8  0x00007f70d175a45c in QXcbClipboard::~QXcbClipboard (this=0x7f70c8005dd0, __in_chrg=<optimized out>) at qxcbclipboard.cpp:274
#9  0x00007f70d175a609 in QXcbClipboard::~QXcbClipboard (this=0x7f70c8005dd0, __in_chrg=<optimized out>) at qxcbclipboard.cpp:276
#10 0x00007f70d176103b in QXcbConnection::~QXcbConnection (this=0x55562ad6a920, __in_chrg=<optimized out>) at qxcbconnection.cpp:141
#11 0x00007f70d1761639 in QXcbConnection::~QXcbConnection (this=0x55562ad6a920, __in_chrg=<optimized out>) at qxcbconnection.cpp:159
#12 0x00007f70d1762846 in qDeleteAll<QList<QXcbConnection*>::const_iterator> (end=..., begin=...) at ../../../../include/QtCore/../../src/corelib/tools/qalgorithms.h:320
#13 qDeleteAll<QList<QXcbConnection*> > (c=...) at ../../../../include/QtCore/../../src/corelib/tools/qalgorithms.h:328
#14 QXcbIntegration::~QXcbIntegration (this=0x55562ad60590, __in_chrg=<optimized out>) at qxcbintegration.cpp:229
#15 0x00007f70d1762949 in QXcbIntegration::~QXcbIntegration (this=0x55562ad60590, __in_chrg=<optimized out>) at qxcbintegration.cpp:231
#16 0x00007f70d975815d in QGuiApplicationPrivate::~QGuiApplicationPrivate (this=0x55562ad5b170, __in_chrg=<optimized out>) at kernel/qguiapplication.cpp:1645
#17 0x00007f70d8f0a819 in QApplicationPrivate::~QApplicationPrivate (this=0x55562ad5b170, __in_chrg=<optimized out>) at kernel/qapplication.cpp:181
#18 0x00007f70da126633 in QScopedPointerDeleter<QObjectData>::cleanup (pointer=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:60
#19 QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer (this=0x55562ad59528, __in_chrg=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:107
#20 QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:892
#21 0x00007f70da0f18f6 in QCoreApplication::~QCoreApplication (this=0x55562ad59520, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:892
#22 0x00007f70d975bb60 in QGuiApplication::~QGuiApplication (this=0x55562ad59520, __in_chrg=<optimized out>) at kernel/qguiapplication.cpp:649
#23 0x00007f70d8f0c989 in QApplication::~QApplication (this=0x55562ad59520, __in_chrg=<optimized out>) at kernel/qapplication.cpp:773
#24 0x00007f70d8f0cb89 in QApplication::~QApplication (this=0x55562ad59520, __in_chrg=<optimized out>) at kernel/qapplication.cpp:843
#25 0x00007f70d8775a37 in Qt5Instance::~Qt5Instance() () from /usr/lib64/libreoffice/program/libvclplug_qt5lo.so
#26 0x00007f70ef89b9cb in non-virtual thunk to KF5SalInstance::~KF5SalInstance() () from /usr/lib64/libreoffice/program/libvclplug_kf5lo.so
#27 0x00007f70ee03fa43 in DeInitVCL() () from /usr/lib64/libreoffice/program/libmergedlo.so
#28 0x00007f70ee03fe3a in ImplSVMain() () from /usr/lib64/libreoffice/program/libmergedlo.so
#29 0x00007f70ed617665 in soffice_main () from /usr/lib64/libreoffice/program/libmergedlo.so
#30 0x00005556291cf77b in main ()
[Inferior 1 (process 8248) detached]

Thank you mac-wang for your feedback.

Michael: any thoughts about bt which are qt related?

@mac-wang: Does this still happen with a daily development build from https://dev-builds.libreoffice.org/daily/master/ or LibreOffice 7.1?
You can install that in parallel to your existing installation as described here:
https://wiki.documentfoundation.org/Installing_in_parallel/Linux

Does it happen if you just create a new (empty) Writer document, wait a minute, and then close LibreOffice?

Dear Mr. Weghorn:
  The bug is appearing again on LibreOffice 7.1.1.2 (from the openSUSE repository). The operating system is the same, openSUSE Leap 15.2 x86_64.
  However, it is not happening while I opens Writer/Impress/Calc, wait a minute, and close it. It seems that the bug is only happening if I'm processing some document. 
  The new backtrace log is provided as follows.


Application: soffice (soffice), signal: Segmentation fault
[KCrash Handler]
#4  0x00007f5ee57ebac1 in TextRanger::~TextRanger() () from /usr/lib64/libreoffice/program/libmergedlo.so
#5  0x00007f5e4b659801 in ClrContourCache() () from /usr/lib64/libreoffice/program/../program/libswlo.so
#6  0x00007f5e4b3f4f49 in SwDoc::~SwDoc() () from /usr/lib64/libreoffice/program/../program/libswlo.so
#7  0x00007f5e4b3f7861 in SwDoc::release() () from /usr/lib64/libreoffice/program/../program/libswlo.so
#8  0x00007f5e4ba2bc79 in SwTransferable::~SwTransferable() () from /usr/lib64/libreoffice/program/../program/libswlo.so
#9  0x00007f5e4ba2c0b9 in SwTransferable::~SwTransferable() () from /usr/lib64/libreoffice/program/../program/libswlo.so
#10 0x00007f5eceb13407 in Qt5MimeData::~Qt5MimeData() () from /usr/lib64/libreoffice/program/libvclplug_qt5lo.so
#11 0x00007f5ec7d7345c in QXcbClipboard::~QXcbClipboard (this=0x7f5ec0005450, __in_chrg=<optimized out>) at qxcbclipboard.cpp:274
#12 0x00007f5ec7d73609 in QXcbClipboard::~QXcbClipboard (this=0x7f5ec0005450, __in_chrg=<optimized out>) at qxcbclipboard.cpp:276
#13 0x00007f5ec7d7a03b in QXcbConnection::~QXcbConnection (this=0x55b022865b80, __in_chrg=<optimized out>) at qxcbconnection.cpp:141
#14 0x00007f5ec7d7a639 in QXcbConnection::~QXcbConnection (this=0x55b022865b80, __in_chrg=<optimized out>) at qxcbconnection.cpp:159
#15 0x00007f5ec7d7b846 in qDeleteAll<QList<QXcbConnection*>::const_iterator> (end=..., begin=...) at ../../../../include/QtCore/../../src/corelib/tools/qalgorithms.h:320
#16 qDeleteAll<QList<QXcbConnection*> > (c=...) at ../../../../include/QtCore/../../src/corelib/tools/qalgorithms.h:328
#17 QXcbIntegration::~QXcbIntegration (this=0x55b02285dfe0, __in_chrg=<optimized out>) at qxcbintegration.cpp:229
#18 0x00007f5ec7d7b949 in QXcbIntegration::~QXcbIntegration (this=0x55b02285dfe0, __in_chrg=<optimized out>) at qxcbintegration.cpp:231
#19 0x00007f5ecfad915d in QGuiApplicationPrivate::~QGuiApplicationPrivate (this=0x55b0228587a0, __in_chrg=<optimized out>) at kernel/qguiapplication.cpp:1645
#20 0x00007f5ecf28b819 in QApplicationPrivate::~QApplicationPrivate (this=0x55b0228587a0, __in_chrg=<optimized out>) at kernel/qapplication.cpp:181
#21 0x00007f5ed04a7633 in QScopedPointerDeleter<QObjectData>::cleanup (pointer=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:60
#22 QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer (this=0x55b022856b08, __in_chrg=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:107
#23 QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:892
#24 0x00007f5ed04728f6 in QCoreApplication::~QCoreApplication (this=0x55b022856b00, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:892
#25 0x00007f5ecfadcb60 in QGuiApplication::~QGuiApplication (this=0x55b022856b00, __in_chrg=<optimized out>) at kernel/qguiapplication.cpp:649
#26 0x00007f5ecf28d989 in QApplication::~QApplication (this=0x55b022856b00, __in_chrg=<optimized out>) at kernel/qapplication.cpp:773
#27 0x00007f5ecf28db89 in QApplication::~QApplication (this=0x55b022856b00, __in_chrg=<optimized out>) at kernel/qapplication.cpp:843
#28 0x00007f5eceb02067 in Qt5Instance::~Qt5Instance() () from /usr/lib64/libreoffice/program/libvclplug_qt5lo.so
#29 0x00007f5ee85aeacb in non-virtual thunk to KF5SalInstance::~KF5SalInstance() () from /usr/lib64/libreoffice/program/libvclplug_kf5lo.so
#30 0x00007f5ee6fe0ce0 in DeInitVCL() () from /usr/lib64/libreoffice/program/libmergedlo.so
#31 0x00007f5ee6fe111a in ImplSVMain() () from /usr/lib64/libreoffice/program/libmergedlo.so
#32 0x00007f5ee5f07165 in soffice_main () from /usr/lib64/libreoffice/program/libmergedlo.so
#33 0x000055b02184b77b in main ()
[Inferior 1 (process 3143) detached]

(In reply to mac-wang from comment #5)
> Dear Mr. Weghorn:
>   The bug is appearing again on LibreOffice 7.1.1.2 (from the openSUSE
> repository). The operating system is the same, openSUSE Leap 15.2 x86_64.
>   However, it is not happening while I opens Writer/Impress/Calc, wait a
> minute, and close it. It seems that the bug is only happening if I'm
> processing some document. 

Can you find any specific steps while processing "some document" that cause the crash? And can you attach a sample document for which it happens?

If possible, it would be great to have exact steps to reproduce which will very much increase the chance that the underlying issue can be analysed and fixed, like:

1) open attached sample document "mydoc.odt"
2) do this or that
3) ...

Dear Mr. Weghorn:
  
  I'm sorry that I could not provide you with the documents I'm processing. You see, I'm a college student, and posting my documents risk leaking my personal info, and may lead to unexpected violations of some academic integrity code.
  I will, however, provide some more detailed information on how this happens.

  First, I would open an *.docx document. (This file format is required by my instructor) 
  Then, I would start editing it. During the course when I want to refer to other sources, I would use pdf reader and internet browser to gather info, but I usually close all other apps before I stop editing.
  Finally, I close the document, and an error message appears. I noticed that the longer I'm editing the documents, the more possible an error message appears.

  And that's all. Thank you.

(In reply to mac-wang from comment #7)
>   I'm sorry that I could not provide you with the documents I'm processing.
> You see, I'm a college student, and posting my documents risk leaking my
> personal info, and may lead to unexpected violations of some academic
> integrity code.

I understand this. Can you try whether the issue also happens when you take the same steps using e.g. an empty document instead of one that contains confidential information?

>   I will, however, provide some more detailed information on how this
> happens.
> 
>   First, I would open an *.docx document. (This file format is required by
> my instructor) 
>   Then, I would start editing it. During the course when I want to refer to
> other sources, I would use pdf reader and internet browser to gather info,
> but I usually close all other apps before I stop editing.
>   Finally, I close the document, and an error message appears. I noticed
> that the longer I'm editing the documents, the more possible an error
> message appears.

Since the initial description mentions that LibreOffice 6.45.2 is used: Can you please retest with the current LibreOffice fresh version 7.1?

  I confirm that the bug is appearing in release 7.1.2.2. I also confirm that the bug is NOT happening if I open an empty document, wait a while, and close it.


  Now a NEW bug is appearing and is causing data loss. In the previous bug, I reported that the KDE kept informing that soffice.bin is crashing even it is not. I also observed that sometimes, on next startup, a dialog appears asking me whether to recover the document or not, indicating that LibreOffice DID crash on exit. So, I modified the title of the bug to "LibreOffice is crashing on exit and in daily use". 
  However, today I observed that soffice.bin IS CRASHING DURING USE. This happens when I am editing a .docx, and opened a .pptx for my reference. soffice.bin suddenly exited, and KCrashHandler did not notice that event! This is actually causing me data loss.
  As a supplementary info, the bug appeared not on exit, but suddenly. Also KCrashHandler was not incited, so there is even no backtrace log. If you know how to generate a backtrace log in this circumstance, or if I need to use gdb or some stuff to debug soffice.bin, please email me.
  
  System info: openSUSE Leap 15.3 Beta x86_64
  LibreOffice info: 
    Version: 7.1.2.2 / LibreOffice Community
    Build ID: 10(Build:2)
    CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5
    Locale: en-US (en_US.UTF-8); UI: en-US
    Calc: threaded

Created attachment 171451 [details]
The document I'm referring to when LibreOffice suddenly exited.

There is a .pptx file that is not so important, and I could upload to you. For reasons of academic integrity, I'm not uploading the .docx file.

(In reply to Mack Wang from comment #9)
>   I confirm that the bug is appearing in release 7.1.2.2. I also confirm
> that the bug is NOT happening if I open an empty document, wait a while, and
> close it.

Thanks for further testing.
The "Version" field is for the *earliest* affected version, so I'm setting it back to the previous value.

Please set bugs back to UNCONFIRMED if you add the requested information. NEW is the status that is set if somebody else could confirm/reproduce the bug.

>   Now a NEW bug is appearing and is causing data loss. In the previous bug,
> I reported that the KDE kept informing that soffice.bin is crashing even it
> is not. I also observed that sometimes, on next startup, a dialog appears
> asking me whether to recover the document or not, indicating that
> LibreOffice DID crash on exit. So, I modified the title of the bug to
> "LibreOffice is crashing on exit and in daily use". 
>   However, today I observed that soffice.bin IS CRASHING DURING USE. This
> happens when I am editing a .docx, and opened a .pptx for my reference.
> soffice.bin suddenly exited, and KCrashHandler did not notice that event!
> This is actually causing me data loss.
>   As a supplementary info, the bug appeared not on exit, but suddenly. Also
> KCrashHandler was not incited, so there is even no backtrace log. If you
> know how to generate a backtrace log in this circumstance, or if I need to
> use gdb or some stuff to debug soffice.bin, please email me.

https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace has information on how to generate a backtrace.


Can you find exact steps to reliably reproduce this on your end?
If so, I suggest you start creating a fresh sample document with which this is also reproducible that you can share, so somebody can try to reproduce and analyze the issue with that one.

What I usually do in such cases is that I start with the original document, then:

1) delete some content
2) try whether the issue is still reproducible
  * if yes: continue at step 1 (delete some more content)
  * if no: put the content back, try to delete some other content

This way, you can first minimize the existing document. Once you know what part is the problematic one, you can try to create a fresh, non-confidential document that has the same characteristic as the original one and also triggers the crash. You could then share that non-confidential document.

I know this will take some time, but it is hard to fix bugs that are not reproducible and whose backtrace doesn't show the problem at once. In case you want to try this and/or have any questions, you can also ask them on IRC or the QA mailing list, s. https://wiki.documentfoundation.org/QA/GetInvolved#Contact for details.

Dear Mack Wang,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp