Bug 115975 - Crash in: google_breakpad::ExceptionHandler::HandlePureVirtualCall()
Summary: Crash in: google_breakpad::ExceptionHandler::HandlePureVirtualCall()
Status: RESOLVED DUPLICATE of bug 115420
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.2.1 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: VCL-OpenGL
  Show dependency tree / graph
 
Reported: 2018-02-23 17:04 UTC by Mike Kaganski
Modified: 2018-02-23 19:18 UTC (History)
3 users (show)

See Also:
Crash report or crash signature: ["google_breakpad::ExceptionHandler::HandlePureVirtualCall()"]

Attachments
A small sample extension for testing the crash (6.49 KB, application/vnd.openofficeorg.extension)
2018-02-23 17:04 UTC, Mike Kaganski 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2018-02-23 17:04:37 UTC 
Created attachment 140095 [details]
A small sample extension for testing the crash

This bug was filed from the crash reporting server and is br-5cba81d3-7e73-41ea-a8b2-cc8c7cf32c6d.
=========================================

Steps to reproduce:

0. I had a brand-new user profile, by removing the old one, and then launching LO once. Then I closed LO (in case quickstart is used, it should be closed, too).
1. Double-click on an extension's .oxt file to start its installation (or run soffice -o path/to/extension.oxt). For testing, a small sample extension is attached. A confirmation ("You are about to install the extension 'FAF-0.1.5.oxt'. Click 'OK' to proceed with the installation. Click 'Cancel' to stop the installation.") appears over Extension Manager over empty text document.
2. Click Cancel. Everything disappears (the confirmation, the extension manager, and empty document).
3. Launch LO. Crash reporter window appears.

The crash report generated with Version: 6.0.2.1 (x64)
Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
Locale: ru-RU (ru_RU); Calc: CL

Also reproducible with current master.
Comment 1 Mike Kaganski 2018-02-23 17:27:08 UTC 
Call stack when reproducing with master:

> vcllo.dll!OpenGLSalGraphicsImpl::IsOffscreen() Line 161
> vcllo.dll!OpenGLSalGraphicsImpl::doFlush() Line 2071
> vcllo.dll!OpenGLFlushIdle::Invoke() Line 64
> vcllo.dll!Scheduler::ProcessTaskScheduling() Line 448
> vcllo.dll!Scheduler::CallbackTaskScheduling() Line 271
> vcllo.dll!SalTimer::CallCallback() Line 56
> vcllo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 158
> vcllo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 509
> vcllo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 555
> vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 469
> vcllo.dll!Application::Yield() Line 535
> vcllo.dll!Application::Execute() Line 449
> sofficeapp.dll!desktop::Desktop::Main() Line 1622
> vcllo.dll!ImplSVMain() Line 194
> vcllo.dll!SVMain() Line 233
> sofficeapp.dll!soffice_main() Line 166
> soffice.bin!sal_main() Line 48
> soffice.bin!main(int argc, char * * argv) Line 47
> soffice.bin!WinMain(void * _hinst, void * _dummy, char * _cmdline, int _nshow) Line 47
> soffice.bin!invoke_main() Line 99
> soffice.bin!__scrt_common_main_seh() Line 253
> soffice.bin!__scrt_common_main() Line 296
> soffice.bin!WinMainCRTStartup() Line 17
> kernel32.dll!BaseThreadInitThunk()
> ntdll.dll!RtlUserThreadStart()

"Exception thrown: read access violation.
this->mpProvider-> was 0xFFFFFFFFFFFFFFE7."

Looks OpenGL-specific.
Comment 2 Aron Budea 2018-02-23 17:52:35 UTC 
Yes, this seems to be very similar/closely related to bug 115420.
Comment 3 V Stuart Foote 2018-02-23 19:02:33 UTC 
Same stack trace as bug 115420#16 just there the STR are the Close button rather than the Cancel--but would expect it to behave the same. Does the crash occur if OpenGL rendering is disabled when doing the Update -> Cancel?

=> DUP

*** This bug has been marked as a duplicate of bug 115420 ***