Download it now!
Bug 90502 - CRASH - failed assertion in unittest sw_globalfilter in master build OSX (ImplLogicToPixel)
Summary: CRASH - failed assertion in unittest sw_globalfilter in master build OSX (Imp...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
(earliest affected) Master
Hardware: x86-64 (AMD64) Mac OS X (All)
: high major
Assignee: Not Assigned
Keywords: haveBacktrace, notBibisectable, regression
Depends on:
Reported: 2015-04-07 17:41 UTC by Alex Thurgood
Modified: 2015-12-17 10:59 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

full bt, a few frames analysed (30.35 KB, text/plain)
2015-04-07 17:44 UTC, Alex Thurgood

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2015-04-07 17:41:51 UTC

Comment 1 Alex Thurgood 2015-04-07 17:44:14 UTC
In master debug builds on OSX 10.10.2, seeing the unittest sw_globalfilter crash for a failed assertion :

Assertion failed: (nMapNum == 0 || std::abs(n) < std::numeric_limits<long>::max() / nMapNum / nDPI), function ImplLogicToPixel, file /Volumes/BUILDHD/Shared/LO/core/vcl/source/outdev/map.cxx, line 379.

Enclosing a bt - tried investigating a few frames, but not understanding what the code is trying to do, didn't get me very far.
Comment 2 Alex Thurgood 2015-04-07 17:44:56 UTC
Created attachment 114675 [details]
full bt, a few frames analysed
Comment 3 Julien Nabet 2015-04-07 19:44:09 UTC
Stephan: noticing, thought you might be interested in this one.

(putting at NEW since there's a bt + increase importance since crash+regression)
Comment 4 Stephan Bergmann 2015-04-08 06:56:00 UTC
So at the end of lcl_CalcBorderRect (sw/source/core/layout/paintfrm.cxx; frame 7) rRect must contain the values that are reported for rLogicRect in frame 5:

  nLeft =   9223372036854755805
  nTop =    9223372036854755807
  nRight =  9223372036854755808
  nBottom = 9223372036854755808


  nLeft =   0x7FFF'FFFF'FFFF'B1DD
  nTop =    0x7FFF'FFFF'FFFF'B1DF
  nRight =  0x7FFF'FFFF'FFFF'B1E0
  nBottom = 0x7FFF'FFFF'FFFF'B1E0

which smells like mis-calculations using the FAR_AWAY (sw/source/core/inc/frmtool.hxx) value LONG_MAX - 20000 = 9223372036854755807 = 0x7FFF'FFFF'FFFF'B1DF.
Comment 5 Miklos Vajna 2015-04-08 07:10:05 UTC
Is this specific to OS X or something that can be reproduced on Linux, too?

Without being able to reproduce, the big picture is: for e.g. page frames, there is an "is invalid" flag that's true by default and set to false by the layout when its size and position is correct. I guess there is a similar flag for fly frames as well: before that FAR_AWAY should not be taken literally. Possibly that's what happens here, seeing the values which are close to, but do not equal to FAR_AWAY.
Comment 6 Alex Thurgood 2015-04-08 08:13:30 UTC
Seems specific to OSX - also confirmed by mjayfrancis on his OSX setup
Comment 7 Alex Thurgood 2015-04-08 08:18:23 UTC
Assertion failed: (nMapNum == 0 || std::abs(n) < std::numeric_limits<long>::max() / nMapNum / nDPI), function ImplLogicToPixel, file /Volumes/BUILDHD/Shared/LO/core/vcl/source/outdev/map.cxx, line 379.

So, if I understand correctly, the line of code above is using LONG MAX ?
Comment 8 Julien Nabet 2015-04-12 07:07:30 UTC
Just for the record, I could also reproduce this on MacOs build (with debug option) and not on Linux.
Comment 9 Julien Nabet 2015-04-19 09:45:28 UTC
Caolan/Chris: thought you might be interested in this one since bt shows vcl part.
Comment 10 Alex Thurgood 2015-04-20 06:46:38 UTC
It makes no difference whether I build with debug enabled or disabled, the build fails systematically with this unit test. This has completely broken building on master for me. I completely clean the build tree each time before pulling, forcing removal with 'sudo rm -Rf' of any instdir, workdir, and test-install folders.

Changed title to reflect findings.
Comment 11 David Tardon 2015-04-20 06:54:07 UTC
No crash here. Maybe a High-DPI issue?
Comment 12 Alex Thurgood 2015-04-21 10:26:37 UTC
(In reply to David Tardon from comment #11)
> No crash here. Maybe a High-DPI issue?

My monitor is a LG Flatron W1946
18,4-inch (1360 x 768)
GPU : NVIDIA GeForce 320M 256 Mo

so it isn't hi-DPI capable and shouldn't be using code paths geared to such hiDPI support ?
Comment 13 Alex Thurgood 2015-04-22 14:30:55 UTC
Now seeing this :

(lldb) run
Process 80430 launched: '/Volumes/BUILDHD/Shared/LO/core/workdir/LinkTarget/Executable/cppunittester' (x86_64)
assertion failed
- Expression:
- loading failed: file:///Volumes/BUILDHD/Shared/LO/core//sw/qa/extras/globalfilter/data/skipimages.docx

tearDown() failed
- An uncaught exception of type

/Volumes/BUILDHD/Shared/LO/core/unotest/source/cpp/macros_test.cxx:52: Assertion
Test name: Test::testSkipImages
assertion failed
- Expression:
- loading failed: file:///Volumes/BUILDHD/Shared/LO/core//sw/qa/extras/globalfilter/data/skipimages.docx

##Failure Location unknown## : Error
Test name: Test::testSkipImages
tearDown() failed
- An uncaught exception of type

Failures !!!
Run: 8   Failure total: 2   Failures: 1   Errors: 1
2015-04-22 16:25:08.529 cppunittester[80430:1566208] *** -[NSAutoreleasePool release]: This pool has already been released, do not drain it (double release).
Process 80430 exited with status = 1 (0x00000001) 

There is no stack to trace in this via lldb, but the line of code indicated as failing is :

Comment 14 Julien Nabet 2015-05-02 12:36:50 UTC
I've got the same bt on Mac too with master sources updated today (+ enable-dbgutil + "make clean" before building):
    frame #4: 0x000000010683ffde libvcllo.dylib`ImplLogicToPixel(n=9223372036854755805, nDPI=103, nMapNum=1, nMapDenom=1440, nThres=44773650664343568) + 302 at map.cxx:381
    frame #5: 0x0000000106843da8 libvcllo.dylib`OutputDevice::LogicToPixel(this=0x000000013009e860, rLogicRect=0x00007fff5fbecfb8) const + 184 at map.cxx:997
    frame #6: 0x000000010d4a3267 libswlo.dylib`SwAlignRect(rRect=0x00007fff5fbed538, pSh=0x000000013328cb40) + 231 at paintfrm.cxx:1254
    frame #7: 0x000000010d4be5cd libswlo.dylib`lcl_CalcBorderRect(rRect=0x00007fff5fbed538, pFrm=0x0000000133218170, rAttrs=0x000000011a913f18, bShadow=false, properties=0x000000010e7b1620) + 3005 at paintfrm.cxx:1512
    frame #8: 0x000000010d4b9b78 libswlo.dylib`SwFrm::GetBackgroundBrush(this=0x0000000133218170, rFillAttributes=0x00007fff5fbed528, rpBrush=0x00007fff5fbed560, rpCol=0x00007fff5fbed558, rOrigRect=0x00007fff5fbed538, bLowerMode=false) const + 1736 at paintfrm.cxx:7595
    frame #9: 0x000000010d4b919e libswlo.dylib`SwFlyFrm::IsBackgroundTransparent(this=0x0000000133218170) const + 238 at paintfrm.cxx:3972
    frame #10: 0x000000010d4ccae5 libswlo.dylib`lcl_RefreshLine(pLay=0x0000000133289be0, pPage=0x000000011a912000, rP1=0x00007fff5fbeda98, rP2=0x00007fff5fbeda68, nSubColor='\x10', pSubsLines=0x0000000130b3e160) + 1221 at paintfrm.cxx:6857
    frame #11: 0x000000010d4cc08f libswlo.dylib`SwLayoutFrm::PaintSubsidiaryLines(this=0x0000000133289be0, pPage=0x000000011a912000, rRect=0x00007fff5fbee0f0) const + 1391 at paintfrm.cxx:7174
    frame #12: 0x000000010d4bd36d libswlo.dylib`SwLayoutFrm::RefreshLaySubsidiary(this=0x0000000133289be0, pPage=0x000000011a912000, rRect=0x00007fff5fbee0f0) const + 205 at paintfrm.cxx:6749
    frame #13: 0x000000010d4bb58a libswlo.dylib`SwFlyFrm::Paint(this=0x0000000133289be0, rRect=0x0000000133289c40, (null)=0x0000000000000000) const + 5018 at paintfrm.cxx:4332

iMac (21.5 inches, mid-2011)
Processor: 2,5 GHz Intel Core i5
AMD Radeon HD 6750M 512 Mo
Comment 15 Julien Nabet 2015-05-25 10:21:14 UTC
I tried to follow FAR_AWAY/flag lead (proposed by Miklos and Stephan) but I must recognize I got lost :-(

Michael: noticing your commit fixed the same assertion, thought you might have some idea for this one.

All: If you don't have a Mac, don't hesitate to attach a test patch, I can give it a try and report if the assertion is still there or not.
Comment 16 Julien Nabet 2015-07-13 10:51:44 UTC
I just changed the title to retrieve it more quickly.
Comment 17 Caolán McNamara 2015-07-13 11:27:27 UTC
Is this still a problem or is it fixed, I ask because the bt in bug 92573 is similar to this one
Comment 18 Julien Nabet 2015-07-13 12:49:29 UTC
(In reply to Caolán McNamara from comment #17)
> Is this still a problem or is it fixed, I ask because the bt in bug 92573 is
> similar to this one

I've just git updated and it's building right now.
However, I can say that with sources updated the 8th of July, it was still crashing with same messages.
Comment 19 Julien Nabet 2015-07-14 08:50:25 UTC
Badfully, it still fails with same message.
Comment 20 Julien Nabet 2015-10-15 17:07:04 UTC
I don't reproduce this with master sources updated today.
I'm quite sure it's thanks to

Alex, could you give it a new try?
Comment 21 Alex Thurgood 2015-12-03 13:37:24 UTC
Yep, no longer seems to fail anymore? Closing
Comment 22 Robinson Tryon (qubit) 2015-12-17 10:59:10 UTC Comment hidden (obsolete)