Gnuradio on ARM: gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument

gnuradio maint branch, v.3.6.4.1

‘make test’ fails, due to gr-core-test-all failing.

At first, I was getting an error due to the “shmat (2)” line above where
this error occurs, but it has settled on (3).
I added a couple lines of extra debug output (source code is below the
error output).

test 6
Start 6: gr-core-test-all

6: Test command: /bin/sh
“/src/gnuradio/build/gnuradio-core/src/tests/gr-core-test-all_test.sh”
6: Test timeout computed to be: 9.99988e+06
6: Testing gr_vmcircbuf_createfilemapping_factory…
6: gr_vmcircbuf_createfilemapping: createfilemapping is not available
6: … gr_vmcircbuf_createfilemapping_factory: Doesn’t work
6: Testing gr_vmcircbuf_sysv_shm_factory…
6: gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument
6: gr_vmcircbuf_sysv_shm: shmid1=163842, first_copy+pagesize=0x40039000
6: … gr_vmcircbuf_sysv_shm_factory: Doesn’t work
6: Testing gr_vmcircbuf_mmap_shm_open_factory…
6: … gr_vmcircbuf_mmap_shm_open_factory: OK
6: Testing gr_vmcircbuf_mmap_tmpfile_factory…
6: … gr_vmcircbuf_mmap_tmpfile_factory: OK
6: …NOTICE: test from c++ NOTICE
6: DEBUG: test from c++ DEBUG
6: INFO: test from c++ INFO
6: WARN: test from c++ WARN
6: ERROR: test from c++ ERROR
6: FATAL: test from c++ FATAL
6: …Using Volk machine: generic

Snippet from gr_vmcircbuf_sysv_shm.cc :

// There may be a race between our detach and attach.
//
// If the system allocates all shared memory segments at the same
// virtual addresses in all processes and if the system allocates
// some other segment to first_copy or first_copoy + size between
// our detach and attach, the attaches below could fail [I’ve never // seen it fail for this reason].

//shmdt (first_copy);

if (shmdt (first_copy) == -1){
perror(“gr_vmcircbuf_sysv_shm: shmdt (a)”); // Debug line added
}

// first read-only guard page
if (shmat (shmid_guard, first_copy, SHM_RDONLY) == (void *) -1){
perror (“gr_vmcircbuf_sysv_shm: shmat (2)”);
fprintf (stderr, “gr_vmcircbuf_sysv_shm: shmid_guard=%d,
first_copy=0x%x\n”, shmid_guard, (unsigned int) first_copy);
shmctl (shmid_guard, IPC_RMID, 0);
shmctl (shmid1, IPC_RMID, 0);
throw std::runtime_error (“gr_vmcircbuf_sysv_shm”);
}

// first copy
if (shmat (shmid1, (char *) first_copy + pagesize, 0) == (void *) -1){
perror (“gr_vmcircbuf_sysv_shm: shmat (3)”);
fprintf (stderr, “gr_vmcircbuf_sysv_shm: shmid1=%d,
first_copy+pagesize=0x%x\n”, shmid1, (unsigned int) ((char *) first_copy

  • pagesize));
    shmctl (shmid_guard, IPC_RMID, 0);
    shmctl (shmid1, IPC_RMID, 0);
    shmdt (first_copy);
    throw std::runtime_error (“gr_vmcircbuf_sysv_shm”);
    }

On an earlier test run where the shmat (2) line failed, this was the
debug output from the above code:

6: Testing gr_vmcircbuf_sysv_shm_factory…
6: gr_vmcircbuf_sysv_shm: shmat (2): Invalid argument
6: gr_vmcircbuf_sysv_shm: shmid_guard=98304, first_copy=0x400e9000

Not sure how this will affect my system. Posting this more of an FYI.

I can add more details about the build if needed.

On 04/17/2013 07:28 PM, Monahan-Mitchell, Tim wrote:

gnuradio maint branch, v.3.6.4.1

‘make test’ fails, due to gr-core-test-all failing.

At first, I was getting an error due to the “shmat (2)” line above where this
error occurs, but it has settled on (3).
I added a couple lines of extra debug output (source code is below the error
output).

I am digging into repressed memories here, so people cirrect me if I am
wrong.

GNU Radio allocates a large buffer to use for block input/output
buffers. It has about three ways to do this, one of which uses shmem
calls. These calls fail on arm due to some internal difference between
x86 and arm. (I forget what the detail is)

Since this fails, it tries another allocator that succeeds and saves
this info in a dot file. I think you see the message from gnuradio once,
then you do not see it again.

Philip

On Thu, Apr 18, 2013 at 8:57 AM, Philip B. [email protected]
wrote:

GNU Radio allocates a large buffer to use for block input/output
buffers. It has about three ways to do this, one of which uses shmem
calls. These calls fail on arm due to some internal difference between
x86 and arm. (I forget what the detail is)

Since this fails, it tries another allocator that succeeds and saves
this info in a dot file. I think you see the message from gnuradio once,
then you do not see it again.

Philip

Yep, that’s right.

Tom

wrong.
Philip

Yep, that’s right.

Tom

OK, so I ran ‘ctest -V’ twice in a row without code changes or building,
and got the
same error output below for gr-core-test-all each time:

test 6
Start 6: gr-core-test-all

6: Test command: /bin/sh
“/src/gnuradio/build/gnuradio-core/src/tests/gr-core-test-all_test.sh”
6: Test timeout computed to be: 9.99988e+06
6: Testing gr_vmcircbuf_createfilemapping_factory…
6: gr_vmcircbuf_createfilemapping: createfilemapping is not available
6: … gr_vmcircbuf_createfilemapping_factory: Doesn’t work
6: Testing gr_vmcircbuf_sysv_shm_factory…
6: gr_vmcircbuf_sysv_shm: shmat (2): Invalid argument
6: … gr_vmcircbuf_sysv_shm_factory: Doesn’t work
6: Testing gr_vmcircbuf_mmap_shm_open_factory…
6: … gr_vmcircbuf_mmap_shm_open_factory: OK
6: Testing gr_vmcircbuf_mmap_tmpfile_factory…
6: … gr_vmcircbuf_mmap_tmpfile_factory: OK
6: …NOTICE: test from c++ NOTICE
6: DEBUG: test from c++ DEBUG
6: INFO: test from c++ INFO
6: WARN: test from c++ WARN
6: ERROR: test from c++ ERROR
6: FATAL: test from c++ FATAL
6: …Using Volk machine: generic
6:
6: NOTE: This is supposed to produce an error from gr_block_executor
6: Error: gr_block_executor: propagation_policy ‘ONE-TO-ONE’ requires
ninputs == noutputs
6: [generic] [armv7_a]
6: [generic] [armv7_a]
6: [generic]
6: [generic]
6: [generic]
6: [generic] [armv7_a]
6: >>> gr_fir_fff: using armv7_a
6: >>> gr_fir_ccf: using armv7_a
6:
…F…
6:
6/222 Test #6: gr-core-test-all …***Failed 44.44
sec

So what is the real error here?

Thanks,
Tim

On Thu, Apr 18, 2013 at 12:55 PM, Monahan-Mitchell, Tim
[email protected] wrote:

wrong.
Philip

6: Testing gr_vmcircbuf_mmap_tmpfile_factory…
6: Error: gr_block_executor: propagation_policy ‘ONE-TO-ONE’ requires ninputs ==
noutputs
6/222 Test #6: gr-core-test-all …***Failed 44.44 sec

So what is the real error here?

Thanks,
Tim

Tim,

You can find out which error is failing by looking at the output xml
file from the tests here:
gnuradio-core/src/tests/.unittests/gnuradio_core_all.xml

Tom

The circular buffer allocator chooses form about three different ways of
setting up the buffer. The shm version does not work on ARM.

The circular buffer is going to become more and more painful as we try
to do cool stuff with Zynq.

That is all.

Philip

On Tue, Aug 27, 2013 at 6:43 AM, Philip B.
[email protected]wrote:

The circular buffer is going to become more and more painful as we try
to do cool stuff with Zynq.

Agree. This was a good topic of discussion at the last hackfest in
Virginia, and I expect there will be a presentation or two at GRCON13 on
alternatives when dealing with FPGA and GPU offload architectures.

On 08/27/2013 09:58 AM, Johnathan C. wrote:

In the short term, do you know which buffer allocator GNU Radio prefers
to use? Can we just disable the shm based one?

Philip

OK, so I ran ‘ctest -V’ twice in a row without code changes or building,
and got the
6: … gr_vmcircbuf_createfilemapping_factory: Doesn’t work
6: WARN: test from c++ WARN
6: [generic]

Thanks,
Tim

I’m having similar issues with gnuradio git commit
523a53ac387a699cef4d8e784561cdcaffad39cf as well as 3.7.0. I have run
this
test multiple times (the very first failure was at shmat (2)). Gnuradio
was
natively compiled with gcc 4.6.3 for the ARM Coretex-A9 (Xilinx Zynq)
processor. Now, surprisingly, when running the unit tests under
qemu-user
chroot as described here:

http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=5

it seems to work fine.

Here is a snapshot of running ctest -V -R gr-runtime on the ARM
processor:

========= snip =====
Start 2: gr-runtime-test

2: Test command: /bin/sh
“/root/gnuradio/build/gnuradio-runtime/lib/gr-runtime-test_test.sh”
2: Test timeout computed to be: 9.99988e+06
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::buffer::allocate_buffer: failed to allocate buffer of size 4 KB
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::buffer::allocate_buffer: failed to allocate buffer of size 4 KB
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
2: .E.E.E.E…NOTICE: test from c++ NOTICE
2: DEBUG: test from c++ DEBUG
2: INFO: test from c++ INFO
2: WARN: test from c++ WARN
2: ERROR: test from c++ ERROR
2: FATAL: test from c++ FATAL
2: Testing gr::vmcircbuf_createfilemapping_factory…
2: vmcircbuf_createfilemapping: createfilemapping is not available
2: … gr::vmcircbuf_createfilemapping_factory: Doesn’t work
2: Testing gr::vmcircbuf_sysv_shm_factory…
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: gr::vmcircbuf_sysv_shm: shmat (3): Invalid argument
2: … gr::vmcircbuf_sysv_shm_factory: Doesn’t work
2: Testing gr::vmcircbuf_mmap_shm_open_factory…
2: … gr::vmcircbuf_mmap_shm_open_factory: OK
2: Testing gr::vmcircbuf_mmap_tmpfile_factory…
2: … gr::vmcircbuf_mmap_tmpfile_factory: OK
2: …
2:
1/1 Test #2: gr-runtime-test …***Failed 25.73 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 25.98 sec

The following tests FAILED:
2 - gr-runtime-test (Failed)
Errors while running CTest

Regards

  • Stephan


View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ARM-gr-vmcircbuf-sysv-shm-shmat-3-Invalid-argument-tp40870p43349.html
Sent from the GnuRadio mailing list archive at Nabble.com.

You can override it in the ~/.gnuradio/prefs/vmcircbuf_default_factory file.

Thanks for the input, I can override with:

gr::vmcircbuf_mmap_shm_open_factory
or
gr::vmcircbuf_mmap_tmpfile_factory

and now things seem to work. I believe I know what happened though - the
very first time I compiled gnuradio, it was in the qemu user
environment,
where gr::vmcircbuf_sysv_shm passed, this then was added to the
~/.gnuradio/prefs/vmcircbuf_default_factory file. I then NFS mount this
stuff to the Zynq processor (where sysv_shm doesn’t work). The key is to
either remove ~/.gnuradio when switching between qemu (emulated
environment) and the real deal, or to override the
vmcircbuf_default_factory file.

Cheers

  • Stephan

On Tue, Aug 27, 2013 at 07:41:33AM -0700, Tom R.-2 [via GnuRadio]
wrote:

Though it’s supposed to test to see if your system can handle the
Discuss-gnuradio mailing list
To unsubscribe from gnuradio on ARM: gr_vmcircbuf_sysv_shm: shmat (3): Invalid
argument, visit
http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=40870&code=c3RlcGhhbi5lc3Rlcmh1aXplbkBqcGwubmFzYS5nb3Z8NDA4NzB8LTEzNzQ1Mzk5Mjg=


Stephan Esterhuizen

GPS Systems Group
NASA/Jet Propulsion Lab
California Institute of Technology

4800 Oak Grove Drive
M/S: 138-212
Pasadena, CA 91109-8099

818-354-5942 [Office]
626-319-4871 [Mobile]
818-393-5115 [Fax]

On Tue, Aug 27, 2013 at 10:15 AM, Philip B. [email protected]
wrote:

alternatives when dealing with FPGA and GPU offload architectures.

In the short term, do you know which buffer allocator GNU Radio prefers
to use? Can we just disable the shm based one?

Philip

You can override it in the ~/.gnuradio/prefs/vmcircbuf_default_factory
file.

Just put in there the line (with no newline):

gr::vmcircbuf_createfilemapping_factory

And that will tell the system to use that method of managing the
circular buffers.

Though it’s supposed to test to see if your system can handle the
shared memory method first before setting this prefs file. So I guess
there’s something different on the ARM that’s not being tested for
compliance here.


Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

On Tue, Aug 27, 2013 at 1:51 PM, esterhui
[email protected] wrote:

and now things seem to work. I believe I know what happened though - the
Great!

  • Stephan
    Ah, that makes sense. Glad you got things working in your environment.


Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13