octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59869] octave-parallel tests trigger "int32 s


From: Christian Ehrhardt
Subject: [Octave-bug-tracker] [bug #59869] octave-parallel tests trigger "int32 scalar cannot be indexed with" on systems with 1 CPU
Date: Thu, 14 Jan 2021 02:46:37 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36

URL:
  <https://savannah.gnu.org/bugs/?59869>

                 Summary: octave-parallel tests trigger "int32 scalar cannot
be indexed with" on systems with 1 CPU
                 Project: GNU Octave
            Submitted by: paelzer
            Submitted on: Thu 14 Jan 2021 07:46:35 AM UTC
                Category: Octave Forge Package
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Regression
                  Status: None
             Assigned to: None
         Originator Name: Christian Ehrhardt
        Originator Email: 
             Open/Closed: Open
                 Release: 6.1.0
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Hi,
I was tracking an issue of octave (6.1.1~hg.2020.12.27-3) and octave-parallel
(4.0.0-2) which continuously started to always fail [1] in the Ubuntu
autopkgtest infrastructure [2].

The error looked like:


[inst/pararrayfun.m]
>>>>> /tmp/autopkgtest.hf2ucm/build.AhK/src/inst/pararrayfun.m
...
 assert (res = pararrayfun (2, @ (x, y) x * y, [1, 2, 3, 4], [2, 3, 4, 5],
"ChunksPerProc", 2, "CumFunc", @ (a, b) a + b), 40)
!!!!! test failed
int32 scalar cannot be indexed with {
5 tests, 4 passed, 0 known failure, 0 skipped


The biggest problem with that initially was that it only triggered in our
autopkgtest environment.
It happened not on one, but on all VM based architectures x86 + arm64 +
ppc64el + s390x.
If I run the same code in Ubuntu or Debian in:
- local containers
- or all DebCI runs which are in containers
- or Ubuntu's armhf runs which are in containers
- on bare metal
It all works just fine and as expected.

Way more debug data and steps that were taken in between can be found on the
Ubuntu bug tracker for this at [3]. Looking back some of those steps are
hilarious, but afterwards you are always smarter :-)

I was eventually able to recreate the issue on a KVM guest in the same
Openstack cloud that does our test runs. And I realized that if I run it in a
local KVM guest it is failing as well IFF I give it only one CPU.

So it seems the test needs at least 2 CPUs to not fail.

I was trying to further corner the root cause and found that - on the affected
systems - the following is enough to reproduce the issue:


# on Ubuntu hirsute (21.04) or Debian-sid do
$ apt install octave-parallel
$ octave-cli
octave:1> pkg ('load', 'parallel');
octave:2> pararrayfun (2, @ (x, y) x * y, [1, 2, 3, 4], [2, 3, 4, 5],
"ChunksPerProc", 2, "CumFunc", @ (a, b) a + b), 40
 error: int32 scalar cannot be indexed with {
 error: called from
     parcellfun at line 206 column 25
     chunk_parcellfun at line 47 column 25
     parcellfun at line 142 column 28
     pararrayfun at line 85 column 28


Dropping the 2 after ChunksPerProc to 1 makes it not fail that bad.

 octave:6> pararrayfun (1, @ (x, y) x * y, [1, 2], "ChunksPerProc", 1,
"CumFunc", @ (a, b) a + b), 40
 ans = 40


It could be related to the min of "2" CPUs that I've found.
But TBH - I don't really know what I'm changing here.


I've found that when downgrading to the former Debian/Ubuntu versions being:
- octave=5.2.0-3build1
- octave-parallel=3.1.3-4build1
- octave-common=5.2.0-3build1
- octave-struct=1.0.16-6
Then the test as run from octave parallel works even on just a one CPU
system:


octave:2> assert (res = parcellfun (2, @ (x, y) x * y, {1, 2, 3, 4}, {2, 3, 4,
5}, "ChunksPerProc", 2, "CumFunc", @ (a, b) a + b), 40)
parcellfun: 4/4 jobs done


Therefore I'd classify it as a regression unless you think otherwise.

Would it be possible to change the test in a way to not fail on those small
systems? Or if this is considered a bug in octave/octave-parallel fix it
there=

After an discussion on IRC I was asked to file a bug which I hereby do. The
test is easy for me and I'm to be able to create affected (in our cloud) and
unaffected (local VMs) systems as needed. So if there is a good suggestion
where to look at - let me know.

[1]:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20210112_151852_47229@/log.gz
[2]: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure
[3]: https://bugs.launchpad.net/ubuntu/+source/octave-parallel/+bug/1911400




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59869>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]