Filing bug-report with a attachment that is larger than 1MB?

Hi,

How do I file a bug-report with a attachment that is larger than 1MB?

Clang-cl ICEs on some code and following the instructions, compressing the indicated files with 7zip generates an archive of 1.5MB. My code is small, the rest is a lib. The bug-report gets created [41745], but the attachment fails. Please indicate how to proceed.

Regards,

degski

If you can, try to reduce the overall test case (CReduce can help here
https://embed.cs.utah.edu/creduce/ ) - running it through a
preprocessor and stripping everything not needed to reproduce the bug.
this'll make it easier for humans as well as for dealing with the bug
database.

The file is the file produced by clang’s pre-processor automatically when an ICE occurs, it’s is full of comments added to it by clang, that are destined for the human to understand why different bits of code are there and where they came from. My code is 14 lines long and that includes the return statement in main(), which I can strip :slight_smile: .

Fact is clang produces 440’000+ lines of code, which after compression with LZMA at the highest compression level reduces to 1.5MB, which is over the pathetic maximum of 1000KB, sorry for that, welcome in the 21st century.

From the creduce repo: " Before compiling C-Reduce yourself, you might want to see if your OS comes with a precompiled package for C-Reduce. Ubuntu, Debian, Gentoo, and Mac OS X (Homebrew) all do. For example, on OS X: "

I checked, my package manager [vcpkg] doesn’t carry creduce.

I can email you the archive, then you can do the gymnastics with creduce [ffs] and add it to bug report 41745.

Please indicate how to proceed.

degski

Just to be absolutely clear, I’m just following instructions:

1>Stack dump:
1>0. Program arguments: C:\Program Files\LLVM\bin\clang-cl.exe -cc1 -triple x86_64-pc-windows-msvc19.16.27030 -emit-obj -mincremental-linker-compatible -disable-free -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -relaxed-aliasing -menable-no-infs -menable-no-nans -menable-unsafe-fp-math -fno-signed-zeros -mreassociate -freciprocal-math -fno-trapping-math -ffp-contract=fast -ffast-math -ffinite-math-only -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu haswell -mllvm -x86-asm-syntax=intel -D_MT -flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames -stack-protector 2 -fcxx-exceptions -fexceptions -fexternc-nounwind -fms-volatile -fdefault-calling-conv=cdecl -fdiagnostics-format msvc -dwarf-column-info -momit-leaf-frame-pointer -ffunction-sections -coverage-notes-file Y:\REPOS\gmp_random\gmp_random\main.gcno -resource-dir C:\Program Files\LLVM\lib\clang\9.0.0 -I y:\vcpkg\installed\x64-windows-static\include -D WIN64 -D NDEBUG -D _CONSOLE -D NOMINMAX -D MPPP_BUILD_STATIC_LIBRARY -D MPPP_STATIC -D MPPP_PUBLIC= -D _UNICODE -D UNICODE -internal-isystem C:\Program Files\LLVM\lib\clang\9.0.0\include -internal-isystem y:\vc\x64\include -internal-isystem y:\vc\x64 -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\atlmfc\include -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\VS\include -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\winrt -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\cppwinrt -internal-isystem Include\um -O2 -Wall -Wno-error -fdeprecated-macro -fdebug-compilation-dir Y:\REPOS\gmp_random\gmp_random -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.16.27030 -std=c++17 -fdelayed-template-parsing -fobjc-runtime=gcc -fno-caret-diagnostics -fdiagnostics-show-option -fno-show-column -vectorize-loops -vectorize-slp -o Y:\REPOS\gmp_random\x64\Release\main.obj -x c++ main.cpp -faddrsig
1>1. y:\vcpkg\installed\x64-windows-static\include\mp++/integer.hpp:2841:59: current parser token ‘;’
1>2. y:\vcpkg\installed\x64-windows-static\include\mp++/integer.hpp:2839:5: parsing function body ‘mppp::integer::binary_load’
1>3. y:\vcpkg\installed\x64-windows-static\include\mp++/integer.hpp:2839:5: in compound statement (’{}’)
1>0x00007FF6E2F82E66 (0x0000000000000016 0x00007FF6E2F82E60 0x0000001000000000 0x00007FFCEEC8A510)
1>0x00007FFCEEC0DA2D (0x0000000000000901 0x00007FF600000000 0x000000000000092B 0x00007FF6E656C93E), raise() + 0x1DD bytes(s)
1>0x00007FFCEEC0E901 (0x00007FFC00000003 0x00007FFC00000003 0x00007FF6E656C93E 0x00007FF6E656C430), abort() + 0x31 bytes(s)
1>0x00007FFCEEC10261 (0x000000000000092B 0x00007FF6E656C93E 0x0000001027D87A70 0x0000000000000010), _get_wpgmptr() + 0x18A1 bytes(s)
1>0x00007FFCEEC10591 (0x0000016D778403F8 0x0000000000000000 0x0000016D7783F940 0x0000016D7783F940), _wassert() + 0x71 bytes(s)
1>0x00007FF6E4D90595 (0x0000016D00000000 0x00007FF6E4D83A7C 0x0000016D77826C70 0x0000000000000000)
1>0x00007FF6E45BCE19 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
1>0x00007FF6E46C7098 (0x0000000000000000 0x00000000E4900023 0x0000016D77825830 0x00007FF6E4E101DD)
1>0x00007FF6E46C61BD (0x0000000000000013 0x0000016D70F20090 0x0000016D7099E8B0 0x0000001027D8BC08)
1>0x00007FF6E447111B (0x0000016D001347A5 0x0000000000000000 0x0000016D77822DE0 0x0000016D7736C990)
1>0x00007FF6E446E65C (0x0000000000000000 0x00007FF6E532DE1C 0x00007FFCEEC10520 0x0000001027D8C7C0)
1>0x00007FF6E4468EFB (0xFFFFFFFFFFFFFFF8 0x0000001027D8C854 0x00000000004ECFF7 0x0000016D7096A260)
1>0x00007FF6E446898D (0x00000000000038E3 0x00007FF6E316D2DB 0x0000016D7096A260 0x0000000000000010)
1>0x00007FF6E44A6E8B (0x0000016D77826888 0x0100000000134790 0x0000FAC1BC6F388B 0x0000016D7096A200)
1>0x00007FF6E44A689F (0x0000001000000003 0x0000016D712AE730 0x0000016D75914668 0x0000016D709949B0)
1>0x00007FF6E44B0107 (0x0000000000000026 0x0000016D759146B0 0x00007FF6E50D6494 0x0000000000000000)
1>0x00007FF6E44B0D84 (0x0000000000000002 0x00007FFCF259267D 0x0000016D709EDA90 0x00007FFCF259267D)
1>0x00007FF6E443FB39 (0x0000000100000000 0x0000FAC100000000 0x0000000000000000 0x0000000000000000)
1>0x00007FF6E4BBB07B (0x0000000000000001 0x00007FF6E460EE8C 0x0000000000000000 0x0000016D70F20400)
1>0x00007FF6E4BBEB9D (0x0000000000000000 0x0000001027D8D4C8 0x0000000400000000 0x0000000000000001)
1>0x00007FF6E45213D5 (0x0000016D70936400 0x00007FF6E531DDEC 0x0000016D70F20090 0x0000000000000000)
1>0x00007FF6E441DF32 (0x0000000000000000 0x00007FF6E36D67FF 0x00007FF6E5F93DC6 0x0000000000000004)
1>0x00007FF6E441A0F9 (0x0000000000000000 0x0000000000000000 0x0000FAC1BC6F249B 0x0000016D709202F0)
1>0x00007FF6E371D330 (0x0000016D7093D380 0x00007FF6E532A023 0x00000000000000C0 0x0000016D7099FAE0)
1>0x00007FF6E36D9DAF (0x00007FF6E532E901 0x0000000000000000 0x0000000000000000 0x000000000000007B)
1>0x00007FF6E377E4B5 (0x0000000000000000 0x0000016D709749A0 0x0000000000001801 0x0000000000000000)
1>0x00007FF6E1357284 (0x00000000000006A6 0x0000000000000000 0x0000000019000019 0x00000000000006B0)
1>0x00007FF6E1354715 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
1>0x00007FF6E532A248 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
1>0x00007FFCF2437974 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x14 bytes(s)
1>0x00007FFCF25EA271 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s)
1>clang-cl : error : clang frontend command failed due to signal (use -v to see invocation)
1>clang version 9.0.0 (trunk)
1>Target: x86_64-pc-windows-msvc
1>Thread model: posix
1>InstalledDir: C:\Program Files\LLVM\bin
1>clang-cl: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
1>clang-cl: note: diagnostic msg:
1>********************
1>
1>PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
1>Preprocessed source(s) and associated run script(s) are located at:
1>clang-cl: note: diagnostic msg: C:\Users\xxx\AppData\Local\Temp\main-469827.cpp
1>clang-cl: note: diagnostic msg: C:\Users\xxx\AppData\Local\Temp\main-469827.sh
1>clang-cl: note: diagnostic msg:
1>
1>********************
1>Done building project “gmp_random.vcxproj” – FAILED.

So we see: " PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script."

I’m doing my best.

And “PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: … C:\Users\xxx\AppData\Local\Temp\main-469827.cpp”.

That is a 15MB file, which I reduced to 1.5MB, again I’m doing my best.

It’s an ICE, it’s not a ‘maybe a bug’, no it’s a ‘guaranteed bug’. If nobody is interested, I’ll just move on and get out of your way.

n case some-one didn’t notice, yes, I’m p’ed off.

degski

I understand you are irritated by the 1MB maximum. It’s possible we could get the admins to increase that, but it rarely is a problem in practice.

Instead of creduce, I would first look at reducing the header-file overhead. Can you reduce the number of headers in your source? Windows is particularly prone to pulling in boatloads of headers that you don’t actually need. If you do need all the headers in your original source, but you are including say <windows.h> along with everything else, there are some preprocessor symbols you can set to reduce that overhead and so (we hope) get the preprocessed source down to where you can file the bug.

For example, you could try defining WIN32_LEAN_AND_MEAN and see if that helps. There are probably other symbols you can set to reduce the header overhead, but that’s the one that I remember getting the most benefit.

HTH,

–paulr

vcpkg is a C++ library package manager, not your distro's package manager. If you're on Windows, then maybe you can download it somewhere?

But you said that your code is small, and if the only code you #include is from the standard library, then it's okay IMO to just include that and not the full prepocessed source. Maybe also include your compiler flags.

Hope that helped

I understand you are irritated by the 1MB maximum. It’s possible we could get the admins to increase that, but it rarely is a problem in practice.

Well, that would be the best solution, isn’t it? I mean, 1MB, my desktop background-jpg is more than 1MB. I always use trunk (from the snapshot builds) and encounter ICE’s regularly. Most of them are triggered by me f’in up C++ syntax, so I let those pass [as in not report] (clang f’ed up, but so did I). But this one is clearly in the compiler-bug realm. The code compiles with VC and I don’t see any reason why it [clang] shouldn’t [compile it correctly].

Instead of creduce, I would first look at reducing the header-file overhead.

I do dual-boot my lap-top with Fedora-30 [I’m rather nix-green, though], I had a look, and they [dnf] don’t carry creduce either.

I had already reduced them to a max, but it pulls in this lib https://github.com/bluescarni/mppp , as you could see [in the issues], I raised it as an issue as well, there. The work-around is simple, but that does not take away from the fact clang-cl has one bug :slight_smile: .

Can you reduce the number of headers in your source? Windows is particularly prone to pulling in boatloads of headers that you don’t actually need. If you do need all the headers in your original source, but you are including say <windows.h> along with everything else, there are some preprocessor symbols you can set to reduce that overhead and so (we hope) get the preprocessed source down to where you can file the bug.

If the clang project wants people to report bugs, it should not be necessary to jump through hoops. Most of the ‘volume’ of this file consists of annotations [comments] by clang itself, they are all kind of comments in fact, they seem useful, trying to get rid of them seems counter-productive.

But, since I still would like to ‘contribute’ my bug and since getting a bigger disk [to allow for bigger attachements] is not possible, I could host the files as gists on my github-account, or I could put them on paste-bin. Could that be a solution?

degski

I could host the files as gists on my github-account, or I could put them on paste-bin. Could that be a solution?

Yes, I’m pretty sure I’ve seen other bugs with links to paste-bin or similar.

–paulr

Nicolas Lesser wrote:

vcpkg is a C++ library package manager, not your distro’s package manager. If you’re on Windows, then maybe you can download >> it somewhere?

It’s not in the Fedora repo either, so we could qualify it as obscure at best.

But you said that your code is small, and if the only code you #include is from the standard library, then it’s okay IMO to just include that and not the full prepocessed source. Maybe also include your compiler flags.

My code [~15 lines] pulls in a lib https://github.com/bluescarni/mppp (which pulls in gmp) and some STL, and that’s [in mppp] where it happens.

I’ve now hosted the files on github https://gist.github.com/degski/3949d4bc2b723c659fae29cb4eabc47e and 2 others.

degski

Thanks - reduced the test case and filed https://bugs.llvm.org/show_bug.cgi?id=41800

Though it looks like it /might/ be a bug in Visual Studio’s standard library implementation - might be worth trying a newer Visual Studio, if you have the chance (as it may be fixed, or at least changed in a way that’s clang-compatible).