Created attachment 154802 [details]
bt Windows (windbg)

Created attachment 154805 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I got an assertion too.

Confirmed in Ubuntu 19.04. The following is the assertion, perhaps a missing file? I wonder if it's related to bug 126293's fix.

soffice.bin: /home/valaki/projects/libreoffice/vcl/source/gdi/bmpacc.cxx:38: BitmapInfoAccess::BitmapInfoAccess(Bitmap&, BitmapAccessMode): Assertion `xImpBmp && "Forbidden Access to empty bitmap!"' failed.

Caolán/Noel: thought you might be interested in this one (a bt is included) since it concerns vcl.

For my Linux build using Elementary icon theme, the issue appears to be a missing extensions/res/buttonminus.png.  The links.txt in instdir/share/config/images_elementary.zip contains

  extensions/res/buttonminus.png extensions/res/scanner/minus.png

but instdir/share/config/images_elementary.zip contains no extensions/res/scanner/minus.png, even though there is a source file icon-themes/elementary/extensions/res/scanner/minus.png.  Must be some issue with how postprocess/CustomTarget_images.mk generates those images_*.zip?

Is it an incremental build dependency bug ?, we had that before e.g. bug 124023.

FWIW I'm not getting the assert locally

(In reply to Stephan Bergmann from comment #5)
> For my Linux build using Elementary icon theme, the issue appears to be a
> missing extensions/res/buttonminus.png.  The links.txt in
> instdir/share/config/images_elementary.zip contains
> 
>   extensions/res/buttonminus.png extensions/res/scanner/minus.png
> ...

Just for curiosity, how did you find there was a missing file? Indeed, I don't see the file name concerned in the bt (or perhaps missed it)

(In reply to Caolán McNamara from comment #6)
> Is it an incremental build dependency bug ?, we had that before e.g. bug
> 124023.
> 
> FWIW I'm not getting the assert locally

I did a make clean on Win10 this morning (I'm UTC+2) and I could reproduce the assertion.

(In reply to Caolán McNamara from comment #6)
> Is it an incremental build dependency bug ?, we had that before e.g. bug
> 124023.

I can still reproduce hitting the "vcl/source/gdi/bmpacc.cxx:38: BitmapInfoAccess::BitmapInfoAccess(Bitmap &, BitmapAccessMode): Assertion `xImpBmp && "Forbidden Access to empty bitmap!"' failed" assert after a full rebuild (on Linux).  (And instdir/share/config/images_elementary.zip still contains no extensions/res/scanner/minus.png.)

(In reply to Julien Nabet from comment #7)
> Just for curiosity, how did you find there was a missing file? Indeed, I
> don't see the file name concerned in the bt (or perhaps missed it)

Once the assert is hit in gdb:

> (gdb) f 16
> #16 0x00007fffc422bd43 in Button::ImplDrawAlignedImage (this=0x6170001bba80, pDev=0x6170001bba80, rPos=Point = {...}, rSize=Size = {...}, nImageSep=7, nTextStyle=5411, pSymbolRect=0x0, bAddImageSep=true) at core/vcl/source/control/button.cxx:439
> 439	        pDev->DrawImage(aImagePos, *pImage, nStyle);
> (gdb) p *pImage->mpImplData.get()
> $1 = {
>   maBitmapChecksum = 0, 
>   maSizePixel = Size = {
>     width = 0,
>     height = 0
>   }, 
>   maPreferedSizePixel = Size = {
>     width = 0,
>     height = 0
>   }, 
>   maStockName = "extensions/res/buttonminus.png", 
[...]

$ rm -rf workdir/CustomTarget/postprocess/
$ ls -l icon-themes/elementary/extensions/res/scanner/minus.png
-rw-r--r--. 1 caolan caolan 188 Oct 29 14:59 icon-themes/elementary/extensions/res/scanner/minus.png
$ make postprocess.build
$ unzip -l workdir/CustomTarget/postprocess/images/images_elementary.zip|grep minus
      188  10-29-2019 15:16   extensions/res/scanner/minus.png
      488  10-29-2019 15:16   res/minus.png

no idea why it seems extensions/res/scanner/minus.png goes missing for you, someone who is afflicted by this would have to debug solenv/bin/pack_images.py to see why that file does not get included

Indeed, retrying with my local Linux master build from today, `unzip -l instdir/share/config/images_elementary.zip | grep extensions/res/scanner/minus.png` shows that the file is there, and the reproducer from comment 0 no longer causes a crash for me.

On pc Debian x86-64 with master sources updated today (and full rebuild some days ago), I don't reproduce this. Let's put this one to WFM then.