Bug 74432 - Crash with "invalid vector <T> subscript" when referencing named range including formula and Basic function
Summary: Crash with "invalid vector <T> subscript" when referencing named range includ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Windows (All)
: high blocker
Assignee: Not Assigned
Whiteboard: (target:4.2.5)
Depends on:
Reported: 2014-02-03 08:41 UTC by Peter Lehmkuhle
Modified: 2015-01-22 21:49 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Screenshot of callstack. (76.61 KB, image/png)
2014-05-05 17:29 UTC, Raymond Martineau
Reproduction case (15.92 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-05-05 18:24 UTC, Raymond Martineau
Testcase for calc sorting crash (69.85 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-06-23 14:05 UTC, Norbert Scheibner

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Lehmkuhle 2014-02-03 08:41:00 UTC

I just had to downgrade to 4.1 because of this bug:

In my spreadsheet I have a named range (one cell) "WTp0". This one cell contains a formula which is based on a LibreOffice Basic function. This function calculates a date based on another date (today()).
I have seen bug 72473. But as that bug involves sorting and mine does not, I decided to file a new bug.

Today I repeatedly tried to enter "=WTp0" into another cell to use the calculated date there.

LibreOffice repeatedly crashed with "invalid vector <T> subscript".

I will try to provide a copy of my spreadsheet, but I will have to remove sensitive data first.

Is there a way to get a more verbose error message while using 4.2 release? A stack trace maybe?

Comment 1 Julien Nabet 2014-02-03 19:11:46 UTC
Peter: it would be very useful indeeed! Here's a link which may help you:
Comment 2 Julien Nabet 2014-02-09 20:02:15 UTC
Put it at NEEDINFO for the moment.
Comment 3 Raymond Martineau 2014-05-05 17:28:37 UTC
Extracted a crash dump.  In particular, I'm getting this bug simply by sorting a list a few times, and it's also inconsistant when it does crash.  

I'd say the crash occurs in unshareFormulaCell. 

0:012> !analyze -v
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files (x86)\LibreOffice 4\program\soffice.bin - 

75961d4d 8b4c2454        mov     ecx,dword ptr [esp+54h]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 75961d4d (KERNELBASE!RaiseException+0x00000048)
   ExceptionCode: e06d7363 (C++ EH exception)
  ExceptionFlags: 00000001
NumberParameters: 3
   Parameter[0]: 19930520
   Parameter[1]: 0101e3b4
   Parameter[2]: 7519ca7c

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=00000001 ebx=00000000 ecx=00000000 edx=00000000 esi=00000002 edi=00000002
eip=77cdd72c esp=0e13f5b4 ebp=0e13f734 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
77cdd72c c21400          ret     14h



PROCESS_NAME:  soffice.bin

OVERLAPPED_MODULE: Address regions for 'i18npoollo' and 'faultrep.dll' overlap

ERROR_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>






APP:  soffice.bin

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre



LAST_CONTROL_TRANSFER:  from 7598ea7f to 77cdd72c

0e13f5b0 7598ea7f 00000002 0b486e08 00000001 ntdll!NtWaitForMultipleObjects+0xc
0e13f734 75a89188 00000000 0b486e08 00000000 KERNELBASE!WaitForMultipleObjectsEx+0xdc
0e13f750 557a64b1 00000002 0b486e08 00000000 KERNEL32!WaitForMultipleObjects+0x19
0e13f788 750fc556 0b486de4 77739469 00000000 sysdtrans!CMtaOleClipboard::clipboardChangedNotifierThreadProc+0x51
0e13f7c0 750fc600 00000000 0e13f7d8 75a8919f MSVCR100!_callthreadstartex+0x1b
0e13f7cc 75a8919f 0b192cc0 0e13f81c 77cea8cb MSVCR100!_threadstartex+0x64
0e13f7d8 77cea8cb 0b192cc0 759ba655 00000000 KERNEL32!BaseThreadInitThunk+0xe
0e13f81c 77cea8a1 ffffffff 77cdf67e 00000000 ntdll!__RtlUserThreadStart+0x20
0e13f82c 00000000 750fc59c 0b192cc0 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND:  .cxr 0x0 ; kb

sysdtrans!CMtaOleClipboard::clipboardChangedNotifierThreadProc+51 [c:\cygwin\home\buildslave\source\libo-core\dtrans\source\win32\clipb\mtaoleclipb.cxx @ 837]
557a64b1 8d7e34          lea     edi,[esi+34h]

FAULTING_SOURCE_LINE:  c:\cygwin\home\buildslave\source\libo-core\dtrans\source\win32\clipb\mtaoleclipb.cxx

FAULTING_SOURCE_FILE:  c:\cygwin\home\buildslave\source\libo-core\dtrans\source\win32\clipb\mtaoleclipb.cxx



SYMBOL_NAME:  sysdtrans!CMtaOleClipboard::clipboardChangedNotifierThreadProc+51

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: sysdtrans

IMAGE_NAME:  sysdtrans.dll


FAILURE_BUCKET_ID:  APPLICATION_FAULT_e06d7363_sysdtrans.dll!CMtaOleClipboard::clipboardChangedNotifierThreadProc

BUCKET_ID:  APPLICATION_FAULT_APPLICATION_FAULT_sysdtrans!CMtaOleClipboard::clipboardChangedNotifierThreadProc+51


FAILURE_ID_HASH_STRING:  um:application_fault_e06d7363_sysdtrans.dll!cmtaoleclipboard::clipboardchangednotifierthreadproc

FAILURE_ID_HASH:  {1c446a8b-ac87-ed13-7e14-38b40d9d320e}

Followup: MachineOwner
Comment 4 Raymond Martineau 2014-05-05 17:29:22 UTC
Created attachment 98505 [details]
Screenshot of callstack.
Comment 5 Raymond Martineau 2014-05-05 18:24:05 UTC
Created attachment 98509 [details]
Reproduction case

Minimal spreadsheet to reproduce crash.  

Instructions - costantly sort Columb B descending.  LibreOffice will eventually crash.

Likely linked to formula used in A2.
Comment 6 Laurent Balland 2014-05-05 20:23:57 UTC

Using test case of comment #5:
I CAN reproduce with LibO 4.2.4 RC1 Version:
Build ID: d4c441391e20647b3d2e8dde4d20aa868e77e515

I can NOT reproduce with Version:
Build ID: 8ff260e47873674ca03a334f6b3198d66dc68db7
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-05-04_21:46:54

It may have been fixed by resolution of bug 76607. Unfortunately, it is not sure it will be include in time for 4.2.4 final.

@Raymond: please test with a recent build [1] and feel free to reopen the bug if you find it is not fixed.

[1] For instance, from http://dev-builds.libreoffice.org/daily/libreoffice-4-2/Win-x86@42/
Comment 7 Norbert Scheibner 2014-05-19 08:53:03 UTC
I got still problems sorting.

I'll try to investigate further, but for now I just reopen this bug.
Comment 8 Julien Nabet 2014-05-19 10:12:09 UTC
Norbert: it seems it's fixed from 4.2.5 according to Laurent's comment (see https://bugs.freedesktop.org/show_bug.cgi?id=74432#c6)
Did you test on a daily build from 4.2? (see http://dev-builds.libreoffice.org/daily/libreoffice-4-2/Win-x86@42/)
Comment 9 Norbert Scheibner 2014-06-23 13:30:07 UTC
I just tried 4.2.5 final.
It crashes now without any message immediately.

Filling empty cells with content before sorting or changing the starting cell from where to call the sort does not help anymore. It helped in 4.2.4 frome time to time, but it wasn't even a stable workaround.

Extrem annoying.

I'll try to create a testfile.
Comment 10 Norbert Scheibner 2014-06-23 14:05:33 UTC
Created attachment 101593 [details]
Testcase for calc sorting crash

Thats a actual file I use.
I haven't yet found out the actual exact circumstances under which calc crashes, so I took something really in use.
I sort the table by "Sortierhilfe", "Ort" and "Straße" to trigger the crash.
Comment 11 Laurent Balland 2014-06-23 14:52:12 UTC
(In reply to comment #10)
> Created attachment 101593 [details]
> Testcase for calc sorting crash
> Thats a actual file I use.
> I haven't yet found out the actual exact circumstances under which calc
> crashes, so I took something really in use.
> I sort the table by "Sortierhilfe", "Ort" and "Straße" to trigger the crash.

@Norbert: Thanks for your tests. I can reproduce crash with your test file with LibO final. However, you should not reopen this bug but open a new one, because your problem is different from this actual bug report: I can NOT reproduce crash of initial test case of this bug report (attachment 98509 [details]) with LibO (so this bug should be considered as fixed); I can reproduce crash with your testcase document (so the sorting crash you pointed out is a different one from this bug report).
I closed the bug as fixed as explain above. Feel free to reopen this bug report if you can reproduce crash with the initial testcase.

Please open a new bug report with your testcase.