[UHD Python API] Error in macOS 15.0: pointer being freed was not allocated #778
Comments
doctormin
changed the title
doctormin
changed the title
|
I experience the same issue on MacOS 15.1:
|
|
Same issue here, macOS 15.1 Apple silicon, radioconda installation.
gqrx is here: https://github.com/gqrx-sdr/gqrx |
|
Thanks, @doctormin , @rchmielarz , @kgarrels for reporting the issue. For further analysis, could you please
|
|
|
Interesting to see that the |
|
would you expect different results than for gqrx? In gqrx, uhd is called from gr-osmosdr, probably no python involved. I can try the example, needs some time... |
If UHD is built as part of gqrx (I have not checked if it is) then you are right - then the assumption would be that the UHD examples (built using cmake) also work. You mentioned that with Xcode it crashes. What do you mean? Did you build gqrx using Xcode? If this is the case then this would be an indication that somehow the build using Xcode is causing the problem. Then it would be interesting to see if the UHD examples built using Xcode show the issue. |
|
Yes, I create the Xcode project with cmake -G Xcode .. , I found no difference in the cmake logs. It could well be that we have two different things - I was very surprised to see the python example delivers the same error messages. I will try the examples, and send a picture of the Xcode behaviour. |
|
libuhd is linked dynamically. I did not manage to build the examples yet, but radioconda has them installed: I connected my B200: |
|
crash with Xcode: no crash with cmake: weird. |
|
@kgarrels Hey Kai! Long time ... hope you're doing well. I finally got a demo working for a conference in a week (whew!) & am jumping to a few macOS issues of recent including this one. For macOS 15.1.1 and current miniconda, can you list the versions like the author did above? IDK if that's helpful yet ... I've never used conda (any of them), so trying to come up to speed on it alongside Brew and MacPorts & also seeing if macOS provides enough dependencies to do a general build |
|
Catching up here ... by default there is no "uhd" in miniconda ... one has to go to radioconda to find the SDR projects like UHD & GNU Radio & others |
|
UHD installs a SO in the Python directory ... for me it is |
|
FYI the basic UHD install in miniconda was really easy ... clearly there is some work to do on the Python API for macOS still ... |
|
Hi, this issue persists in the latest version: |
Hi Michael @michaelld, thank you for paying attention to this issue! By the way, the |
Wow, nice to meet you again! All good here! What demo, which conference? Just curious :-)
I dropped macports some time ago, it seems gnuradio was not getting updates, maybe I just didn't understand it. The bug start after I upgraded macos 14.x to 15.1. I think we should forget the Xcode problem for now, that thing is just too complicated to understand. otool: Here is my version listing: |
|
@kgarrels I've never been to UE gnuradio days; would love to go some day. Ettus/NI/Emerson has folks in Germany & I think some of them go since they are much closer. I'm heading to AOC'24 Dec 9-13 to give the demos showing off the X440 phase coherence & 1.6 GHz IBW (2 GS/s). This demo was created a couple years ago & I've inherited it; had to reverse engineer lots of things on how it both works and is used. Glad to have success. with 1 week to go!
@kgarrels @doctormin I have never used miniconda or miniforge;l trying the minimum of the former to be able to do debugging (I will also try MacPorts for diversity sake). I'm guessing the error I see if the same as y'all are seeing, regardless of how UHD was installed ... Python crashes when one issues "import uhd" with some sort of memory access issue. I ran "lldb python3.12", then "run", then "import uhd" and here's what I see: ... which is not hugely informative unfortunately without debugging symbols. I'd be curious if y'all see the same. In the past (when I was active in MacPorts -- I've not been active for coming up 2 years, which is why the GNU Radio & related ports have not been updated very much) there were 2 primary issues to get UHD working with Python: (1) make sure the library dependencies daisy-chained correctly ... for example IIRC removing the Python library from the .SO being loaded because one is already in Python and trying to reload the library caused DYLD issues; (2) make sure the same libraries and includes -- both installed dependencies as well as system ones -- are from the same source ... for example sometimes CMake would use Apple Python headers but port libraries or vice versa, some sort of mix-and-match, which is never a good thing. I wonder here whether the issue is that the Python is built using "Clang 14.0.6" whereas we're using "Clang 16.0.0" (or 16.0.6; doesn't really matter) for UHD. While the Clang libraries will be similar between versions, they will be different in subtle ways & those could be enough to throw things off. Is there a way to force Python to be built from source in conda or mamba? That would be worth a try. Let' keep at it & eventually we'll figure this out! |
|
2GS/s sounds like fun :-) I think conda's packages are always pre-built, I could remove single packages and try to build them locally, but where to start, uhd? Then I would need some help... What can we learn from the otool results? |
|
yes 2 GS/s is fun! The X440 is a pretty amazing radio! Unless one uses bursts of data then it takes quite a beastly server to receive that data stream even on 1 channel ... the X440 supports 2 (either direction for either stream), which is even more fun. Next up will be adding in 1 or 2 GPUs to see if we can stream to them & then they do real-time processing on the data. Need some beefy GPUs! I seem to remember reading about Conda/Samba that Apple Silicon support was experimental ... am i misremembering? I'm using MacPorts to build everything from source & seeing if that install works. If that works I'll store those & change the install to be from pre-built binary.
I'm guessing the line you note is a local build directory ( |
|
I think conda/mamba are released, https://docs.conda.io/projects/conda/en/latest/ |
|
In the issue Jörg notes on conda-forge, Ryan notes that his UHD feedstock is up to date & even rebuilt it just in case. Following the instructions provided I added this channel to my miniconda install & then installed UHD through it. This updated the Python 3..12 install & now the compilers match for Python and UHD (Clang 16.0.6), and "import uhd" works. This reinforces my belief that the issue is compiler mismatch. I also built UHD 4.7 release in MacPorts & it works fine all around. I don't know enough about conda/mamba/forge to tell people how to resolve this issue, but it's very unlikely to be an issue with UHD. |
|
@doctormin @kgarrels As mentioned by @michaelld , there is a new build of uhd available in conda-forge (date: 12/03/2024) which is supposed to solve the issue. Please check and confirm. |
|
Thanks! I've upgraded to the newest build of Unfortunately, this issue persists. |
That's a pity. However, as we learned that this issue is conda-specific, I suggest to continue the discussion here: conda-forge/uhd-feedstock#59 @doctormin Would you mind copying your latest findings there? |
|
Sure :) |
Issue Description
I have been successfully using the UHD Python API with USRP devices on macOS. However, recently, after upgrading to the macOS 15.0 developer beta system, my UHD API returns an error when running the following line of code:
uhd/host/python/uhd/usrp/multi_usrp.py
Line 36 in a5ed187
The error is as follows:
Setup Details
Host OS: macOS 15.0
Python: 3.12.4
UHD: 4.7.0.0-release
ENV setup:
I used miniforge to install gnuradio from conda-forge, which automatically installs Python and UHD. For example, I am currently using the latest version:
Suspecting this bug might be related to the versions of Python and UHD, I tried the following:
mamba install gnuradio=3.10.7(UHD=4.5.0.0, Python=3.11.9)but encountered the same error.
Steps to reproduce the problem
mamba create -n <env_name>mamba activate <env_name>mamba install gnuradioThis error will emerge:
The text was updated successfully, but these errors were encountered: