Created attachment 177349 [details]
Screenshot of the dialog

The problem happens inside ExitProcess system call, when some code in DLL unload functions attempts to access ImplSVData singleton, which at that time is already destroyed by the statics destruction code called by CRT.

I am not sure if we really need to care about this secondary crash. Trying to do something sane inside abnormal termination is IMO unrealistic, and actually does not address any real problem besides some artifact only visible under debugger - or does it?

(In reply to Mike Kaganski from comment #2)
> The problem happens inside ExitProcess system call

Is that from within the crash signal handler (i.e., do you have a backtrace)?

Created attachment 177379 [details]
Screenshot

> I am not sure if we really need to care about this secondary crash. Trying
> to do something sane inside abnormal termination is IMO unrealistic, and
> actually does not address any real problem besides some artifact only
> visible under debugger - or does it?

In my case - non debug/ daily - it throws few error messages. Not to problematic, more esthetical. Not sure what happens in the case when it's actually saving something

(In reply to Stephan Bergmann from comment #3)
> Is that from within the crash signal handler (i.e., do you have a backtrace)?

Yes I have; and it seems I was wrong thinking that it was after dtor of ImplSVData was already called.

>	vcllo.dll!SalAbort(const rtl::OUString & rErrorText, bool bDumpCore) Line 333	C++
>	vcllo.dll!Application::Abort(const rtl::OUString & rErrorText) Line 275	C++
>	sofficeapp.dll!desktop::Desktop::Exception(ExceptionCategory nCategory) Line 1174	C++
>	vcllo.dll!VCLExceptionSignal_impl(void * __formal, oslSignalInfo * pInfo) Line 170	C++
>	sal3.dll!callSignalHandler(oslSignalInfo * pInfo) Line 59	C++
>	sal3.dll!`anonymous namespace'::signalHandlerFunction(_EXCEPTION_POINTERS * lpEP) Line 108	C++
>	KernelBase.dll!UnhandledExceptionFilter()	Unknown
>	ntdll.dll!RtlUserThreadStart$filt$0()	Unknown
>	ntdll.dll!__C_specific_handler()	Unknown
>	ntdll.dll!RtlpExecuteHandlerForException()	Unknown
>	ntdll.dll!RtlDispatchException()	Unknown
>	ntdll.dll!KiUserExceptionDispatch()	Unknown
>	swlo.dll!SwFrame::GetUpper() Line 679	C++
>	swlo.dll!lcl_InnerCalcLayout(SwFrame * pFrame, __int64 nBottom, bool _bOnlyRowsAndCells) Line 1627	C++
>	swlo.dll!lcl_InnerCalcLayout(SwFrame * pFrame, __int64 nBottom, bool _bOnlyRowsAndCells) Line 1607	C++
>	swlo.dll!lcl_RecalcRow(SwRowFrame & rRow, __int64 nBottom) Line 1645	C++
>	swlo.dll!lcl_RecalcTable(SwTabFrame & rTab, SwLayoutFrame * pFirstRow, SwLayNotify & rNotify) Line 1725	C++
>	swlo.dll!SwTabFrame::MakeAll(OutputDevice * pRenderContext) Line 2146	C++
>	swlo.dll!SwFrame::PrepareMake(OutputDevice * pRenderContext) Line 375	C++
>	swlo.dll!SwFrame::Calc(OutputDevice * pRenderContext) Line 1794	C++
>	swlo.dll!SwLayAction::FormatLayoutTab(SwTabFrame * pTab, bool bAddRect) Line 1516	C++
>	swlo.dll!SwLayAction::FormatLayout(OutputDevice * pRenderContext, SwLayoutFrame * pLay, bool bAddRect) Line 1401	C++
>	swlo.dll!SwLayAction::FormatLayout(OutputDevice * pRenderContext, SwLayoutFrame * pLay, bool bAddRect) Line 1407	C++
>	swlo.dll!SwLayAction::InternalAction(OutputDevice * pRenderContext) Line 576	C++
>	swlo.dll!SwLayAction::Action(OutputDevice * pRenderContext) Line 386	C++
>	swlo.dll!SwLayIdle::SwLayIdle(SwRootFrame * pRt, SwViewShellImp * pI) Line 2253	C++
>	swlo.dll!SwViewShell::LayoutIdle() Line 818	C++
>	swlo.dll!sw::DocumentTimerManager::DoIdleJobs(Timer * __formal) Line 177	C++
>	swlo.dll!sw::DocumentTimerManager::LinkStubDoIdleJobs(void * instance, Timer * data) Line 156	C++
>	vcllo.dll!Link<Timer *,void>::Call(Timer * data) Line 111	C++
>	vcllo.dll!Timer::Invoke() Line 76	C++
>	vcllo.dll!Scheduler::CallbackTaskScheduling() Line 472	C++
>	vcllo.dll!SalTimer::CallCallback() Line 55	C++
>	vclplug_winlo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 166	C++
>	vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 474	C++
>	vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 530	C++
>	vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 465	C++
>	vcllo.dll!Application::Yield() Line 533	C++
>	vcllo.dll!Application::Execute() Line 444	C++
>	sofficeapp.dll!desktop::Desktop::Main() Line 1594	C++
>	vcllo.dll!ImplSVMain() Line 199	C++
>	vcllo.dll!SVMain() Line 232	C++
>	sofficeapp.dll!soffice_main() Line 98	C++
>	soffice.bin!sal_main() Line 51	C
>	soffice.bin!main(int argc, char * * argv) Line 49	C
>	soffice.bin!invoke_main() Line 79	C++
>	soffice.bin!__scrt_common_main_seh() Line 288	C++
>	soffice.bin!__scrt_common_main() Line 331	C++
>	soffice.bin!mainCRTStartup(void * __formal) Line 17	C++
>	kernel32.dll!BaseThreadInitThunk()	Unknown
>	ntdll.dll!RtlUserThreadStart()	Unknown

I have checked that (1) system's ExitProcess is not yet started; and (2) ImplSVData is not destroyed. Also dtors of SalInstance and SalData were not yet called. I apparently thought that this crash was the same as I saw when fixing bug 146621, when I made exception handler do nothing...

Following are the steps performed recently,


Steps:
1. Open attached file (slightly modified version of attachment 143995 [details] -> https://bugs.documentfoundation.org/attachment.cgi?id=143995)
2. Press CTRL+A
3. Press CTRL+C
4. Go to second page.. and click somewhere at green highlighting (different table distribution)
5. Scroll up. Place cursor somewhere at yellow marking 
6. CTRL+V (wait)
7. CTRL+Z -> crash was not observed


Actual Result:
The CTRL+Z, UNDO operation happened as expected. LibreOffice Writer did not crash.


Version: 7.4.3.2 (x64) / LibreOffice Community
Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-IN (en_IN); UI: en-US
Calc: threaded

(In reply to sockseight from comment #6)
> 6. CTRL+V (wait)
> 7. CTRL+Z -> crash was not observed

Please pay attention to the logic of the report.

This report is *not* about a crash when working with the document; the crash in step 7 is explicitly marked as *pre-requisite* for the real issue handled here, which is a *secondary crash* of the crash reporter / document recovery dialog. Thus, some steps were chosen, that were known at the time of writing this bug to cause the *needed* first crash, so that one could see the dialog, and *then* see the actual problem.

Now you see that steps 1-7 don't crash anymore; that absolutely doesn't mean that the problem in steps 8-9 has been fixed (which is what WORKSFORME here would mean); it only means that you need other steps to get to the required state.

Hi Telesto,
Is this issue still reproducible for you with a recent version ?

The initial crash is gone, so the problem might be lingering out of sight.
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c9916d9be9c060d43fc063b76d70629162650fea
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded