-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test suite failures #2288
Comments
Asking someone who speaks C++ far better than I do, this is just an out of bounds array reference. Fedora builds with |
hmm, we never run the test suite with the debugging enabled. I suppose the
assert is harmless. I cannot help right now, it will take some time to
resolve.
By the way, you should build the application by giving the Release target
to CMake when building for the distro. I suppose this will mute the asserts.
cmake -DCMAKE_BUILD_TYPE=Release
…On Mon, May 20, 2019 at 8:27 PM Jason Tibbitts ***@***.***> wrote:
Version
2.0.0 rc2
Operating system type + version
Fedora 29
Behavior
I am trying to get the test suite to run as part of Fedora's package build
process (and have largely succeeded) but several of the tests in the
"integration" test suite fail. These are the tests in the top-level 't'
directory of the tarball.
Basically, combineinfill.t, custom_gcode.t, fill.t, multi.t and
retraction.t all abort with this message:
/usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = double; _Alloc = std::allocator<double>; std::vector<_Tp, _Alloc>::const_reference = const double&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped
Some of their subtests may run but obviously nothing runs past the abort.
I'm afraid that I haven't yet been able to untangle all of the C++ here, so
I've no idea what's really gone wrong here, but I've extracted the
following backtrace. (I removed 19 other threads that weren't doing
anything.)
Thread 1 (Thread 0x7fa7bd442740 (LWP 22972)):
#0 0x00007fa7bd47d57f in raise () from /lib64/libc.so.6
#1 0x00007fa7bd467895 in abort () from /lib64/libc.so.6
#2 0x00007fa7b008fe08 in std::__replacement_assert ***@***.***=0x7fa7b034d468 "/usr/include/c++/8/bits/stl_vector.h",
***@***.***=950,
***@***.***=0x7fa7b03a32c0 <_ZZNKSt6vectorIdSaIdEEixEmE19__PRETTY_FUNCTION__> "std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = double; _Alloc = std::allocator<double>; std::vector<_Tp, _Alloc>:"..., ***@***.***=0x7fa7b034d438 "__builtin_expect(__n < this->size(), true)")
at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2391
#3 0x00007fa7b02ab9d9 in std::vector<double, std::allocator<double> >::operator[] (__n=<optimized out>, this=<optimized out>)
at /usr/include/c++/8/bits/stl_vector.h:948
#4 Slic3r::ToolOrdering::fill_wipe_tower_partitions (this=0x7ffdf6787850, config=..., object_bottom_z=<optimized out>)
at /builddir/build/BUILD/PrusaSlicer-version_2.0.0-rc2/src/libslic3r/GCode/ToolOrdering.cpp:302
#5 0x00007fa7b02ad36c in Slic3r::ToolOrdering::ToolOrdering (this=0x7ffdf6787850, print=..., first_extruder=4294967295,
prime_multi_material=<optimized out>) at /builddir/build/BUILD/PrusaSlicer-version_2.0.0-rc2/src/libslic3r/Print.hpp:331
#6 0x00007fa7b01451a7 in Slic3r::GCode::_do_export (this=0x7ffdf6787ce0, print=..., file=0x56396bc13e60)
at /usr/include/c++/8/bits/stl_vector.h:300
#7 0x00007fa7b0148556 in Slic3r::GCode::do_export ***@***.***=0x7ffdf6787ce0, ***@***.***=0x56396c66c2b0,
path=0x56396c69d3a0 "/builddir/build/BUILD/PrusaSlicer-version_2.0.0-rc2/t/combineinfill.t.gcode.temp",
***@***.***=0x0) at /builddir/build/BUILD/PrusaSlicer-version_2.0.0-rc2/src/libslic3r/GCode.cpp:448
#8 0x00007fa7b01e301f in Slic3r::Print::export_gcode ***@***.***=0x56396c66c2b0,
path_template="/builddir/build/BUILD/PrusaSlicer-version_2.0.0-rc2/t/combineinfill.t.gcode.temp", ***@***.***=0x0)
at /usr/include/c++/8/bits/basic_string.h:2290
#9 0x00007fa7b00081a1 in XS_Slic3r__Print_export_gcode (my_perl=<optimized out>, cv=<optimized out>)
at /usr/include/c++/8/bits/basic_string.h:252
#10 0x00007fa7bd90c5d9 in Perl_pp_entersub () from /lib64/libperl.so.5.28
#11 0x00007fa7bd9027e5 in Perl_runops_standard () from /lib64/libperl.so.5.28
#12 0x00007fa7bd87f7bf in perl_run () from /lib64/libperl.so.5.28
#13 0x000056396a8e434a in ?? ()
#14 0x00007fa7bd469413 in __libc_start_main () from /lib64/libc.so.6
#15 0x000056396a8e438e in ?? ()
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2288?email_source=notifications&email_token=ABMPSI2OSVET6Q7F6CLFEWLPWLURHA5CNFSM4HOELSMKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUZIBXA>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABMPSI7KCCUP3SRTBBAJ7DTPWLURHANCNFSM4HOELSMA>
.
|
For the record, we are already building with
and this tends to catch all sorts of things. Better to catch out of bounds array references early. |
sure. Some of our developers run regularly with address sanitizer, so this
assert from the unit tests is likely not an issue. We should fix it for
sure.
…On Mon, May 20, 2019 at 8:37 PM Jason Tibbitts ***@***.***> wrote:
For the record, we are already building with -DCMAKE_BUILD_TYPE=Release.
It's just that Fedora uses:
+ CFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
and this tends to catch all sorts of things. Better to catch out of bounds
array references early.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2288?email_source=notifications&email_token=ABMPSI3L4IEIYQMV3GVZALLPWLVVBA5CNFSM4HOELSMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVZWS5A#issuecomment-494102900>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABMPSI7JTNYOZZ7LICOCHODPWLVVBANCNFSM4HOELSMA>
.
|
@jasontibbitts Would you please tell me:
|
I have to admit I am noob, but it sounds to me that the settings |
There was a bug in unit tests that led to generating the wipe tower with non-normalized preset. This caused out-of-bounds access into max_layer_height vector in fill_wipe_tower_partitions. The problem surfaced in #2288. I quickly patched additional normalization of the preset to prevent this from happening. Also, an assert in the same function turned out to trip on one of the tests. This one was commented out for now and will (hopefully) be looked into later. Function Print::apply_config was renamed to apply_config_perl_tests_only so everyone sees its current purpose and does not mistake it for the more important Print::apply.
As I mentioned in the commit message above, there really was a bug in our unit tests which made PrusaSlicer do the out-of-bounds access. This bug only appeared in the test (not in the application) and we never saw it actually crash. Forcing the range-check revealed the error so we could fix it - hopefully the commit above did and the tests should now pass even with the range checks enabled. That being said, I'm also surprised you're enabling the extra assert checks and would not expect that in C++ release build. But I'm by far not an expert. |
I am considering myself an expert in high performance C++ computing and I am very surprised that these checks are enabled in a release mode. My understanding is, that _GLIBCXX_ASSERTIONS enable run time checks, which will likely have a detrimental effect on the computation speed and power consumption. We shall consider our carbon footprint and the effects on the global warming when forcing unnecessary computation cycles by the distro packaging rules. Are these rules really necessary for a package, which poses a negligible security risk? |
I'm so sorry that I didn't see this before; there are so many github notifications.... I compile on Fedora 29 and 31. Yes, the default Fedora flags are quite strict, but note that the definition of "security sensitive" is basically anything that will ever open a file that could potentially come from somewhere else so you end up including everything that runs on the desktop. After all, I think you'd want the browser to offer to start PrusaSlicer when the user clicks on an STL file, but only if you can trust it to run on untrusted data. In any case, I can't comment on the overhead as I really have no idea. Do note that I'm not doing anything to enable these extra checks; they are used for all packages in Fedora. I would expect that most other distributions would eventually followed suit if they haven't already and I'm sure I can get some expert to provide more information on the tradeoffs involved if you would really like to know. Fedora is very closely linked into GCC upstream (as well as glibc) and decisions about what flags to enable are generally made by GCC or glibc developers. As for the package I'm building, I did have a fork at https://src.fedoraproject.org/fork/tibbs/rpms/slic3r-prusa3d but I've moved on to getting the renamed version properly into the distribution. Hopefully that won't take too long as I'm nearly ready to submit it. |
thanks for your effort.
út 4. 6. 2019 v 2:08 odesílatel Jason Tibbitts <[email protected]>
napsal:
… I'm so sorry that I didn't see this before; there are so many github
notifications....
I compile on Fedora 29 and 31. Yes, the default Fedora flags are quite
strict, but note that the definition of "security sensitive" is basically
anything that will ever open a file that could potentially come from
somewhere else so you end up including everything that runs on the desktop.
After all, I think you'd want the browser to offer to start PrusaSlicer
when the user clicks on an STL file, but only if you can trust it to run on
untrusted data.
In any case, I can't comment on the overhead as I really have no idea. Do
note that I'm not doing anything to enable these extra checks; they are
used for all packages in Fedora. I would expect that most other
distributions would eventually followed suit if they haven't already and
I'm sure I can get some expert to provide more information on the tradeoffs
involved if you would really like to know. Fedora is very closely linked
into GCC upstream (as well as globc) and decisions about what flags to
enable are generally made by GCC or glibc developers.
As for the package I'm building, I did have a fork at
https://src.fedoraproject.org/fork/tibbs/rpms/slic3r-prusa3d but I've
moved on to getting the renamed version properly into the distribution.
Hopefully that won't take too long as I'm nearly ready to submit it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2288?email_source=notifications&email_token=ABMPSI4JRC5WKNTDQAO4BM3PYWXAHA5CNFSM4HOELSMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW3A23I#issuecomment-498470253>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABMPSI5ZKIYN7ROPA5LSEELPYWXAHANCNFSM4HOELSMA>
.
|
We fixed the crash that was reported initially. Closing for now. |
For the record, I did ask about the performance impact of this and did get a reasonable response from Florian Wiemer, who I believe is a glibc developer: I'll quote the relevant text below. I am happy to ask for more information if it would be useful. (Personally I'm not sure just what you would look for in a profile; otherwise I could do some testing myself.)
|
So I really thought this had been fixed, but now with 2.1.0-alpha1 I'm seeing the same
I guess the skirt_brim.t failure is new; the other files failed in 2.0.0 but were fixed with 07282eb which I applied in the Fedora package. Is it possible that was only applied on a branch or was somehow reverted? I've checked that this isn't due to additional checks in a new gcc version or something like that. |
I haven't yet looked into it properly but the workaround that fixed it was removed with ac6969c which unified config handling for the unit tests and the main application. The whole function Print::apply_config_perl_tests_only was removed and Print::apply should have taken over. It is possible that it is missing something. @bubnikv |
I have removed the "special" code, that was executed by the unit tests
only, I replaced it with the production code.
I suppose we will have to go over the tests again.
At the end of the day, we should rewrite the tests to C++, as it is PITA to
run the Perl unit tests in debug mode on developer machines.
pá 23. 8. 2019 v 8:19 odesílatel lukasmatena <[email protected]>
napsal:
… I haven't yet looked into it properly but the workaround that fixed it was
removed with ac6969c
<ac6969c992b8b260f804790edc10d98412ea8060which>
unified config handling for the unit tests and the main application.
The whole function Print::apply_config_perl_tests_only was removed and
Print::apply should have taken over. It is possible that it is missing
something. @bubnikv <https://github.com/bubnikv>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2288?email_source=notifications&email_token=ABMPSI7YWHI3EWN3CDMNCILQF56QFA5CNFSM4HOELSMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD47HSYY#issuecomment-524188003>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABMPSI3YXE3XYY7LVDDRRG3QF56QFANCNFSM4HOELSMA>
.
|
Version
2.0.0 rc2
Operating system type + version
Fedora 29
Behavior
I am trying to get the test suite to run as part of Fedora's package build process (and have largely succeeded) but several of the tests in the "integration" test suite fail. These are the tests in the top-level 't' directory of the tarball.
Basically, combineinfill.t, custom_gcode.t, fill.t, multi.t and retraction.t all abort with this message:
Some of their subtests may run but obviously nothing runs past the abort. I'm afraid that I haven't yet been able to untangle all of the C++ here, so I've no idea what's really gone wrong here, but I've extracted the following backtrace. (I removed 19 other threads that weren't doing anything.)
The text was updated successfully, but these errors were encountered: