Re: Clang 5.0 32-bit builds Failing on CppunitTest_vcl_pdfexport

On 04/12/2017 10:46 PM, Michael Stahl wrote:
> On 12.04.2017 21:43, Michael Stahl wrote:
> > On 12.04.2017 19:35, slacka wrote:
> > > Here is the backtrace:
> > >
> > > https://pastebin.com/vhYRQDSG
> > >
> > > This was with  clang version 4.0.0 (trunk 287326)
> > >
> > > On Ubuntu 16.04.2 LTS 3 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:49:39
> > > UTC 2017 i686 i686 i686
> > >
> > > I'm not sure if it was timing, ccache. or what but whatever is causing this
> > > crash started about 1 month ago. I have been building Libreoffice with Clang
> > > for years and I'm seeing this on 2 different machines(Ubuntu/Fedora).
> >
> > oh, that is interesting!
> >
> > > #11 0x403058ad in std::terminate() () from /usr/lib/i386-linux-gnu/libstdc++.so.6
> > > No symbol table info available.
> > > #12 0x40305b70 in __cxa_throw () from /usr/lib/i386-linux-gnu/libstdc++.so.6
> > > No symbol table info available.
> > > #13 0x458d4ea4 in errorExit (cinfo=0xbfa9beb0) at /core/vcl/source/filter/jpeg/jpegc.cxx:45
> > >          buffer = "Quantization table 0x00 was not 
> > > defined\000\016\225\261E\260\276\251\277S\v\000\000\230\273\251\277\273\221\261E\b\000\000\000\b\000\000\000\000\260\367E\b\000\000\000\b\000\000\000\000\260\367E\300\245\362\t\260\245\362\t\370\320\362\t@\v\000\000\001\000\000\000\260\276\251\277\001\000\000\000\000\260\367E軩\277\060\227\261E\260\276\251\277\001\000\000\000@\v\000\000\n\000\000\000
> > >  
> > > \001\000\000\020\000\000\000`\000\000\000\000\260\367E^\373\064\000\000\000\000\000\n\000\000\000\n\000\000\000\000\261\362\t0\205\362\t\370\320\362\t\n\000\000\000
> > >  \001\000\000\001\000\000\000\260\276\251\277"
> > > #14 0x45b052e2 in latch_quant_tables (cinfo=0xbfa9beb0) at jdinput.c:259
> > >          ci = 0
> > >          qtblno = 0
> > >          compptr = 0x9f26620
> > >          qtbl = 0x1
> > > #15 0x45b04ab7 in start_input_pass (cinfo=0xbfa9beb0) at jdinput.c:281
> > > No locals.
> > > #16 0x45b0aa98 in master_selection (cinfo=0xbfa9beb0) at jdmaster.c:575
> > >          master = 0x9e64870
> > >          use_c_buffer = 0
> > >          samplesperrow = 2220
> > >          jd_samplesperrow = 2220
> > > #17 0x45b0a3ce in jinit_master_decompress (cinfo=0xbfa9beb0) at jdmaster.c:735
> > >          master = 0x9e64870
> > > #18 0x45b033ca in jpeg_start_decompress (cinfo=0xbfa9beb0) at jdapistd.c:47
> > > No locals.
> > > #19 0x458d5738 in ReadJPEG (pJPEGReader=0x9e5e03c, pInputStream=0xbfa9ca30, pLines=0xbfa9c124, 
> > > previewSize=...) at /core/vcl/source/filter/jpeg/jpegc.cxx:206
> >
> > an unhandled exception during JPEG import
>
> this is probably happening since:
>
> commit 6889fa826eef6bd1074d77507818e71dfe8ba152
> Author:     Caolán McNamara <caolanm@redhat.com>
> AuthorDate: Sat Mar 18 20:19:51 2017 +0000
>
>      rework jpeg error handling to throw rather than setjmp to avoid leaks
>
>
> the function errorExit() is declared extern "C" and throws an exception,
> so std::terminate() is invoked and the catch
> (css::uno::RuntimeException) in ReadJPEG() is not reached.
>
> now why does that happen only in your build?  my clang builds don't seem
> to mind throwing from extern "C"?  tinderboxes seem happy too.

Maybe it depends on how the jpeg library was built.  So interesting 
questions would be:

* Which jpeg library is that, system one or external/jpeg-turbo?

* What's the autogen.input anyway?

* Does this "terminate called after throwing an instance of 
'com::sun::star::uno::RuntimeException'" SIGABRT failure of 
CppunitTest_vcl_filters_test only happen on one of those "2 different 
machines(Ubuntu/Fedora)" or on both?