Bug 1561893

Summary: [abrt] freecad: std::__replacement_assert(): FreeCAD killed by SIGABRT
Product: [Fedora] Fedora Reporter: Onyeibo Oku <twohotis>
Component: zipios++Assignee: Richard Shaw <hobbes1069>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: cz172638, hobbes1069, john, mtasaka, twohotis
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/b93a64938abb3471528c9426b3939ce7477a54db
Whiteboard: abrt_hash:d5885a407071f1b4d330bab9f5c8350e1736d02f;VARIANT_ID=workstation;
Fixed In Version: zipios++-0.1.5.9-20.fc27 zipios++-0.1.5.9-20.fc26 zipios++-0.1.5.9-20.fc28 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-24 04:01:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: cpuinfo
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: mountinfo
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages
none
workaround none

Description Onyeibo Oku 2018-03-29 07:04:12 UTC
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

Comment 1 Onyeibo Oku 2018-03-29 07:04:24 UTC
Created attachment 1414552 [details]
File: backtrace

Comment 2 Onyeibo Oku 2018-03-29 07:04:27 UTC
Created attachment 1414553 [details]
File: cgroup

Comment 3 Onyeibo Oku 2018-03-29 07:04:32 UTC
Created attachment 1414554 [details]
File: core_backtrace

Comment 4 Onyeibo Oku 2018-03-29 07:04:34 UTC
Created attachment 1414555 [details]
File: cpuinfo

Comment 5 Onyeibo Oku 2018-03-29 07:04:38 UTC
Created attachment 1414556 [details]
File: dso_list

Comment 6 Onyeibo Oku 2018-03-29 07:04:41 UTC
Created attachment 1414557 [details]
File: environ

Comment 7 Onyeibo Oku 2018-03-29 07:04:43 UTC
Created attachment 1414558 [details]
File: limits

Comment 8 Onyeibo Oku 2018-03-29 07:04:48 UTC
Created attachment 1414559 [details]
File: maps

Comment 9 Onyeibo Oku 2018-03-29 07:04:51 UTC
Created attachment 1414560 [details]
File: mountinfo

Comment 10 Onyeibo Oku 2018-03-29 07:04:54 UTC
Created attachment 1414561 [details]
File: open_fds

Comment 11 Onyeibo Oku 2018-03-29 07:04:56 UTC
Created attachment 1414562 [details]
File: proc_pid_status

Comment 12 Onyeibo Oku 2018-03-29 07:04:58 UTC
Created attachment 1414563 [details]
File: var_log_messages

Comment 13 Richard Shaw 2018-03-31 11:59:57 UTC
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.

Comment 14 Richard Shaw 2018-03-31 12:37:53 UTC
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

Comment 15 Onyeibo Oku 2018-03-31 19:10:30 UTC
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)

Comment 16 Richard Shaw 2018-04-01 01:48:54 UTC
I just build 0.17 pre-release on Rawhide, might as well give it a shot.

Comment 17 Onyeibo Oku 2018-04-04 22:44:03 UTC
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)

Comment 18 Richard Shaw 2018-04-06 20:24:29 UTC
It's likely a problem in a dependant library then. It will take some looking into.

Comment 19 Richard Shaw 2018-04-10 12:27:47 UTC
I can't reproduce it on f27 so it seems to be with rawhide...

Comment 20 Mamoru TASAKA 2018-04-10 13:32:13 UTC
(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

Comment 21 Mamoru TASAKA 2018-04-10 13:42:17 UTC
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

Comment 22 Mamoru TASAKA 2018-04-10 13:50:36 UTC
For F-29: https://koji.fedoraproject.org/koji/taskinfo?taskID=26290580

Comment 23 Richard Shaw 2018-04-10 15:29:32 UTC
Does your patch change ABI? If so I'll have to rebuild all the dependencies...

Comment 24 Mamoru TASAKA 2018-04-10 23:06:45 UTC
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.

Comment 25 Mamoru TASAKA 2018-04-12 03:29:31 UTC
Onyeibo, would you check if the workaround on comment 22 works?

Comment 26 Onyeibo Oku 2018-04-12 22:57:00 UTC
(In reply to Mamoru TASAKA from comment #25)
> Onyeibo, would you check if the workaround on comment 22 works?

Yes it does.  Thanks

Comment 27 Onyeibo Oku 2018-04-12 23:01:32 UTC
(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?

Comment 28 Mamoru TASAKA 2018-04-13 07:45:59 UTC
(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?

Comment 29 Richard Shaw 2018-04-13 12:00:45 UTC
Yes, now that we've confirmed the patch fixes the problem. Reassigning...

Comment 30 Richard Shaw 2018-04-13 13:26:29 UTC
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++".

Comment 31 Fedora Update System 2018-04-13 13:26:34 UTC
zipios++-0.1.5.9-20.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3845a777dc

Comment 32 Fedora Update System 2018-04-13 13:26:44 UTC
zipios++-0.1.5.9-20.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2e2b1ae3ab

Comment 33 Fedora Update System 2018-04-13 13:26:51 UTC
zipios++-0.1.5.9-20.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4c20d089d4

Comment 34 Fedora Update System 2018-04-15 02:26:08 UTC
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

Comment 35 Fedora Update System 2018-04-15 16:22:03 UTC
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

Comment 36 Fedora Update System 2018-04-15 21:44:17 UTC
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

Comment 37 Fedora Update System 2018-04-24 04:01:44 UTC
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.

Comment 38 Fedora Update System 2018-04-25 18:16:09 UTC
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.

Comment 39 Fedora Update System 2018-04-27 04:02:30 UTC
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.