Problem description: Steps to reproduce: 1. open file (see file attached).... 2. change zoom factor to 200%.... 3. cry ;-).... Current behavior: crash
Created attachment 109760 [details] File that crashes with LO 4.3.4 and not with 4.2.7
Comment on attachment 109760 [details] File that crashes with LO 4.3.4 and not with 4.2.7 http://1drv.ms/1F7q2oL
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 Version: 4.4.0.0.alpha2+ 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.
Created attachment 109796 [details] File that crashes with LO 4.3.4 and not with 4.2.7
I confirm bug in 4.3.0.4, 4.3.3.2 and 4.5.0.0 alpha under Win8.1 no crash with 4.2.6.2 hence regression, needs bibisecting
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 source-hash-abf842e4b125b9f863ea4c2af17ad6ac7d82b15e 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
Two obvious crashes are fixed in the above range, but the fixes had already landed in 4.3.3.2 which is mentioned as having been reproduced upon (I assume the version "4.3.4" mentioned in comment 1 refers to 4.3.0.4 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.3.5.1 / 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)
Created attachment 110826 [details] BackTrace I confirm crash with both 4.3.5.1 and 4.4.0
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
It also crashes with LO 4.4.0
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.
It also crashes with libreoffice-4-4~2015-02-06
Ok thank you for your feedback. I think I can't help here.
It also crashes with libreoffice-4-4~2015-02-09
It also crashes with LO 4.4.0.3
It also crashes with libo-master~2015-02-11
It also crashes with libo-master~2015-02-13 and libo-43~2015-02-12
It also crashes with LibreOffice 4.4.1.1
It also crashes with libo-43~2015-02-15
It also crashes with libo-master~2015-02-14
Could you provide a bt with last master version? (just to know if it's always the same bt).
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 - FAULTING_IP: vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+15 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 vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+0x15: 530249f5 8a0a mov cl,byte ptr [edx] ds:002b:95c2d4e2=?? FAULTING_THREAD: 0000173c PROCESS_NAME: soffice.bin ERROR_CODE: (NTSTATUS) 0xc0000005 - L EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - L EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 95c2d4e2 READ_ADDRESS: 95c2d4e2 FOLLOWUP_IP: vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+15 530249f5 8a0a mov cl,byte ptr [edx] NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 APP: soffice.bin ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) x86fre BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ_BEFORE_WRITE PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ_BEFORE_WRITE DEFAULT_BUCKET_ID: INVALID_POINTER_READ_BEFORE_WRITE LAST_CONTROL_TRANSFER: from 52e2f1fc to 530249f5 STACK_TEXT: 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_STACK_INDEX: 0 SYMBOL_NAME: vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+15 FOLLOWUP_NAME: MachineOwner MODULE_NAME: vcllo IMAGE_NAME: vcllo.dll DEBUG_FLR_IMAGE_TIMESTAMP: 54dfe0c6 FAILURE_BUCKET_ID: INVALID_POINTER_READ_BEFORE_WRITE_c0000005_vcllo.dll!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_BEFORE_WRITE_vcllo!BitmapReadAccess::GetPixelFor_24BIT_TC_BGR+15 ANALYSIS_SOURCE: UM 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 ---------
Created attachment 113424 [details] BackTrace libo-master~2015-02-14
It also crashes with libo-master~2015-02-16 (see BT)
Created attachment 113428 [details] BackTrace libo-master~2015-02-16
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).
It also crashes with libo-master 2015-12-18
Created attachment 113540 [details] backtrace_libo-master~2015-02-18.txt
It also crashes with LibO Parallel libo-master~2015-02-23 (see bt attached)
Created attachment 113639 [details] BackTrace libo-master~2015-02-23
It also crashes with LibreOffice 4.4.1.2 (see BT attached)
Created attachment 113640 [details] BackTrace LibreOffice 4.4.1.2
It doesn't crashe with LibO libo-master~2015-02-26 !
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?
It crashes with libreoffice-4-4~2015-03-08
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.
Lets try that as https://gerrit.libreoffice.org/#/c/14809/
Ashod Nakashian committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e40f78753e10be6ca867aac593b6f0be166f3b73&h=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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It doesn't crash with libo-44~2015-03-10
yay Ashod fixed this one! probably affect only 32-bit builds, due to use of "long" type.
Ashod Nakashian committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0be27b45fabe07222256c7fe759b90b391ee56d9&h=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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
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.
It crashes with libo-43~2015-03-13_14.52.09
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.
It also doesn’t crash with 4.3.7.0 (libo-43~2015-03-19). Thanks
*** Bug 83199 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (notBibisectable) [NinjaEdit]