Bug 1026935

Summary: gobject-introspection: fch hash generator is broken
Product: Red Hat Enterprise Linux 7 Reporter: Florian Weimer <fweimer>
Component: gobject-introspectionAssignee: Colin Walters <walters>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: vbenes, walters
Target Milestone: rcFlags: vbenes: needinfo? (walters)
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-15 07:28:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1026934    

Description Florian Weimer 2013-11-05 17:00:25 UTC
This loop in fch_buckets_get_indexes_sorted_by_size in girepository/cmph/fch_buckets.c

186		for(i = (int)buckets->max_size - 1; i >= 0; i--)
187		{
188			sum += value;
189			value = nbuckets_size[i];
190			nbuckets_size[i] = sum;
191			
192		}

never exits because the condition i >= 0 is always true; i is declared unsigned:

175		cmph_uint32 i = 0;

As a result, the CMPH_FCH code does not work at all.

Comment 2 Florian Weimer 2013-11-06 09:53:24 UTC
This has already been fixed upstream, in commit 0c13ae5fa4716e86815d129c1ed88c5fe55cdd44.

Some of the other generators are broken as well.  The file loaders do not perform sufficient checking and crash on corrupted files.  There is a /var/tmp race in brz.c.  buffer_entry_read_key and buffer_manager_read_key can write bytes after *keylen, corrupting the stack frame in brz_gen_mphf.  All this code isn't used, but still compiled and linked.

Let's hope that the code we actually use works better.

Comment 3 Colin Walters 2013-11-07 16:05:59 UTC
(In reply to Florian Weimer from comment #2)
> This has already been fixed upstream, in commit
> 0c13ae5fa4716e86815d129c1ed88c5fe55cdd44.

Yeah...i would have liked to depend on CMPH as a library, but it needed a number of patches, and at the time upstream indicated they might port to C++, which would make the library a lot less interesting for me.

Now 3 years later...not sure.  It looks like the looming C++ port is now just an experimental additional interface.

Filed this as https://bugzilla.gnome.org/show_bug.cgi?id=711622

> Let's hope that the code we actually use works better.

The only bits we're using are BDZ.  Are there any errors in that?

Comment 4 Florian Weimer 2013-11-07 18:00:13 UTC
(In reply to Colin Walters from comment #3)

> The only bits we're using are BDZ.  Are there any errors in that?

It looked better to me (including the generator part).  The only risk I see is false negatives during lookups because of some subtle algorithm issue.

Comment 5 RHEL Program Management 2014-03-28 05:48:21 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 9 RHEL Program Management 2020-12-15 07:28:07 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.