Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1270268 - [epel7s390x] perl-IPC-Shareable SRPM does not build correctly on s390x
Summary: [epel7s390x] perl-IPC-Shareable SRPM does not build correctly on s390x
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: perl-IPC-Shareable
Version: epel7
Hardware: s390x
OS: Linux
high
medium
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: epel7s390x
TreeView+ depends on / blocked
 
Reported: 2015-10-09 13:02 UTC by IBM Bug Proxy
Modified: 2017-03-21 08:08 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-21 08:08:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Build Log (6.98 KB, text/plain)
2015-10-09 13:02 UTC, IBM Bug Proxy
no flags Details
Reproducer (923 bytes, text/plain)
2015-10-16 15:38 UTC, Petr Pisar
no flags Details


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 131551 0 None None None Never

Description IBM Bug Proxy 2015-10-09 13:02:13 UTC

Comment 1 IBM Bug Proxy 2015-10-09 13:02:16 UTC
The EPEL 7 SRPM for perl-IPC-Shareable 
https://dl.fedoraproject.org/pub/epel/7/SRPMS/p/perl-IPC-Shareable-0.61-1.el7.src.rpm
does not build correctly in Mock on s390x

Failed 1/14 test programs. 2/96 subtests failed.
t/35clean.t (Wstat: 0 Tests: 11 Failed: 2)
  Failed tests:  4-5

This prevents the RPM from being built in Mock. Cause for the subtest failure is:

Couldn't remove shared memory segment 983040: Invalid argument at t/35clean.t line 66.
Use of uninitialized value in semctl at /usr/lib64/perl5/IPC/Semaphore.pm line 66.
Use of uninitialized value in list slice at /usr/lib64/perl5/IPC/Semaphore.pm line 66.
Couldn't remove semaphore set 983040: Invalid argument at t/35clean.t line 66.

Comment 2 IBM Bug Proxy 2015-10-09 13:02:22 UTC
Created attachment 1081331 [details]
Build Log

Comment 3 Petr Pisar 2015-10-16 12:32:39 UTC
Detailed test log:

$ prove -b -v t/35clean.t 
t/35clean.t .. 
1..11
ok 1
ok 2
ok 3
not ok 4
not ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
Couldn't remove shared memory segment 1605632: Invalid argument at t/35clean.t line 66.
Use of uninitialized value in semctl at /usr/lib64/perl5/IPC/Semaphore.pm line 66.
Use of uninitialized value in list slice at /usr/lib64/perl5/IPC/Semaphore.pm line 66.
Couldn't remove semaphore set 1605632: Invalid argument at t/35clean.t line 66.
Failed 2/11 subtests

Comment 4 Petr Pisar 2015-10-16 15:38:39 UTC
Created attachment 1083734 [details]
Reproducer

If the reproducer is run with SHAREABLE_DEBUG=1 environment variable, debugging log will show:

--- ok  2015-10-16 17:14:24.227346866 +0200
+++ bad 2015-10-16 17:14:40.000000000 +0200
[...]
-IPC::Shareable (8990) debug:
+IPC::Shareable (27668) debug:
     IPC::Shareable::_tie tells us that:
-        'binding to existing segment on '
-        14090243
+        'brand new segment on '
+        3375105
  at ./reproducer line 39.
[...]

Both platforms (ok=x86_64, bad=s390x) should show "brand new segment" because this is the very first tie() call with create => 'yes' option in parent.

Later, the child's clean_up() call differs like:

-ok read after cleanup
-IPC::Shareable (8991) debug:
+IPC::Shareable (27669) debug:
+    IPC::Shareable::remove called with:
+        $_[0] = IPC::Shareable=HASH(0x92712060): shmid: 3375105; $opts = {
+          '_magic' => '',
+          '_owner' => '27669',
+          'create' => '',
+          'destroy' => 0,
+          'exclusive' => '',
+          'key' => 'hash',
+          'mode' => 438,
+          'size' => 65536
+        };
+ at ./reproducer line 31.
+not ok read after cleanup

Which causes failing the tests because it removes the foreign process' segment even if clean_up() should not harness only segments created by current process.

Comment 5 Petr Pisar 2015-10-16 15:49:07 UTC
I forgot to write down the child's tie in between the two differing events looks like:

-IPC::Shareable (8991) debug:
+IPC::Shareable (27669) debug:
     IPC::Shareable::_tie tells us that:
-        'binding to existing segment on '
-        14090243
+        'brand new segment on '
+        3375105
  at ./reproducer line 25.

Which is in line with the tests and explains why the clean_up() removes the segment in the child.

It also displays that the 'brand new segment on ' is faulty here.

Comment 6 IBM Bug Proxy 2016-02-23 17:31:51 UTC
------- Comment From vsandhya.com 2016-02-23 12:14 EDT-------
Any updates?

Comment 7 IBM Bug Proxy 2017-03-20 06:31:02 UTC
------- Comment From urjawere.com 2017-03-20 02:22 EDT-------
Any Updates ?

Comment 8 Petr Pisar 2017-03-21 08:08:25 UTC
This package has never been built for EPEL7 and due to this was completely removed from git source repository two years ago:

commit 96b4a4de72534fe911cb17e16f9d5445d59d0977
Author: Till Maas <opensource>
Date:   Thu May 19 18:04:18 2016 +0200

    2016-05-19: Retired orphaned package, because it was orphaned for
    more than six weeks.


Note You need to log in before you can comment on or make changes to this bug.