Bug 86493 - Writer crashes when increasing Zoom factor in Web layout view
Summary: Writer crashes when increasing Zoom factor in Web layout view
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Ashod Nakashian
Whiteboard: target:4.5.0 target:4.4.2 target:4.3.7
Keywords: notBibisectable, regression
: 83199 (view as bug list)
Depends on:
Blocks: Writer-Web-Layout
  Show dependency treegraph
Reported: 2014-11-20 16:42 UTC by levy.jeanmarc
Modified: 2016-10-17 22:38 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

File that crashes with LO 4.3.4 and not with 4.2.7 (22 bytes, text/plain)
2014-11-20 16:51 UTC, levy.jeanmarc
File that crashes with LO 4.3.4 and not with 4.2.7 (2.52 MB, application/vnd.oasis.opendocument.text)
2014-11-21 09:24 UTC, levy.jeanmarc
BackTrace (6.87 KB, text/plain)
2014-12-13 20:21 UTC, levy.jeanmarc
Bibisected backtrace to ignore - not the reported crash (5.67 KB, text/plain)
2014-12-14 02:06 UTC, Matthew Francis
BackTrace libo-master~2015-02-14 (8.27 KB, text/plain)
2015-02-16 08:13 UTC, levy.jeanmarc
BackTrace libo-master~2015-02-16 (8.25 KB, text/plain)
2015-02-16 10:48 UTC, levy.jeanmarc
backtrace_libo-master~2015-02-18.txt (8.36 KB, text/plain)
2015-02-20 08:19 UTC, levy.jeanmarc
BackTrace libo-master~2015-02-23 (8.34 KB, text/plain)
2015-02-24 15:37 UTC, levy.jeanmarc
BackTrace LibreOffice (7.90 KB, text/plain)
2015-02-24 16:00 UTC, levy.jeanmarc

Note You need to log in before you can comment on or make changes to this bug.
Description levy.jeanmarc 2014-11-20 16:42:26 UTC
Problem description: 

Steps to reproduce:
1. open file (see file attached)....
2. change zoom factor to 200%....
3. cry ;-)....

Current behavior: crash
Comment 1 levy.jeanmarc 2014-11-20 16:51:31 UTC
Created attachment 109760 [details]
File that crashes with LO 4.3.4 and not with 4.2.7
Comment 2 levy.jeanmarc 2014-11-20 16:52:09 UTC
Comment on attachment 109760 [details]
File that crashes with LO 4.3.4 and not with 4.2.7

Comment 3 Terrence Enger 2014-11-20 23:11:42 UTC
As this bug seems to have been created in status NEW, I am setting it
UNCONFIRMED and normal priority.

Note that only with Internet Explorer running on Windows was I able to
download the document by following the link in comment 03.  Iceweasel
on Linux downloaded a zero-length file.

Neither on Windows nor with a recent LibreOffice on Linux was I able
to come close to a zoom factor of 200%.

(*) On Windows Vista with 
        Build ID: 4f18bd405831c31cd49190046f7bafd805a47d7d
        TinderBox: Win-x86@39, Branch:master, Time: 2014-11-20_09:39:04
        Locale: en_CA
    some time after my first zoom-in (plus sign in the zoom control in
    the status bar) the zoom factor was 120%.  Two more zoom-in leave
    the entire Writer window grayed out and the mouse cursor is
    chasing its tail around; TasK Manager shows modest CPU usage (1%,
    3%, 4%).

(*) With daily dbgutil bibisect version 2014-11-20, I named the file
    on the command line.  LibreOffice pegged the CPU essentially
    continuously, and I cancelled the job after at least five minutes.
    The terminal shows many instances (overflowing the terminal
    buffer) of the message:
        warn:sw.resizeview:13569:1:sw/source/core/view/vdraw.cxx:237: Trying to move anchor from invalid page - fix layouting!

For comparison, the 43all bibisect repository version oldest opens the
file promtly and zooms to and beyond 200% without any evident problem.
I am *not* calling this bug a regression because I have not succeeded
in reproducing the reporter's problem.
Comment 4 levy.jeanmarc 2014-11-21 09:24:21 UTC
Created attachment 109796 [details]
File that crashes with LO 4.3.4 and not with 4.2.7
Comment 5 tommy27 2014-11-29 18:47:59 UTC
I confirm bug in, and alpha under Win8.1

no crash with

hence regression, needs bibisecting
Comment 6 Matthew Francis 2014-12-13 06:36:26 UTC
I do not reproduce in 4.5 master on Linux, and I get the following bibisect results from 44 (on the basis of a search for where it ceases to crash - "bad" means fixed here):

5b2c61f6b34f03146c2d03da03a7b7f546ce56b8 is the first bad commit
commit 5b2c61f6b34f03146c2d03da03a7b7f546ce56b8
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sat Oct 18 00:19:03 2014 +0000

    commit abf842e4b125b9f863ea4c2af17ad6ac7d82b15e
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Thu Jun 5 10:16:52 2014 +0100
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Thu Jun 5 13:35:53 2014 +0100
        coverity#705323 Missing break in switch, assuming its intentional
        Change-Id: Ibb8fe4e1d13a24f810fbdf4978606c35890a9cfd

# bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6
# good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474
git bisect start 'latest' 'oldest'
# good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81
git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048
# bad: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd
git bisect bad 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5
# bad: [1a63057f6378db7c6b8af1171b7b140f7583f246] source-hash-59f84b4a2c082382767f12e0c7a06a3f0b52e721
git bisect bad 1a63057f6378db7c6b8af1171b7b140f7583f246
# bad: [3787e4f82e47eaf4fa454afdca671272e50f875b] source-hash-0e09134a4a4cbb0639fc586c560c6fb2765487be
git bisect bad 3787e4f82e47eaf4fa454afdca671272e50f875b
# bad: [5b2c61f6b34f03146c2d03da03a7b7f546ce56b8] source-hash-abf842e4b125b9f863ea4c2af17ad6ac7d82b15e
git bisect bad 5b2c61f6b34f03146c2d03da03a7b7f546ce56b8
# good: [1022c199a7d20dde7600f08007b5e2cac81e55f4] source-hash-df903c3e2084d8cc33e3935a1668b8b46e25201f
git bisect good 1022c199a7d20dde7600f08007b5e2cac81e55f4
# skip: [5ab97df01d7167dc7b472cf0f5b21fea4fccd232] source-hash-b651ed7a6700b560052b67102a65f06a498dd182
git bisect skip 5ab97df01d7167dc7b472cf0f5b21fea4fccd232
# good: [7e3ee4ad7f79565293c1ff9c20e099101435d3c1] source-hash-312ffe07bbef6b8dbc14ce38c0a726f69dd90946
git bisect good 7e3ee4ad7f79565293c1ff9c20e099101435d3c1
# good: [a40d8c51092e2ab68f3c483b782e5eac0fdf5e3b] source-hash-f18a86759b20d13c660a6224fe26451cb64bd92d
git bisect good a40d8c51092e2ab68f3c483b782e5eac0fdf5e3b
# first bad commit: [5b2c61f6b34f03146c2d03da03a7b7f546ce56b8] source-hash-abf842e4b125b9f863ea4c2af17ad6ac7d82b15e
Comment 7 Matthew Francis 2014-12-13 11:40:30 UTC
Two obvious crashes are fixed in the above range, but the fixes had already landed in which is mentioned as having been reproduced upon (I assume the version "4.3.4" mentioned in comment 1 refers to as this is what the Version field is set to)

Could the original submitter and/or reproducer please:
- Confirm whether they still experience the crash in / 4.4beta1 (or later) and/or current master
- If it still crashes, follow https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg to get a Windows backtrace and attach it here

If this is a genuinely Windows specific bug rather than what I bibisected above, then the backtrace will be needed to investigate any further.

Setting to NEEDINFO - please set the status back to NEW when further information is attached (either the fact that it can no longer be reproduced on Windows, or a backtrace)
Comment 8 levy.jeanmarc 2014-12-13 20:21:07 UTC
Created attachment 110826 [details]

I confirm crash with both and 4.4.0
Comment 9 Matthew Francis 2014-12-14 02:06:35 UTC
Created attachment 110829 [details]
Bibisected backtrace to ignore - not the reported crash

Thanks for following up. To avoid later confusion, the attached is a backtrace from the previously bibisected crash which has already been fixed. The two seem unrelated.

I'm going to assume then that the but reported here isn't reproducible on Linux (at least not on 64-bit), so it's unfortunately not bibisectable

-> Setting status back to NEW
-> Changing to Whiteboard: notBibisectable

There is also a partial backtrace attached to bug 83199 which resembles the backtrace supplied here, but I'm suspicious that several different crashes are getting mixed up in the reproduction here, so probably best not to merge the two bugs for now
Comment 10 levy.jeanmarc 2015-02-01 07:53:03 UTC
It also crashes with LO 4.4.0
Comment 11 Julien Nabet 2015-02-08 16:32:16 UTC
Jean-Marc: did the crash in 4.4.0 show the same bt as the one you already reported?
If interested, you can give a try to daily builds (see http://dev-builds.libreoffice.org/daily/), it could be useful to know if last daily build (above all 4.5 and 4.4) still contain this bug.
Comment 12 levy.jeanmarc 2015-02-08 19:15:56 UTC
It also crashes with libreoffice-4-4~2015-02-06
Comment 13 Julien Nabet 2015-02-08 20:33:53 UTC
Ok thank you for your feedback.
I think I can't help here.
Comment 14 levy.jeanmarc 2015-02-09 16:31:05 UTC
It also crashes with libreoffice-4-4~2015-02-09
Comment 15 levy.jeanmarc 2015-02-11 08:29:05 UTC
It also crashes with LO
Comment 16 levy.jeanmarc 2015-02-11 09:32:55 UTC
It also crashes with libo-master~2015-02-11
Comment 17 levy.jeanmarc 2015-02-13 07:25:09 UTC
It also crashes with libo-master~2015-02-13 and libo-43~2015-02-12
Comment 18 levy.jeanmarc 2015-02-13 19:23:51 UTC
It also crashes with LibreOffice
Comment 19 levy.jeanmarc 2015-02-15 14:13:40 UTC
It also crashes with libo-43~2015-02-15
Comment 20 levy.jeanmarc 2015-02-15 22:25:05 UTC
It also crashes with libo-master~2015-02-14
Comment 21 Julien Nabet 2015-02-16 06:29:27 UTC
Could you provide a bt with last master version? (just to know if it's always the same bt).
Comment 22 levy.jeanmarc 2015-02-16 07:20:03 UTC
Bàck trace with libo-master~2015-02-14

*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\swlo.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\sfxlo.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\tllo.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\sofficeapp.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\soffice.bin - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\sal3.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\salhelper3MSC.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\sysdtrans.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\Jean-Marc\LibreOfficeParallele\libo-master~2015-02-14\program\updchklo.dll - 

530249f5 8a0a            mov     cl,byte ptr [edx]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 530249f5 (vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+0x00000015)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 95c2d4e2
Attempt to read from address 95c2d4e2

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=00c7ec88 ebx=21b92c50 ecx=95c2d4e2 edx=95c2d4e2 esi=000115c8 edi=00000000
eip=530249f5 esp=00c7ec60 ebp=00c7ec60 iopl=0         nv up ei ng nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010286
530249f5 8a0a            mov     cl,byte ptr [edx]          ds:002b:95c2d4e2=??


PROCESS_NAME:  soffice.bin

ERROR_CODE: (NTSTATUS) 0xc0000005 - L




READ_ADDRESS:  95c2d4e2 

530249f5 8a0a            mov     cl,byte ptr [edx]



APP:  soffice.bin

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) x86fre




LAST_CONTROL_TRANSFER:  from 52e2f1fc to 530249f5

WARNING: Stack unwind information not available. Following frames may be wrong.
00c7ec60 52e2f1fc 00c7ec88 95c2d4e2 00000000 vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+0x15
00c7ec78 53015605 00c7ecb8 ffff8ae3 00000000 vcllo!BitmapReadAccess::GetPixel+0x1c
00c7ecf4 530160f3 ffff8ae3 000117c9 6f37552f vcllo!Bitmap::ImplScaleFast+0x215
00c7ed50 53022c6f 00c7ed90 00c7ed98 00000002 vcllo!Bitmap::Scale+0x1a3
00c7ed74 53022d27 00c7ed90 00c7ed98 00000002 vcllo!BitmapEx::Scale+0x1f
00c7edb0 20de38f2 00000008 00000002 ffbc1141 vcllo!BitmapEx::Scale+0x67
00c7ef08 20de1683 0660e034 0b120ba8 00c7f201 swlo!SwFrmFmt::MakeGraphic+0x3b32
00c7f104 21096996 00c7f254 00000000 ffbc0c3d swlo!SwFrmFmt::MakeGraphic+0x18c3
00c7f274 20b6c31c 01000000 ffbc0c95 2154fed4 swlo!SwViewShell::ImplEndAction+0x5a6
00c7f2dc 20d28237 00000000 00000000 5d9ee060 swlo!SwCrsrShell::EndAction+0xcc
00c7f2fc 21181784 00c7f418 0b3d2668 52a670ed swlo!SwEditShell::EndAllAction+0x37
00c7f384 52ab382e 6f374b0b 00f13d30 00c7f3ec swlo!SwDocShell::DoFlushDocInfo+0x44
00c7f3a0 52a09775 067adbbc 00c7f440 6f374b53 sfxlo!SfxBaseModel::lockControllers+0x1ae
00c7f3f8 52a1aff2 00c7f418 6f374c93 067a4ea0 sfxlo!ExecuteQuerySaveDocument+0x4635
00c7f438 52a1a0ae 067a4e60 067a4e60 0b35f228 sfxlo!ExecuteQuerySaveDocument+0x15eb2
00c7f4bc 20c61b4d 067a4e8c 00c7f518 ffbc0b65 sfxlo!ExecuteQuerySaveDocument+0x14f6e
00c7f52c 20c61e0d 00001388 00000000 0b3d64b8 swlo!SwDoc::isXForms+0x2bb4d
00c7f540 20c615da 00000001 00000000 0b2e5da0 swlo!SwDoc::isXForms+0x2be0d
00c7f554 2129b527 00000001 00000000 ffbc06c9 swlo!SwDoc::isXForms+0x2b5da
00c7f880 21293d4e 21bd0cb8 00c7f8a0 52931794 swlo!SwView::StateStatusLine+0xd67
00c7f88c 52931794 0b2e5da0 21bd0cb8 0b77b728 swlo!SwView::SetMailMergeConfigItem+0x14e
00c7f8a0 529262d6 21b03244 21bd0cb8 21849c20 sfxlo!SfxDispatcher::_FillState+0x44
00c7f8f4 52925d0f 21b03230 6f37418b 00002710 sfxlo!SfxBindings::Update_Impl+0x106
00c7f920 2129742e 00000000 ffbc07fd 21d89780 sfxlo!SfxBindings::Update+0x1af
00c7f9b4 21293d0e 21d89780 00c7fa10 5292df1d swlo!SwView::ExecuteStatusLine+0x62e
00c7f9c0 5292df1d 0b2e5da0 21d89780 6f3742bb swlo!SwView::SetMailMergeConfigItem+0x10e
00c7fa10 529309b9 0b2e5da0 0005e600 21d89780 sfxlo!SfxDispatcher::Call_Impl+0x24d
00c7fa50 5293053e 21d89780 00c7fa6c 5ba94621 sfxlo!SfxDispatcher::PostMsgHandler+0xa9
00c7fa5c 5ba94621 0b77b728 21d89780 00c7fa7c sfxlo!SfxDispatcher::LinkStubPostMsgHandler+0xe
00c7fa6c 52ad5efc 21d89780 21d3bbe0 00c7fa8c tllo!Link::Call+0x11
00c7fa7c 5ba94621 0b76f328 21d89780 00c7faac sfxlo!com_sun_star_comp_sfx2_GlobalEventBroadcaster_get_implementation+0x2dc
00c7fa8c 52f2a802 21d89780 6f3742d3 00000482 tllo!Link::Call+0x11
00c7faac 52f2b074 21d3bbe0 00000000 00000482 vcllo!vcl::Window::ImplAsyncFocusHdl+0x33e2
00c7fafc 532433d9 04d14a28 04d16e68 00000016 vcllo!vcl::Window::ImplAsyncFocusHdl+0x3c54
00c7fb14 53245c96 00090312 21d3bbe0 00000482 vcllo!vcl::OpenTTFontBuffer+0x4a9a9
00c7fb54 53246280 00090312 00000482 00000000 vcllo!vcl::OpenTTFontBuffer+0x4d266
00c7fba0 773162fa 00090312 00000482 00000000 vcllo!vcl::OpenTTFontBuffer+0x4d850
00c7fbcc 77316d3a 53246220 00090312 00000482 USER32!InternalCallWinProc+0x23
00c7fc44 773177c4 00000000 53246220 00090312 USER32!UserCallWinProcCheckWow+0x109
00c7fca4 7731788a 53246220 00000000 00c7fce8 USER32!DispatchMessageWorker+0x3bc
00c7fcb4 53211344 00c7fccc 00f13d30 00000001 USER32!DispatchMessageW+0xf
00c7fce8 53211bac 00f13d01 00000000 534b3288 vcllo!vcl::OpenTTFontBuffer+0x18914
00c7fd0c 53192cd0 00f13d01 00000000 047a808c vcllo!vcl::OpenTTFontBuffer+0x1917c
00c7fea4 531992e5 00000000 00000001 53199669 vcllo!Application::Execute+0x70
00c7febc 5da6d570 6f3747c0 00ec3745 5da9e2d0 vcllo!DeInitVCL+0x635
00c7ff14 00db101e 00ec3745 00db12b2 00db0000 sofficeapp!soffice_main+0x80
00c7ff68 774a338a 7efde000 00c7ffb4 77e09f72 soffice+0x101e
00c7ff74 77e09f72 7efde000 720cbae2 00000000 kernel32!BaseThreadInitThunk+0xe
00c7ffb4 77e09f45 00db1183 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
00c7ffcc 00000000 00db1183 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND:  dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; .cxr 0x0 ; kb


SYMBOL_NAME:  vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+15

FOLLOWUP_NAME:  MachineOwner


IMAGE_NAME:  vcllo.dll





FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_before_write_c0000005_vcllo.dll!bitmapreadaccess::getpixelfor_24bit_tc_bgr

FAILURE_ID_HASH:  {f9599b3c-2d67-566f-2b88-27c23b18bd46}

Followup: MachineOwner
Comment 23 levy.jeanmarc 2015-02-16 08:13:41 UTC
Created attachment 113424 [details]
BackTrace libo-master~2015-02-14
Comment 24 levy.jeanmarc 2015-02-16 10:47:59 UTC
It also crashes with  libo-master~2015-02-16 (see BT)
Comment 25 levy.jeanmarc 2015-02-16 10:48:50 UTC
Created attachment 113428 [details]
BackTrace libo-master~2015-02-16
Comment 26 Julien Nabet 2015-02-16 14:49:58 UTC
Chris/Caolan: Jean-Marc's last bt shows vcl part, one for you?

Also, noticing this part of bt:
00b1e590 0126f1fc 00b1e5b8 00000000 00000000 vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+0x15
00b1e5a8 01455605 00b1e5e8 ffff8ae3 00000000 vcllo!BitmapReadAccess::GetPixel+0x1c
00b1e624 014560f3 ffff8ae3 000117cb ef945dce vcllo!Bitmap::ImplScaleFast+0x215
00b1e680 01462c6f 00b1e6c0 00b1e6c8 00000002 vcllo!Bitmap::Scale+0x1a3
00b1e6a4 01462d27 00b1e6c0 00b1e6c8 00000002 vcllo!BitmapEx::Scale+0x1f
00b1e6e0 23793962 00000008 00000002 23164a31 vcllo!BitmapEx::Scale+0x67

would it be relevant to replace macros from http://opengrok.libreoffice.org/xref/core/include/vcl/bmpacc.hxx#30 with plain C++ (I thought about more control like clang, cppcheck, coverity, etc.)?
See http://opengrok.libreoffice.org/xref/core/include/vcl/bmpacc.hxx#30
(if yes, I could give it a try).
Comment 27 levy.jeanmarc 2015-02-20 08:10:36 UTC
It also crashes with libo-master 2015-12-18
Comment 28 levy.jeanmarc 2015-02-20 08:19:47 UTC
Created attachment 113540 [details]
Comment 29 levy.jeanmarc 2015-02-24 15:37:14 UTC
It also crashes with LibO Parallel libo-master~2015-02-23 (see bt attached)
Comment 30 levy.jeanmarc 2015-02-24 15:37:59 UTC
Created attachment 113639 [details]
BackTrace libo-master~2015-02-23
Comment 31 levy.jeanmarc 2015-02-24 15:58:16 UTC
It also crashes with LibreOffice (see BT attached)
Comment 32 levy.jeanmarc 2015-02-24 16:00:51 UTC
Created attachment 113640 [details]
BackTrace LibreOffice
Comment 33 levy.jeanmarc 2015-02-26 09:07:55 UTC
It doesn't crashe with LibO libo-master~2015-02-26 !
Comment 34 Julien Nabet 2015-02-26 09:24:19 UTC
When looking at last Caolan's commits (see http://cgit.freedesktop.org/libreoffice/core/log/?qt=author&q=caolan), I suppose we can thank him for this :-)

Caolan: may we consider this one as FIXED or do you plan first to backport your commits on 4.4 branch?
Comment 35 levy.jeanmarc 2015-03-09 07:33:33 UTC
It crashes with libreoffice-4-4~2015-03-08
Comment 36 Caolán McNamara 2015-03-09 13:15:49 UTC
I wonder if this was c91bfb9ac7d110c5dca0ea34ec0e1668a985b34c 

commit c91bfb9ac7d110c5dca0ea34ec0e1668a985b34c
Author: Ashod Nakashian <ashodnakashian@yahoo.com>
Date:   Mon Feb 23 22:33:27 2015 -0500

    Fix crash while scaling large bitmaps.
    Fast bitmap scaling overflowed the LUT used by the nearest-neighbor algorithm.
    When a bitmap has 46k pixel on a side and is enlarged, the scaling code
    overflows the 32-bit long, resulting in negative indexes, which then segfaults.
    This isn't as rare as it sounds. At least in web-view in writer the border/shadow
    bitmap is as long as the document (which is an issue in its own right,)
    which can overflow for large documents during scaling and segfault.
Comment 37 Caolán McNamara 2015-03-09 13:20:27 UTC
Lets try that as https://gerrit.libreoffice.org/#/c/14809/
Comment 38 Commit Notification 2015-03-09 13:58:30 UTC
Ashod Nakashian committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":


Resolves: fdo#86493 Fix crash while scaling large bitmaps.

It will be available in 4.4.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 39 levy.jeanmarc 2015-03-10 19:27:34 UTC
It doesn't crash with libo-44~2015-03-10
Comment 40 Michael Stahl (CIB) 2015-03-13 21:47:39 UTC
yay Ashod fixed this one!

probably affect only 32-bit builds, due to use of "long" type.
Comment 41 Commit Notification 2015-03-13 21:50:39 UTC
Ashod Nakashian committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":


Resolves: fdo#86493 Fix crash while scaling large bitmaps.

It will be available in 4.3.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 42 Ashod Nakashian 2015-03-14 02:09:44 UTC
Yes, 32-bit only issue.

Didn't know there was a bug filed. Crashed frequently enough for me that I ran it under a debugger and it took a few minutes until it hit it again and the fix was obvious from there.
Comment 43 levy.jeanmarc 2015-03-14 08:02:21 UTC
It crashes with libo-43~2015-03-13_14.52.09
Comment 44 Ashod Nakashian 2015-03-14 16:41:28 UTC
Levy, it wouldn't have made it into that build as the fix was merged later. It should be in today's (2015-03-14) nightly though. Would be great if you could verify with that build (or newer). Thanks.
Comment 45 levy.jeanmarc 2015-03-19 12:35:51 UTC
It also doesn’t crash with (libo-43~2015-03-19).
Comment 46 Michael Stahl (CIB) 2015-04-16 21:31:21 UTC
*** Bug 83199 has been marked as a duplicate of this bug. ***
Comment 47 Robinson Tryon (qubit) 2015-12-17 10:58:13 UTC Comment hidden (obsolete)