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>, argc=argc@entry=2, > argv=argv@entry=0xbefffd64, env=env@entry=0xbefffd70) 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 (main_map=main_map@entry=0x1074500, 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, > objname@entry=0xbefdd32c, errstring=0xbefdd3c0, > errstring@entry=0xbefdd330, mallocedp=0xbefdd32c, > mallocedp@entry=0xbefdd32b, operate=0xbefdd330, > args=args@entry=0xbefdd334) > 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>, > args=args@entry=0xbefdd580) 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 <bloe...@ccs-labs.org > <mailto:bloe...@ccs-labs.org>>: > > 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/ > <http://www.ccs-labs.org/%7Ebloessl/> > >> On 01 Feb 2016, at 08:37, Gabriel Pechiarovich >> <gaps.18.2...@gmail.com <mailto:gaps.18.2...@gmail.com>> 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 <bloe...@ccs-labs.org >> <mailto:bloe...@ccs-labs.org>>: >> >> Hi, >> >> >>> On 29 Jan 2016, at 10:16, Gabriel Pechiarovich >>> <gaps.18.2...@gmail.com <mailto:gaps.18.2...@gmail.com>> 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? >> >>> >>> root@ettus-e300:~/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 >>> root@ettus-e300:~/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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
