Bug 132158 - Crash not 'intercepted' properly
Summary: Crash not 'intercepted' properly
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Document-Recovery
  Show dependency treegraph
 
Reported: 2020-04-16 18:24 UTC by Telesto
Modified: 2023-08-10 12:11 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (49.56 KB, image/jpeg)
2020-04-17 11:29 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-04-16 18:24:12 UTC
Description:
Normally a Document recovery opens.. Pres OK to restart. I have seen multiple crashing going down 'hard'. LibreOffice doesn't work anymore. Click here to close to program. 

Steps to Reproduce:
1. Open attachment 155421 [details] (bug 131684)
2. Toggle formatting marks on
3. CTRL+A (3x)
4. CTRL+X
5. CTRL+Z
6. CTRL+X
7. CTRL+Z
8. CTRL+X -> Two formatting marks.. ODD
9. Click the top one -> Crash

Actual Results:
Crash reporter window skipped of overwritten by 'LibreOffice doesn't respond'

Expected Results:
If possible some improvement to see the 'crash' informer..

Else, why is there some kind of your program has crashed dialog.. It's rather confusing. If the dialog appears, pfew my documents will recovered while a 'hard' crash means my documents are gone (no probably not.. but)  


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 4475bcd83aac7e033fc5250f268eb922bd471e7b
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: en-US (nl_NL); UI-Language: en-US
Calc: CL
Comment 1 Xisco Faulí 2020-04-17 10:40:09 UTC
Hi Telesto,
I can't reproduce it in

Versión: 6.4.2.2 (x86)
Id. de compilación: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
Subprocs. CPU: 2; SO: Windows 6.1 Service Pack 1 Build 7601; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

Can you reproduce it with a release build? Please note the crashreport is meant to work with release builds, not with daily builds
Comment 2 Telesto 2020-04-17 11:29:23 UTC
Created attachment 159654 [details]
Screenshot
Comment 3 Telesto 2020-04-17 11:36:43 UTC
(In reply to Xisco Faulí from comment #1)
> Can you reproduce it with a release build? Please note the crashreport is
> meant to work with release builds, not with daily builds

It's probably my description. With the current case I get 3 windows on when crashing.

* The LibreOffice Due an error close window
* Windows read exception error
* Windows LibreOffice has stopped responding window

The LibreOffice Due an error close window is in this case 'not responding'. On other cases it doesn't even appear [the current Calc Clipboard crash]. Libo crashes 'hard' wit no window or with a Windows LibreOffice has stopped responding dialog.

My point, is it possible to 'catch' a crash better; so The LibreOffice Due an error close window will open (not only by luck) and be functional (not crashing too).

Else it maybe wise to drop the The LibreOffice Due an error close window and go for a crash.
Comment 4 Buovjaga 2020-06-20 14:14:25 UTC
(In reply to Telesto from comment #0)
> 8. CTRL+X -> Two formatting marks.. ODD

I only see one. Crash not reproduced

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 43c60ce1ac7629a1462e927e6ff937469f58f743
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded
Comment 5 Telesto 2020-06-20 15:04:13 UTC
(In reply to Buovjaga from comment #4)
> (In reply to Telesto from comment #0)
> > 8. CTRL+X -> Two formatting marks.. ODD
> 
> I only see one. Crash not reproduced
> 
> Version: 7.1.0.0.alpha0+ (x64)
> Build ID: 43c60ce1ac7629a1462e927e6ff937469f58f743
> CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL:
> win
> Locale: fi-FI (fi_FI); UI: en-US
> Calc: threaded

True.. the STR to produce the crash are fixed.. to underlying problem is likely still lingering around somewhere, but needs a new sample :-(. 

Going for WFM for now
Comment 6 Telesto 2020-06-21 17:56:01 UTC
New file..  (which does the same thing LibreOffice doesn't respond'). Crash as such reported as bug 134201.. 
1. Open attachment 157498 [details]
2. CTRL+A
3. CTRL+C
4. CTRL+N
5. CTRL+V -> 8x
6. CTRL+Z -> 8x
7. CTRL+V -> 8x
8. CTRL+Z -> 8x -> Crash
Comment 7 Buovjaga 2020-06-21 19:16:32 UTC
(In reply to Telesto from comment #6)
> New file..  (which does the same thing LibreOffice doesn't respond'). Crash
> as such reported as bug 134201.. 
> 1. Open attachment 157498 [details]
> 2. CTRL+A
> 3. CTRL+C
> 4. CTRL+N
> 5. CTRL+V -> 8x
> 6. CTRL+Z -> 8x
> 7. CTRL+V -> 8x
> 8. CTRL+Z -> 8x -> Crash

Yeah, it does not offer document recovery after this.
Comment 8 Telesto 2020-06-21 19:30:44 UTC
(In reply to Buovjaga from comment #7)
> (In reply to Telesto from comment #6)
> > New file..  (which does the same thing LibreOffice doesn't respond'). Crash
> > as such reported as bug 134201.. 
> > 1. Open attachment 157498 [details]
> > 2. CTRL+A
> > 3. CTRL+C
> > 4. CTRL+N
> > 5. CTRL+V -> 8x
> > 6. CTRL+Z -> 8x
> > 7. CTRL+V -> 8x
> > 8. CTRL+Z -> 8x -> Crash
> 
> Yeah, it does not offer document recovery after this.

Also something like this attachment 159654 [details]
Comment 9 Buovjaga 2020-06-22 12:12:26 UTC
I looked into bibisecting this (steps from comment 6). Win 6.2 oldest gives me the recovery window, but master and jumping 1000 commits backwards do not give me any *crash*. You are welcome to try, if this is bibisectable or not.
Comment 10 QA Administrators 2022-06-23 03:47:36 UTC Comment hidden (obsolete, spam)
Comment 11 Justin L 2023-08-10 12:11:13 UTC
I don't see any point to this bug report.

IIUC, it is saying that EVERY crash ought to trigger an EmergencySave.

There are a million ways to cause a crash, and each crash will need to be handled individually. Sure - if the best you can do is to turn a hard crash into a soft crash that would be better than nothing.

It isn't possible to prevent hard crashes from ever occuring.