https://bugs.documentfoundation.org/show_bug.cgi?id=98558

--- Comment #21 from Markus Mohrhard <markus.mohrh...@googlemail.com> ---
(In reply to Timur from comment #20)
> According to what's written and tested, I change the title to "FILEOPEN: ODS
> with large chart out of memory 'Bad Allocation' on 32-bit LO since LO 4.0".
> It worked before 4.0, so looks like a regression. Now, it works on 64-bit LO
> only. Tested in Windows.
> Opening in Linux with 32-bit LO was very slow, but it did open. 
> 
> 
> 0:000> kb
> ChildEBP RetAddr  Args to Child              
> 00f1b098 77889c4e ffffffff 0000014d 00f1fe00 ntdll!ZwTerminateProcess+0x12
> 00f1b0b4 755979dc 00000000 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x85
> 00f1b0c8 70453fac 0000014d 00f1b11c 7045427e kernel32!ExitProcessStub+0x12
> 00f1b0d4 7045427d 0000014d 9032f933 00f1fe00 MSVCR120!__crtExitProcess+0x15
> [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 774]
> 00f1b11c 7049bbc7 0000014d 00000001 00000000 MSVCR120!doexit+0x115
> [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 678]
> 00f1b130 6f74102b 0000014d 9036f64b 6fd3a890 MSVCR120!_exit+0xf
> [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 433]
> 00f1b174 6f745835 00f1fc30 704397f2 00f1fe00 sofficeapp!desktop::`anonymous
> namespace'::FatalError+0x10b
> [c:\cygwin\home\tinderbox\master\desktop\source\app\app.cxx @ 447]
> 00f1fe0c 64b28c3c 90370140 00f1fe44 00000001
> sofficeapp!desktop::Desktop::Main+0x1935
> [c:\cygwin\home\tinderbox\master\desktop\source\app\app.cxx @ 1678]
> 00f1fe3c 64b290af 00000000 00f1febc 6f77d924 vcllo!ImplSVMain+0xbc
> [c:\cygwin\home\tinderbox\master\vcl\source\app\svmain.cxx @ 167]
> 00f1fe48 6f77d924 9036b983 6f7e674c 00000000 vcllo!SVMain+0x2f
> [c:\cygwin\home\tinderbox\master\vcl\source\app\svmain.cxx @ 205]
> *** ERROR: Symbol file could not be found.  Defaulted to export symbols for
> S:\OFFICE\LO-OO-parallel\master\program\soffice.bin - 
> 00f1febc 0030100a 90c95dc0 00f1fed4 0030103a sofficeapp!soffice_main+0x74
> [c:\cygwin\home\tinderbox\master\desktop\source\app\sofficemain.cxx @ 135]
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> 00f1fec8 0030103a 004d8f18 00f1feec 00301078 soffice+0x100a
> 00f1fed4 00301078 00000002 004d8f18 00000002 soffice!main+0x1a
> 00f1feec 003012ce 00300000 00000000 00474166 soffice!main+0x58
> 00f1ff38 7559337a 7efde000 00f1ff84 77869882 soffice!main+0x2ae
> 00f1ff44 77869882 7efde000 76c7b5f6 00000000 kernel32!BaseThreadInitThunk+0xe
> 00f1ff84 77869855 0030119f 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
> 00f1ff9c 00000000 0030119f 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b

That backtrace is completely useless. That is the place that actually catches
the exception and not the one that throws the exception.

The best way would be to start it in Visual Studio and break on thrown
std::bad_alloc exceptions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to