Clang 5.0 32-bit builds Failing on CppunitTest_vcl_pdfexport

[Stephan Bergmann]

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 at 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?