search

sandialabs / gr-fhss_utils

Bursty modem utilities
GNU General Public License v3.0
68 stars 27 forks source link

Illegal Instruction #8

Open epgreen opened 3 years ago

epgreen commented 3 years ago

Good evening,

I've reinstalled fhss_utils a few times, but each time that I try to import fhss_utils it says that there was an "Illegal Instruction" and then a "core dump". I'm using Ubuntu 18.04 and GNUradio 3.8. Any help would be appreciated, trying to get gr-iridium to work in the meantime, but the more generalized implementation of a fhss detector/extractor would be beneficial.

samwhiting-snl commented 3 years ago

Could you provide a call trace for the core dump?

Are you using branch maint-3.8 of gr-fhss_utils? That's the most stable right now for GR3.8.

epgreen commented 3 years ago

When running in GRC:

Call trace:

0 0x00007f9b9f05b9d7 in ?? ()

1 0x0000000000000000 in ?? ()

When importing through python:

0 0x00007f9e597599d7 in ?? ()

1 0x0000005d0000006e in ?? ()

2 0x00007f9e58e21ef1 in ?? ()

3 0x0000000002293f98 in ?? ()

4 0x0000000000008ed0 in ?? ()

5 0x00007f9e59778798 in ?? ()

6 0x0000000000000410 in ?? ()

7 0x00000000022a8130 in ?? ()

8 0x00007f9e58e90758 in ?? ()

9 0x0000000000000000 in ?? ()

Is that what you needed?

epgreen commented 3 years ago

This is from using the maint-3.8 gr-fhss_utils. Haven't upgraded to 3.9 yet.

samwhiting-snl commented 3 years ago

Could you re-build the module with debugging symbols and then get a new call trace? You can do this with a cmake flag while in the build directory:

$ cmake .. -DCMAKE_BUILD_TYPE=Debug

This will make the stack trace more readable and should display function names when it prints.

epgreen commented 3 years ago

I'm not exactly sure what happened, but after reinstalling a few times to try to get the call trace output readable it is now importing and not causing the illegal instruction that was happening prior. I'll go through and make sure the actual modules work though

I am running into a constant ">>> Done (return code -4)" though when I run the flowgraph. With no luck of finding out why that's happening or really what that means.

samwhiting-snl commented 3 years ago

Does the gr-fhss_utils module pass make test? There's a modest amount of QA code that should alert you if something is fatally wrong.

If you do get a readable call trace or more details about the error, let me know.

alphafox02 commented 3 years ago

So interestingly enough, after setting up the new gr-smart_meters, which requires gr_fhss 3.8, I actually get the illegal instruction when trying to open the gr-smart meter flow graph. Thing is, I only get the illegal instruction when doing it on an older intel NUC and within a VM. On a normal x64 laptop I have, the flow graph opens.

If I go back to the VM and Nuc and attempt to open for example, GR-RDS and a flow graph from the command line, I can see about 4-5 lines referring to fhss failing to load, but the RDS flow graph does ultimately open. This is why I think I get the illegal instruction on gr-smart_meters because it is directly trying to use gr-fhss. I do not get the illegal instruction if I uninstall gr-fhss and then open the gr-smart meter flow graph, course the gr-fhss blocks are missing.

Running make test on gr-fhss on the nuc does show all failures while on the laptop it’s fine. Even though all three things are x64 based, is there something like cpu capabilities making the difference for gr-fhss? Why would something like GR-RDS spit out errors referring to gr-fhss, is it just that gnuradio tries to load all oot modules? Sorry for the long post. I’ll jump on the NUC and copy/paste the errors ASAP. I just want to help however possible.

cthierman commented 2 years ago

Interesting. I have an old PC x64 that I upgraded over the years from Ubuntu 12.04 to 20.04. And I'm having exactly the same problem as you describe. To the letter. I have a new IntelNuc on order showing up this week.

But I tried re-installing all the components using pybombs, including gr-smartmeters but I still get the "Done (return code -4)" with Gnuradio-companion. All my gr-fhss tests fail. No matter how I complile. And I am using the maint-3.8 version of both gr-fhss_utils and gr-smartmeters.

If I compile it not using pybombs I get the illegal instruction when I try to run the gr-smart_meters/examples/fhss_detector_reference_hackrf.py script and it dies when it hits the import fhss_utils line.

wonder if anyone has any guess as to what might be causing that with an older machine.

uname -a Linux xxx-P5K-VM 5.4.0-104-generic #118-Ubuntu SMP Wed Mar 2 19:02:41 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

alphafox02 commented 2 years ago

I probably would’ve forgotten about this except every time I start up GRC I’m reminded of it, now that you’re seeing the same thing maybe it’ll get more attention. I’m also trying to switch over to Gnuradio 3.10 and will see if the same issue exists when I build gr-smart meters on it.

samwhiting-snl commented 2 years ago

I wonder if this could be related to openmp that is used to multithread the tagged_bursts_to_pdu block.

https://github.com/sandialabs/gr-fhss_utils/blob/master/lib/tagged_burst_to_pdu_impl.cc#L433

Should be pretty easy to remove lines 433-439, 466 and change the call in 478 for the thread number to just be 1 and then recompile. Not sure what else could be throwing an illegal instruction error. I'm guessing it's not volk otherwise you'd be seeing lots of other errors outside of fhss_utils.

AgentDelta007 commented 2 years ago

I was having the issue described here (attempting to import fhss_utils would result in an illegal instruction error and a crash of whatever was trying to use fhss_utils). Running make test would result in all tests failing. This was with the maint-3.8 branch and version 3.8 of GNURadio on an Ubuntu 20.04 VM hosted on a Proxmox machine.

Someone suggested that I change the CPU type for the VM from the default kvm64 to host. Since I've done that, fhss_utils has been working correctly with no additional errors. I'm guessing it's relying on a CPU flag or instruction set that my host CPU (a Core i5-4590) has available that the default kvm64 CPU does not include. I'm not sure what that flag/instruction set is, though.

csm commented 2 years ago

I ran into this issue trying to run this on an Intel Celeron N4020. Running under gdb it seems the invalid instruction is vmovss, which is emitted because lib/CMakeLists.txt sets:

set(CMAKE_CXX_FLAGS "-fopenmp -mavx")

Removing the -mavx flag stopped the illegal instruction for me (GNU Radio 3.9, Ubuntu 20.04).

alphafox02 commented 2 years ago

Awesome, I’ll annotate this and try it as well. Thank you!