abrt/faf

Attaching MantisBT bugs to reports does not work, hashes differ depending on FAF server

Closed this issue · 3 comments

djuarezg commented

This issue is derived from #523 (comment)

faf attach-centos-bugs links reports with already existing MantisBT bugs based on the hash that appears on the abrt_hash field. The problem is that the abrt_hash differs depending to to which server the ureport is being sent.

Same error, reported to two different instances, creates a different bthash:

faf=# select * from reportbthashes;
 type  |                   hash                   | backtrace_id 
-------+------------------------------------------+--------------
 NAMES | 0a71a4adf9b2efcb9d6608d6568c1e6836f15574 |            1
 NAMES | d2c00324955eeb5973b0f37b53aab7086faf7144 |            1
(2 rows)

[djuarezg@localhost ~]$ abrt-cli list
Private Reports is enabled, use 'abrt-cli -a COMMAND' to get the detected problems.
id 6e108d1053e4e12b96d7db1dab05205fa6318293
reason:         sleep killed by SIGSEGV
time:           Mon 25 May 2020 04:36:26 PM CEST
cmdline:        sleep 10m
package:        coreutils-8.22-24.el7
uid:            1000 (djuarezg)
count:          2
Directory:      /var/spool/abrt/ccpp-2020-05-25-16:36:26-27533
Reported:       https://abrtanalytics.web.cern.ch/faf/reports/bthash/5bb483b5ca0ea992b911f4d845479a085eab0f24
                https://retrace.fedoraproject.org/faf/reports/bthash/058896b486386a0060459830992f69a275e7f3fd

This seems to make that command useless when deploying private instances.

How is such hash specifically determined? Cannot seem to find it for now.

EDIT: cd8d687#diff-f99db2d089007acb7880d0cb22908f75R47 this is what checks the corresponding hash to see if there is a match.

djuarezg commented

I saw that there is an action called faf addcompathashes which adds new hashes to reports, which basically means that both https://abrtanalytics.web.cern.ch/faf/reports/bthash/058896b486386a0060459830992f69a275e7f3fd and https://retrace.fedoraproject.org/faf/reports/bthash/058896b486386a0060459830992f69a275e7f3fd use the same bthash. Not actually sure how this thing works.

Running faf attach-centos-bugs afterwards actually links it..., I guess this should be documented somewhere.

I am preparing a stable and documented deployment for our infra, I could help adding documentation for this kind of things when done.

ernestask commented

Right, so the difference is that the “non-compat” hashing involves encoding the file name, whereas compat-hashing just takes the Unicode representation.

If you observe how hashbase changes, you’ll see this (w\ slight variation):

['coreutils', "clock_nanosleep@@GLIBC_2.17 @ b'/lib64/libc.so.6'", "__nanosleep @ b'/lib64/libc.so.6'", "rpl_nanosleep @ b'/usr/bin/sleep'", "xnanosleep @ b'/usr/bin/sleep'", "main @ b'/usr/bin/sleep'"]

If you think “hmm, those byte literals sure look odd”, then a winner is you, because those byte-literal-looking objects appear like that verbatim in the resulting string, Bs and quotes and all.

ernestask commented

Honestly, with my changes, I don’t see the point for compat-hashing. As usual, the commit that brought it on contains no information, so I guess we’ll never know.