Re: [Discuss-gnuradio] SIGSEGV in volk_32fc_x2_multiply_32fc

2016-02-01 15:01 GMT-05:00 Marcus Müller <address@hidden>:

Hi Nathan,

exactly the right lead. I had "GNU Radio something.8" in mind when I asked myself what version Gabriel was using. Scrolling down I figured Gabriel uses /UHD 3.8.something/, which I must have confused with the GNU Radio version.
Gabriel, is it an option to use a more modern SD card image release? Yours, as Nathan explained, has bugs, and is quite dated.

Best regards,
Marcus

On 01.02.2016 20:56, West, Nathan wrote:
On Mon, Feb 1, 2016 at 2:39 PM, Marcus Müller <address@hidden> wrote:

Hi Gabriel,
aha! That's in GNU Radio's multiply block, using libVOLK, so this is something that we might actually hunt down.
I remember there being awareness of a similar error not too long ago, put Philip Balister in CC:; he had a problem with the neonasm implementation of dot product, so he used neon instead.

https://github.com/gnuradio/volk/issues/25#event-351452447

relevant commit for multiply: https://github.com/gnuradio/volk/commit/92a7251bc9b26ab7bd03cd4fbbd6ee2f0c6f3cef

to help me debug this: the output of "volk-config-info -v --all-machines" would be helpful, and also whether "volk_config -b" runs (that will definitely take a while!) without segfault.

You may just be on an 'old' version of volk. If so either upgrade or set volk_config appropriately.
Best regards,
Marcus

On 01.02.2016 20:25, Gabriel Pechiarovich wrote:
After receiving SIGSEGV, i've used backtrace and got this:

Press Enter to quit:

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x9a4ff460 (LWP 3392)]

.tailcase ()

at /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36

36 vld1.32 d0, [r2]! @ s0, s1 = br, bi

(gdb) backtrace

#0 .tailcase ()

at /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36

#1 0xb6992774 in gr::blocks::multiply_cc_impl::work (this=<optimized out>,

noutput_items=4096, input_items=..., output_items=...)

at /usr/src/debug/gnuradio/3.7.7-r0/git/gr-blocks/lib/multiply_cc_impl.cc:60

#2 0x9a4fede4 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb)
2016-02-01 14:18 GMT-05:00 Marcus Müller <address@hidden>:
ah sorry, that was confusing:
after SIGILL, please "continue", untill you get SIGSEGV, then type "backtrace".

Best regards,
Marcus
On 01.02.2016 20:08, Gabriel Pechiarovich wrote:
Hi, this is the full output:

set_min_output_buffer on block 10 to 96000

set_min_output_buffer on block 12 to 96000

set_min_output_buffer on block 14 to 96000

set_min_output_buffer on block 15 to 96000

set_min_output_buffer on block 18 to 96000

set_min_output_buffer on block 29 to 96000

[New Thread 0xa48e5460 (LWP 3255)]

[New Thread 0xa40e5460 (LWP 3256)]

[New Thread 0xa36ff460 (LWP 3258)]

[New Thread 0xa2eff460 (LWP 3257)]

[New Thread 0xa24ff460 (LWP 3259)]

[New Thread 0xa1cff460 (LWP 3260)]

[New Thread 0xa14ff460 (LWP 3261)]

[New Thread 0xa0cff460 (LWP 3262)]

[New Thread 0xa04ff460 (LWP 3263)]

[New Thread 0x9fcff460 (LWP 3264)]

[New Thread 0x9f4ff460 (LWP 3265)]

[New Thread 0x9ecff460 (LWP 3266)]

[New Thread 0x9e4ff460 (LWP 3267)]

[New Thread 0x9dcff460 (LWP 3268)]

[New Thread 0x9d4ff460 (LWP 3269)]

[New Thread 0x9ccff460 (LWP 3270)]

[New Thread 0x9c4ff460 (LWP 3271)]

[New Thread 0x9bcff460 (LWP 3272)]

[New Thread 0x9b4ff460 (LWP 3273)]

[New Thread 0x9acff460 (LWP 3274)]

[New Thread 0x9a4ff460 (LWP 3275)]

[New Thread 0x99cff460 (LWP 3276)]

[New Thread 0x994ff460 (LWP 3277)]

[New Thread 0x98cff460 (LWP 3278)]

[New Thread 0x984ff460 (LWP 3279)]

[New Thread 0x97cff460 (LWP 3280)]

[New Thread 0x974ff460 (LWP 3281)]

[New Thread 0x96cff460 (LWP 3282)]

[New Thread 0x964ff460 (LWP 3283)]

[New Thread 0x95cff460 (LWP 3284)]

[New Thread 0x954ff460 (LWP 3285)]

[New Thread 0x94cff460 (LWP 3286)]

[New Thread 0x944ff460 (LWP 3287)]

[New Thread 0x93cff460 (LWP 3288)]

[New Thread 0x934ff460 (LWP 3289)]

[New Thread 0x92cff460 (LWP 3290)]

[New Thread 0x924ff460 (LWP 3291)]

[New Thread 0x91cff460 (LWP 3292)]

[New Thread 0x914ff460 (LWP 3293)]

[New Thread 0x90cff460 (LWP 3294)]

Press Enter to quit:

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x9a4ff460 (LWP 3275)]

.tailcase ()

at /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36

36 vld1.32 d0, [r2]! @ s0, s1 = br, bi

(gdb) continue

Continuing.

[Thread 0x90cff460 (LWP 3294) exited]

[Thread 0x914ff460 (LWP 3293) exited]

[Thread 0x91cff460 (LWP 3292) exited]

[Thread 0x924ff460 (LWP 3291) exited]

[Thread 0x92cff460 (LWP 3290) exited]

[Thread 0x934ff460 (LWP 3289) exited]

[Thread 0x93cff460 (LWP 3288) exited]

[Thread 0x93cff460 (LWP 3288) exited]

[Thread 0x944ff460 (LWP 3287) exited]

[Thread 0x94cff460 (LWP 3286) exited]

[Thread 0x954ff460 (LWP 3285) exited]

[Thread 0x95cff460 (LWP 3284) exited]

[Thread 0x964ff460 (LWP 3283) exited]

[Thread 0x96cff460 (LWP 3282) exited]

[Thread 0x974ff460 (LWP 3281) exited]

[Thread 0x97cff460 (LWP 3280) exited]

[Thread 0x984ff460 (LWP 3279) exited]

[Thread 0x98cff460 (LWP 3278) exited]

[Thread 0x994ff460 (LWP 3277) exited]

[Thread 0x99cff460 (LWP 3276) exited]

[Thread 0x9a4ff460 (LWP 3275) exited]

[Thread 0x9acff460 (LWP 3274) exited]

[Thread 0x9b4ff460 (LWP 3273) exited]

[Thread 0x9bcff460 (LWP 3272) exited]

[Thread 0x9c4ff460 (LWP 3271) exited]

[Thread 0x9ccff460 (LWP 3270) exited]

[Thread 0x9dcff460 (LWP 3268) exited]

[Thread 0x9e4ff460 (LWP 3267) exited]

[Thread 0x9ecff460 (LWP 3266) exited]

[Thread 0x9f4ff460 (LWP 3265) exited]

[Thread 0x9fcff460 (LWP 3264) exited]

[Thread 0xa04ff460 (LWP 3263) exited]

[Thread 0xa0cff460 (LWP 3262) exited]

[Thread 0xa14ff460 (LWP 3261) exited]

[Thread 0xa1cff460 (LWP 3260) exited]

[Thread 0xa24ff460 (LWP 3259) exited]

[Thread 0xa36ff460 (LWP 3258) exited]

[Thread 0xa2eff460 (LWP 3257) exited]

[Thread 0xa40e5460 (LWP 3256) exited]

[Thread 0xa48e5460 (LWP 3255) exited]

[Thread 0xb6ffa000 (LWP 3244) exited]

Program terminated with signal SIGSEGV, Segmentation fault.

The program no longer exists.

(gdb)
2016-02-01 13:59 GMT-05:00 Marcus Müller <address@hidden>:
Lack of a library wouldn't cause this; what's the "backtrace" output after gdb tells you the program segfaulted?

Best regards,
Marcus
On 01.02.2016 19:57, Gabriel Pechiarovich wrote:
Hi,

as you foretold it actually crashed with SIGSEGV

Program terminated with signal SIGSEGV, Segmentation fault.

This may be a problem with the onboard linux on the E310, maybe lacks something.

Gabriel Pechiarovich
2016-02-01 13:11 GMT-05:00 Marcus Müller <address@hidden>:
Hi Gabriel,

that might actually be part of OpenSSL's CPU feature detection, be caught and handled normally; maybe it's hiding another fault. I assume when you type "continue" on the gdb prompt the program actually crashes with SIGSEGV?

Best regards,
Marcus

On 01.02.2016 18:54, Gabriel Pechiarovich wrote:
Hi
I used the backtrace and got this:

(gdb) run wifi_loopback_ngui.py

Starting program: /usr/bin/python wifi_loopback_ngui.py

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.

_armv7_tick () at armv4cpuid.S:17

17 mrc p15,0,r0,c9,c13,0

(gdb) bt

#0 _armv7_tick () at armv4cpuid.S:17

#1 0xb48238a8 in OPENSSL_cpuid_setup () at armcap.c:75

#2 0xb6fe70d4 in call_init (l=<optimized out>, address@hidden,

address@hidden, address@hidden) at dl-init.c:78

#3 0xb6fe7230 in call_init (env=<optimized out>, argv=<optimized out>,

argc=<optimized out>, l=<optimized out>) at dl-init.c:36

#4 _dl_init (address@hidden, argc=2, argv=0xbefffd64,

env=0xbefffd70) at dl-init.c:126

#5 0xb6febb2c in dl_open_worker (a=<optimized out>) at dl-open.c:566

#6 0xb6fe6f80 in _dl_catch_error (objname=0xb6ffa510,

address@hidden, errstring=0xbefdd3c0,

address@hidden, mallocedp=0xbefdd32c,

address@hidden, operate=0xbefdd330, address@hidden)

at dl-error.c:187

#7 0xb6feb1d0 in _dl_open (

file=0xbefdd86c "/usr/lib/python2.7/lib-dynload/_hashlib.so",

mode=-2147483646, caller_dlopen=0xb6f444a4 <_PyImport_GetDynLoadFunc+324>,

nsid=-2, argc=2, argv=0xbefffd64, env=0xbefffd70) at dl-open.c:650

#8 0xb6cebb9c in dlopen_doit (a=0xbefdd580) at dlopen.c:66

#9 0xb6fe6f80 in _dl_catch_error (objname=0xb6ffa510, errstring=0x0,

mallocedp=0xa91f4, operate=0xa91f8, args=0xbefdd580) at dl-error.c:187

#10 0xb6cec2ac in _dlerror_run (operate=0xb6cebb20 <dlopen_doit>,

address@hidden) at dlerror.c:163

---Type <return> to continue, or q <return> to quit---

I'm not a programer but i can understand some things.

The modifications i've made to the loopback are basicaly changing all the gui

2016-02-01 11:49 GMT-05:00 Bastian Bloessl <address@hidden>:

Hi,

if you don’t have another USRP that works with a PC (like B210 or N210) and really have to get it running on the E310 you should do a backtrace.

It's hard to tell what’s going wrong from just the fact that something segfaults.

Best,

Bastian

--

Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group

University of Paderborn, Germany

http://www.ccs-labs.org/~bloessl/

On 01 Feb 2016, at 08:37, Gabriel Pechiarovich <address@hidden> wrote:

Hi,

I installed the module by coping the files needed to the E310 then I compiled them on the E310, the needed libraries like itpp were downloaded and copied as well.

I've installed in this order (install using cmake make ...): ITPP 4.3.1 gr-foo-master gr-ieee802-11-master

I wanted to run the ieee802 in this device since i cant run it on the USRP1 and i want to see the spectrum with an analyzer, so i can compare with a standard wifi transmitter.

I'm running the third image of the E310.

2016-01-29 14:01 GMT-05:00 Bastian Bloessl <address@hidden>:

Hi,

On 29 Jan 2016, at 10:16, Gabriel Pechiarovich <address@hidden> wrote:

Hi all, I just installed this module in my E310, to run the loopback in the E310 i modified the flow graph so it is no gui, but when i'm running in the E310 i got a segmentation fault and the program stops:

How did you install the module? Did you compile it on the E310?

address@hidden:~/wifi-master# python wifi_loopback_ngui.py

linux; GNU C++ version 4.9.1; Boost_105600; UHD_003.008.005-0-unknown

Using Volk machine: neon_hardfp

OFDM MAPPER: encoding: 0

set_min_output_buffer on block 10 to 96000

set_min_output_buffer on block 12 to 96000

set_min_output_buffer on block 14 to 96000

set_min_output_buffer on block 15 to 96000

Segmentation fault

address@hidden:~/wifi-master#

I think you should try to get a backtrace. I use something like

gdb python

run wifi_loopback.py

<wait for crash>

bt

I need to run at least the loopback

thank you in andvance

If you are interested in simulations only, there is really no need to run them on the E310.

Best,

Bastian

--

Gabriel Pechiarovich Salas
Red Dragon Games

Designers and game developers

--

Gabriel Pechiarovich Salas
Red Dragon Games

Designers and game developers
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--

Gabriel Pechiarovich Salas
Red Dragon Games

Designers and game developers
--

Gabriel Pechiarovich Salas
Red Dragon Games

Designers and game developers
--

Gabriel Pechiarovich Salas
Red Dragon Games

Designers and game developers
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Gabriel Pechiarovich Salas

Red Dragon Games

Designers and game developers

From:	Gabriel Pechiarovich
Subject:	Re: [Discuss-gnuradio] SIGSEGV in volk_32fc_x2_multiply_32fc_neon
Date:	Mon, 1 Feb 2016 15:21:09 -0500

Re: [Discuss-gnuradio] SIGSEGV in volk_32fc_x2_multiply_32fc_neon