[Bug default/24157] Wrong support of Ada ranges

[Bug default/24157] Wrong support of Ada ranges

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24157

--- Comment #2 from dodji at redhat dot com ---
This issue should now be fixed by commit
https://sourceware.org/git/?p=libabigail.git;a=commit;h=84ec7847439775bda0f4287626ada8cb741ce252
in the master branch of the Libabigail's Git repository.

The issue had indeed to do with the recent Ada support of Libabigail
which is still quite new.

Just so you know, now that the abipkgdiff program can compare the
GtkAda-gl-2.24.2-29.fc29.x86_64.rpm and
GtkAda-gl-2.24.2-30.fc30.x86_64.rpm packages, here is the change
report that the comparison is now yielding:

================ changes of 'libgtkada_gl-2.24.so.2'===============
  Functions changes summary: 0 Removed, 2 Changed (3 filtered out), 0 Added
functions
  Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
  Function symbols changes summary: 0 Removed, 0 Added function symbol not
referenced by debug info
  Variable symbols changes summary: 6 Removed, 6 Added variable symbols not
referenced by debug info

  2 functions with some indirect sub-type change:

    [C]'function void gl_h__glgentextures(const gdk__gl__gl_configs, const
gl_h__gluint_vec___XUP)' at gl_h.adb:35:1 has some indirect sub-type changes:
      parameter 2 of type 'const gl_h__gluint_vec___XUP' has sub-type changes:
        in unqualified underlying type 'struct gl_h__gluint_vec___XUP' at
gl_h.ads:57:1:
          type size hasn't changed
          1 data member change:
           type of 'gl_h__gluint_vec___XUP::gl_h__gluint_vec___XUB*
gl_h__gluint_vec___XUP::P_BOUNDS' changed:
             in pointed to type 'struct
gl_h__gluint_vec___XUP::gl_h__gluint_vec___XUB' at gl_h.ads:57:1:
               type size hasn't changed
               2 data member changes:
                type of 'integer
gl_h__gluint_vec___XUP::gl_h__gluint_vec___XUB::LB0' changed:
                  entity changed from 'integer' to '<range
natural___XDLU_0__2147483647>[2147483648]'
                  type size changed from 32 to 2147483647 (in bits)

                type of 'integer
gl_h__gluint_vec___XUP::gl_h__gluint_vec___XUB::UB0' changed:
                  entity changed from 'integer' to '<range
natural___XDLU_0__2147483647>[2147483648]'
                  type size changed from 32 to 2147483647 (in bits)



    [C]'function gtk__glarea__gtk_glarea
gtk__glarea__gtk_new(gtk__glarea__gtk_glarea, const
gtk__glarea__attributes_array___XUP)' at gtk-glarea.adb:63:1 has some indirect
sub-type changes:
      parameter 2 of type 'const gtk__glarea__attributes_array___XUP' has
sub-type changes:
        in unqualified underlying type 'struct
gtk__glarea__attributes_array___XUP' at gtk-glarea.ads:48:1:
          type size hasn't changed
          1 data member change:
           type of
'gtk__glarea__attributes_array___XUP::gtk__glarea__attributes_array___XUB*
gtk__glarea__attributes_array___XUP::P_BOUNDS' changed:
             in pointed to type 'struct
gtk__glarea__attributes_array___XUP::gtk__glarea__attributes_array___XUB':
               type size hasn't changed
               2 data member changes:
                type of 'integer
gtk__glarea__attributes_array___XUP::gtk__glarea__attributes_array___XUB::LB0'
changed:
                  entity changed from 'integer' to '<range
natural___XDLU_0__2147483647>[2147483648]'
                  type size changed from 32 to 2147483647 (in bits)

                Type of 'integer
gtk__glarea__attributes_array___XUP::gtk__glarea__attributes_array___XUB::UB0'
changed:
                  entity changed from 'integer' to '<range
natural___XDLU_0__2147483647>[2147483648]'
                  type size changed from 32 to 2147483647 (in bit[Thread
0x7ffff579a700 (LWP 13228) exited]
s)




  6 Removed variable symbols not referenced by debug info:

    gtk__glarea__C210s
    gtk__glarea__gtk_glarea_recordB43s
    gtk__glarea__gtk_glarea_recordE39s
    gtk__glarea__gtk_glarea_recordH40s
    gtk__glarea__gtk_glarea_recordR41s
    gtk__glarea__gtk_glarea_recordR41s___UNC

  6 Added variable symbols not referenced by debug info:

    gtk__glarea__C208s
    gtk__glarea__gtk_glarea_recordB41s
    gtk__glarea__gtk_glarea_recordE37s
    gtk__glarea__gtk_glarea_recordH38s
    gtk__glarea__gtk_glarea_recordR39s
    gtk__glarea__gtk_glarea_recordR39s___UNC

================ end of changes of 'libgtkada_gl-2.24.so.2'===============

Thank you for reporting the issue and sorry for the inconvenience.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24157] Wrong support of Ada ranges

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24157

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from dodji at redhat dot com ---
Closing this now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24157] New: misdirected emails about assertion failures

[Bjorn@xn--rombobjrn-67a.se]

https://sourceware.org/bugzilla/show_bug.cgi?id=24157

            Bug ID: 24157
           Summary: misdirected emails about assertion failures
           Product: libabigail
           Version: unspecified
               URL: https://pagure.io/task-abicheck/issue/19
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: Bjorn@xn--rombobjrn-67a.se
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Fedora's Taskotron is reporting assertion failures to the wrong person, and
Kamil Páral says it should be discussed here. The original report is here:

https://pagure.io/task-abicheck/issue/19

As a package maintainer, I'm getting emails saying "dist.abicheck FAILED" for
various packages. After following the link I find that the error is a failed
assertion:

https://taskotron.fedoraproject.org/artifacts/all/989b44ce-255d-11e9-a292-525400fc9f92/tests.yml/GtkAda-2.24.2-30.fc30.log

I understand an assertion failure in the ABI checker to mean that the ABI
checker is defective. This should be reported to the maintainer of the ABI
checker, not to the maintainer of the package that it tried to check. If these
mails keep coming I'll be inclined to ignore all notifications about
dist.abicheck, and then I won't notice if it finds an actual problem with one
of my packages some day.

Possibly the outcome should be "ERROR" instead of "FAILED", in case "ERROR" is
supposed to mean an error in the test itself. (The documentation at
https://qa.fedoraproject.org/docs/libtaskotron/latest/resultyaml.html lists
some allowed values, but makes no attempt to define their meanings.)

If the assertion is actually intended to point out some problem in the package,
then it needs a completely different error message, because this doesn't tell
me anything.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24157] Wrong support of Ada ranges

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24157

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2019-02-06
            Summary|misdirected emails about    |Wrong support of Ada ranges
                   |assertion failures          |
     Ever confirmed|0                           |1

--- Comment #1 from dodji at redhat dot com ---
Thank you for reporting this issue.

The root cause of this issue seems to be that libabigail's  (recent) support of
Ada ranges is lacking.  In this case, the lower bound of the Ada range is a
signed negative integer whereas the upper bound is a positive integer. 
Libabigail's internal representation for ranges expects the two bounds to
positive (unsigned) integers.  So I am changing the internal representation to
handle that case.

There is indeed a second tangent issue which is that the ABI verifier of Fedora
(aka task-abicheck), which uses Libabigail's abipkgdiff tool should have
notified the maintainers of task-abicheck about the crash of abipkgdiff rather
than making you think that there was a problem with the gtkada package program.
 That second issue is tracked by the bug
https://pagure.io/task-abicheck/issue/19 which you kindly filled.

I am thus changing the title of this problem report to reflect the libabigail
root cause.  The task-abicheck issue will be tracked and hopefully fixed at the
level of ttps://pagure.io/task-abicheck/issue/19.

-- 
You are receiving this mail because:
You are on the CC list for the bug.