Description of problem: 1. Open a new file. 2. Save the file That's it -- Crash! It crashes when the new file is saved Version-Release number of selected component: 1:freecad-0.16-12.fc29 Additional info: reporter: libreport-2.9.3 backtrace_rating: 4 cmdline: /usr/bin/FreeCAD crash_function: std::__replacement_assert executable: /usr/lib64/freecad/bin/FreeCAD journald_cursor: s=f2029e67e3f54a16be8f23512ae2a773;i=20737;b=30b7b51156c547df8c06822a7bf8ae5a;m=7b191e4e;t=568877545addb;x=8bd8f1403a7c8bfd kernel: 4.16.0-0.rc6.git0.1.fc29.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000
Created attachment 1414552 [details] File: backtrace
Created attachment 1414553 [details] File: cgroup
Created attachment 1414554 [details] File: core_backtrace
Created attachment 1414555 [details] File: cpuinfo
Created attachment 1414556 [details] File: dso_list
Created attachment 1414557 [details] File: environ
Created attachment 1414558 [details] File: limits
Created attachment 1414559 [details] File: maps
Created attachment 1414560 [details] File: mountinfo
Created attachment 1414561 [details] File: open_fds
Created attachment 1414562 [details] File: proc_pid_status
Created attachment 1414563 [details] File: var_log_messages
Since 0.16 has been out for probably 2 years, it's probably a dependent library causing the issue. I'll make some test packages when I have time.
I kicked off a scratch build, please test the packages when it completes and see if you can reproduce the crash. https://koji.fedoraproject.org/koji/taskinfo?taskID=26081056
same issue as described in the bug. /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 = unsigned char; _Alloc = std::allocator<unsigned char>; std::vector<_Tp, _Alloc>::const_reference = const unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed. Aborted (core dumped)
I just build 0.17 pre-release on Rawhide, might as well give it a shot.
Nope ... still having issues despite the update. Test failed /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 = unsigned char; _Alloc = std::allocator<unsigned char>; std::vector<_Tp, _Alloc>::const_reference = const unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed. Aborted (core dumped)
It's likely a problem in a dependant library then. It will take some looking into.
I can't reproduce it on f27 so it seems to be with rawhide...
(gdb) up #1 0x00007ffff48ec591 in __GI_abort () at abort.c:79 79 raise (SIGABRT); (gdb) #2 0x00007ffff7445178 in std::__replacement_assert (__file=<optimized out>, __line=<optimized out>, __function=<optimized out>, __condition=<optimized out>) at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389 warning: Source file is more recent than executable. 2389 __builtin_abort(); (gdb) #3 0x00007fffef134eb9 in std::vector<unsigned char, std::allocator<unsigned char> >::operator[] (this=0x7fffffffae48, __n=0) at /usr/include/c++/8/bits/stl_vector.h:950 950 __glibcxx_requires_subscript(__n); (gdb) #4 0x00007fffef134d87 in zipios::writeByteSeq (os=..., vec=std::vector of length 0, capacity 0) at ./../zipios++/zipheadio.h:153 153 os.rdbuf()->sputn( reinterpret_cast< const char * >( &( vec[ 0 ] ) ), vec.size() ) ; (gdb) p vec $1 = std::vector of length 0, capacity 0 (gdb) up #5 0x00007fffef1345db in zipios::operator<< (os=..., zlh=...) at zipheadio.cpp:114 114 writeByteSeq( os, zlh.extra_field ) ; (gdb) p zlh $2 = (const zipios::ZipLocalEntry &) @0x7fffffffae00: {<zipios::FileEntry> = {_vptr.FileEntry = 0x7fffef348b10 <vtable for zipios::ZipLocalEntry+16>, _refcount = {_ref_count = 0}}, static signature = 67324752, extract_version = 20, gp_bitfield = 0, compress_method = 8, last_mod_ftime = 45760, last_mod_fdate = 65535, crc_32 = 32767, compress_size = 4109587692, uncompress_size = 32767, filename_len = 12, extra_field_len = 0, filename = "Document.xml", extra_field = std::vector of length 0, capacity 0, _valid = false} (gdb) p zlh.extra_field $3 = std::vector of length 0, capacity 0 So at zipios++/zipheadio.h:153: there is vec[ 0 ] but vec is std::vector of length 0, so this aborts. This file in zipios++ : https://koji.fedoraproject.org/koji/packageinfo?packageID=13748
Note that gcc8 now checks this type of access every time (i.e. std::vector<foo> bar; bar[pos]). Very quick workaround: maybe this works? https://koji.fedoraproject.org/koji/taskinfo?taskID=26290431
For F-29: https://koji.fedoraproject.org/koji/taskinfo?taskID=26290580
Does your patch change ABI? If so I'll have to rebuild all the dependencies...
Created attachment 1420116 [details] workaround (In reply to Richard Shaw from comment #23) > Does your patch change ABI? If so I'll have to rebuild all the > dependencies... No. I've attached my proposal workaround.
Onyeibo, would you check if the workaround on comment 22 works?
(In reply to Mamoru TASAKA from comment #25) > Onyeibo, would you check if the workaround on comment 22 works? Yes it does. Thanks
(In reply to Mamoru TASAKA from comment #22) > For F-29: https://koji.fedoraproject.org/koji/taskinfo?taskID=26290580 So where do I add karma to this?
(In reply to Onyeibo Oku from comment #27) > (In reply to Mamoru TASAKA from comment #22) > > For F-29: https://koji.fedoraproject.org/koji/taskinfo?taskID=26290580 > > So where do I add karma to this? Well, not pushed into bodhi yet. Richard, would you take care of this?
Yes, now that we've confirmed the patch fixes the problem. Reassigning...
The build for rawhide is complete but I'm still not 100% how rawhide works. I'm guessing we'll have to wait for a new compose to complete before it will be available unless you do a "dnf --enablerepo=local update zipios++".
zipios++-0.1.5.9-20.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3845a777dc
zipios++-0.1.5.9-20.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2e2b1ae3ab
zipios++-0.1.5.9-20.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4c20d089d4
zipios++-0.1.5.9-20.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2e2b1ae3ab
zipios++-0.1.5.9-20.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-3845a777dc
zipios++-0.1.5.9-20.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-4c20d089d4
zipios++-0.1.5.9-20.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
zipios++-0.1.5.9-20.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
zipios++-0.1.5.9-20.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.