Debye efficiency (macOS) #2882

klytje · 2024-05-10T15:14:08Z

Test branch for MacOS support of the external AUSAXS library.

lucas-wilkins · 2024-05-10T15:34:25Z

Seems like its not finding it!

lucas-wilkins · 2024-05-10T15:34:52Z

I'll be in the office for a little while longer if there's something you need doing.

klytje · 2024-05-10T17:42:54Z

I think it's working - we didn't mark our new release as the latest, so on the first run the tests were still using the old library. I forgot we have two different actions running, one for pull_request and another for push, so I accidentally only requested a rerun of the former after fixing the issue.

Edit: Yep, everything's passing. @wpotrzebowski can you check the new installer from here?

wpotrzebowski · 2024-05-14T10:30:12Z

@klytje: sorry for the slow reply. It seems to be crashing on my machine.

butlerpd · 2024-05-14T16:30:25Z

Question: is that possibly a chip issue? I think different macs can use very different chips?

Also out of curiosity: does it really crash? I see Mac saying it crashed and offering to kill the program but "ignore" is also an option and looking at the log explorer it looks like SasView caught the crash of ausaxs and fell back to the old method and is just taking a very long time (9% of that calculation at the time of the screenshot)? If one hits ignore does it continue? If so and it is difficult to have it not crash on some chips/platforms it might be good to capture the failure better so that the user does not see the crash warning but just the log explorer popping up saying we could not use it falling back to slow method?

klytje · 2024-05-14T17:19:27Z

Question: is that possibly a chip issue?

Perhaps? Depends on the kind of optimizations Clang decided to use when @lucas-wilkins compiled it. I'll have to research how to specify what it can and cannot use; it's not obvious to me how to do this with universal binaries like this. The current implementation hides the actual crash message; I'll have to change this to debug further.

Also out of curiosity: does it really crash?

A new process is spawned to 'test-run' my library, which indeed did fatally crash. Perhaps the OS is picking up on this and offering to kill the rest of the program as well? Such a popup is not ideal, to say the least. I'm not sure how to get rid of it. When I tested with Linux & Windows, neither of them seemed to care about the crashing process.

If one hits ignore does it continue?

It should recover just fine - that's why we use a new process to test-run it. Any crash, no matter how severe, will not affect the main process which is thus free to continue. As you pointed out it seems to already have started the calculation using the built-in GSC.

If so and it is difficult to have it not crash on some chips/platforms it might be good to capture the failure better so that the user does not see the crash warning

That's how it's supposed to work (and how it does work on both Windows & Linux), but MacOS seems to have picked up on the crashing child process and decided to intervene all on its own.

krzywon · 2024-05-17T14:40:13Z

As another data point, I see the same error as @wpotrzebowski. I am running an M2 processor. Attached is the MacOS crash report which might help you debug the issue.
sasview-2024-05-14-134817.txt

klytje · 2024-05-22T11:29:28Z

@wpotrzebowski Can you test this artifact with this script? Should be easier to debug through this than the sasview installers.

wpotrzebowski · 2024-05-22T11:37:25Z

@klytje sure!
It seems to work ok

python test_shared_lib.py .
AUSAXS: Started evaluating Debye equation.
OK

klytje · 2024-05-22T11:42:04Z

@wpotrzebowski That's odd. I didn't change anything compared to when Lucas compiled it. What happens if you use this library with sasview? It should go in the src/sas/sascalc/calculator/ausaxs/lib folder.

wpotrzebowski · 2024-05-22T12:21:07Z

Hmm, it doesn't work with just swapping lib files for the app from the installer. (Mac security-keeper is not happy about replacing files in the signed executable). I need to think if I can test it differently. We probably can disable signing for this PR (it doesn't work for the moment anyway).

klytje · 2024-05-22T12:25:45Z

I don't think you need an actual installer, you should be able to use it through the run.py script as long as the library is in the correct folder

wpotrzebowski · 2024-05-22T12:35:21Z

I don't think you need an actual installer, you should be able to use it through the run.py script as long as the library is in the correct folder

This is how I made it work before (with the library compiled on my machine), so I know this approach works but indeed it may be worth trying with external one.

wpotrzebowski · 2024-05-22T12:43:21Z

I don't think you need an actual installer, you should be able to use it through the run.py script as long as the library is in the correct folder

This is how I made it work before (with the library compiled on my machine), so I know this approach works but indeed it may be worth trying with external one.

Yes, this works but I had to allow in security settings to run it.

klytje · 2024-05-22T12:47:53Z

@wpotrzebowski I wonder why you didn't get this warning when you were running my testscript? They hook into the library in the exact same way. Could this be related to why it doesn't work in the installer?

If we fix the signing problem I can try compiling a new installer using this version of the library since we know it should work.

wpotrzebowski · 2024-05-22T12:54:28Z

@klytje I don't think this is the reason. The signing script goes through the entire bundle and signs everything (I can probably check if your lib has been signed properly). I had to allow running your lib as it was downloaded from the Internet.

wpotrzebowski · 2024-05-22T12:55:26Z

But disabling signing completely may help understand it. I will try to do it in the evening.

klytje · 2024-05-22T13:09:28Z

@wpotrzebowski I updated the Releases so all new installer runs should include the new library version.

klytje · 2024-05-22T19:52:55Z

Ah - the failing tests is my mistake. I recently changed the distance binning width from 0.1Å to 0.25Å, but this is apparently not good enough for the highly ordered diamond structure we're testing with. I'll fix this in the next version.

wpotrzebowski · 2024-05-22T20:05:07Z

Without signing it returns the same error as for the signed package.

wpotrzebowski · 2024-05-22T20:14:26Z

I´ve run test script on the library from the installer. Maybe this tells you something

 python test_shared_lib.py /Volumes/SasView6/SasView6.app/Contents/Frameworks/sas/sascalc/calculator/ausaxs
Traceback (most recent call last):
  File "/Users/wojciechpotrzebowski/Downloads/macos-latest-binaries/test_shared_lib.py", line 38, in <module>
    ausaxs = ct.CDLL(str(path))
             ^^^^^^^^^^^^^^^^^^
  File "/Users/wojciechpotrzebowski/miniconda3/envs/sasview_dev/lib/python3.11/ctypes/__init__.py", line 376, in __init__
    self._handle = _dlopen(self._name, mode)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: dlopen(/Volumes/SasView6/SasView6.app/Contents/Frameworks/sas/sascalc/calculator/ausaxs/lib/libausaxs.dylib, 0x0006): tried: '/Volumes/SasView6/SasView6.app/Contents/Frameworks/sas/sascalc/calculator/ausaxs/lib/libausaxs.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/System/Volumes/Preboot/Cryptexes/OS/Volumes/SasView6/SasView6.app/Contents/Frameworks/sas/sascalc/calculator/ausaxs/lib/libausaxs.dylib' (no such file), '/Volumes/SasView6/SasView6.app/Contents/Frameworks/sas/sascalc/calculator/ausaxs/lib/libausaxs.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))

klytje · 2024-05-22T20:21:22Z

I´ve run test script on the library from the installer. Maybe this tells you something

Can you run file libausaxs.dylib for me?

wpotrzebowski · 2024-05-22T20:30:27Z

I´ve run test script on the library from the installer. Maybe this tells you something

Can you run file libausaxs.dylib for me?

file /Volumes/SasView6/SasView6.app/Contents/Frameworks/sas/sascalc/calculator/ausaxs/lib/libausaxs.dylib
/Volumes/SasView6/SasView6.app/Contents/Frameworks/sas/sascalc/calculator/ausaxs/lib/libausaxs.dylib: Mach-O 64-bit dynamically linked shared library arm64

klytje · 2024-05-22T20:34:31Z

Can you verify that the uncompressed library has both x86_64 and arm64? This is what my GitHub runner tells me after compilation:

 build/lib/libausaxs.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]

wpotrzebowski · 2024-05-23T03:50:10Z

Can you verify that the uncompressed library has both x86_64 and arm64? This is what my GitHub runner tells me after compilation:
 build/lib/libausaxs.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]

@klytje: What do you mean by uncompressed library?

klytje · 2024-05-23T07:16:55Z

@wpotrzebowski The library artifact you downloaded from my repo.

I've read through the PyInstaller docs. Three observations:

PyInstaller has the ability to trim multi-arch binaries to only a single arch. I am sure this is what must be happening. I don't know why it is removing the wrong arch, though.
PyInstaller has a binary section where you're supposed to put binaries. I moved the library there. Previously it was in the data section. Can you try using the latest installer with this change?
PyInstaller defaults to building for the architecture of the host machine unless otherwise specified. The macos-latest runners are all arm64, which explains why SasView is looking for that version of my library. But wouldn't this mean that the installer will not work with older Intel MacOS machines?

wpotrzebowski · 2024-05-23T07:38:54Z

For uncompressed

file libausaxs.dylib 
libausaxs.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
libausaxs.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
libausaxs.dylib (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

klytje · 2024-05-23T07:52:14Z

Actually after checking your previous comments again, I am even more confused. The installer is definitely building for arm64 (from CI output):

So PyInstaller seems to be doing it right, trimming away the x86_64 version of my library (your earlier file output):
libausaxs.dylib: Mach-O 64-bit dynamically linked shared library arm64

But then at runtime, your system seems to be running SasView as x86_64? That's the library architecture it is looking for, anyway (from your earlier debugging output):
OSError: dlopen [...] libausaxs.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')

I don't understand how this is possible? How can an arm64 program be running in x86_64 mode?

klytje · 2024-05-23T08:05:42Z

Could this perhaps be due to the way an external Python process is spawned?

The first time we try to hook into my library, we do it from a spawned child process to avoid propagating crashes. But this spawns a fresh Python interpreter process. What would happen if you only have x86_64 Python installed on your system, but the process is spawned from an arm64 program?

Edit: I think we can test this by skipping the safety feature and just directly hooking into my library from the main process. @wpotrzebowski please try the new installer when you have time :)

wpotrzebowski · 2024-05-23T11:42:43Z

The latest installer crashes silently.

klytje · 2024-09-09T09:08:45Z

@krzywon can you maybe give the latest installers a try since Wojciech is not available? Just try to run the generic calculator and see if it crashes

krzywon · 2024-09-09T15:06:50Z

Thanks for the update, @klytje. I'll give it a try sometime this week.

krzywon · 2024-09-13T13:55:58Z

I was able to test the latest build this morning. Unfortunately, I am still seeing the error pop up saying SasView stopped, but I also only see a single MacOS build. I am going to update this branch to the latest release to see if we can have parallel builds.

klytje · 2024-09-13T14:01:13Z

I was able to test the latest build this morning. Unfortunately, I am still seeing the error pop up saying SasView stopped, but I also only see a single MacOS build. I am going to update this branch to the latest release to see if we can have parallel builds.

It should already have been parallel builds? Anyway, if it's still crashing, I don't think we can get around waiting for the macbook to be shipped so I can do some proper debugging.

krzywon · 2024-09-16T17:22:01Z

It should already have been parallel builds? Anyway, if it's still crashing, I don't think we can get around waiting for the macbook to be shipped so I can do some proper debugging.

I reran the build so the parallel builds were actually created. I just tested the MacOS latest build and am still seeing the error when running the debye calculation. @rozyczko - any news on the MacBook?

klytje · 2024-10-22T08:34:41Z

@krzywon or @wpotrzebowski Can you try again but running SasView from the terminal? I.e. navigating to the downloaded build and running ./SasView6.app/Contents/MacOS/sasview ? I have a suspicion of what might be going wrong.

klytje · 2024-10-22T15:31:58Z

I recompiled my own library to no longer automatically create a /temp folder on startup, and recompiled SasView to use this updated version. This seems to have fixed the crashing on my intel mac even when running the app directly. Can someone check if it also works on arm?

krzywon · 2024-10-22T16:47:36Z

I was able to test this on my arm based Mac and the error message is no longer present when running any of the calculations.

klytje · 2024-10-23T17:26:10Z

Latest build confirmed working on all three platforms. I think this is ready for testing & review.

krzywon · 2024-10-23T18:54:58Z

As noted in an email conversation, we are holding this for the next release.

wpotrzebowski · 2024-10-24T04:01:40Z

Tested functionality on arm Mac and indeed it seems to work!

krzywon

After some thought, having this in the release would be useful for Mac users. Approved

Merge branch 'release_6.0.0' into mac_test

0b54303

klytje added 9 commits October 21, 2024 15:49

fixed ausaxs filename bug

b83c074

missing assign

6ac7d56

update

125ca72

bugfix

8ede875

updaet

60be519

more debug info

2e0a24d

disabled other builds

2a5524d

compile w. universal

9359b1a

trigger recompile

3c8fe18

recompile

3bf1d50

relaxed maximum deviation allowed in tests

665ba0c

klytje added 3 commits October 22, 2024 20:36

reverted unnecessary changes

07b68b9

reverted matrix

82af689

Merge branch 'release_6.0.0' into mac_test

2efaab9

klytje marked this pull request as ready for review October 23, 2024 17:27

krzywon approved these changes Oct 24, 2024

View reviewed changes

krzywon merged commit fb5d45c into release_6.0.0 Oct 24, 2024
40 checks passed

krzywon deleted the mac_test branch October 24, 2024 15:33

Debye efficiency (macOS) #2882

Debye efficiency (macOS) #2882

Conversation

klytje commented May 10, 2024

lucas-wilkins commented May 10, 2024

lucas-wilkins commented May 10, 2024

klytje commented May 10, 2024 • edited Loading

wpotrzebowski commented May 14, 2024

butlerpd commented May 14, 2024

klytje commented May 14, 2024 • edited Loading

krzywon commented May 17, 2024

klytje commented May 22, 2024

wpotrzebowski commented May 22, 2024

klytje commented May 22, 2024

wpotrzebowski commented May 22, 2024

klytje commented May 22, 2024

wpotrzebowski commented May 22, 2024

wpotrzebowski commented May 22, 2024

klytje commented May 22, 2024 • edited Loading

wpotrzebowski commented May 22, 2024

wpotrzebowski commented May 22, 2024

klytje commented May 22, 2024

klytje commented May 22, 2024

wpotrzebowski commented May 22, 2024

wpotrzebowski commented May 22, 2024

klytje commented May 22, 2024

wpotrzebowski commented May 22, 2024

klytje commented May 22, 2024 • edited Loading

wpotrzebowski commented May 23, 2024

klytje commented May 23, 2024 • edited Loading

wpotrzebowski commented May 23, 2024

klytje commented May 23, 2024 • edited Loading

klytje commented May 23, 2024 • edited Loading

wpotrzebowski commented May 23, 2024

klytje commented Sep 9, 2024

krzywon commented Sep 9, 2024

krzywon commented Sep 13, 2024

klytje commented Sep 13, 2024

krzywon commented Sep 16, 2024

klytje commented Oct 22, 2024

klytje commented Oct 22, 2024

krzywon commented Oct 22, 2024

klytje commented Oct 23, 2024 • edited Loading

krzywon commented Oct 23, 2024

wpotrzebowski commented Oct 24, 2024

krzywon left a comment

Choose a reason for hiding this comment

klytje commented May 10, 2024 •

edited

Loading

klytje commented May 14, 2024 •

edited

Loading

klytje commented May 22, 2024 •

edited

Loading

klytje commented May 22, 2024 •

edited

Loading

klytje commented May 23, 2024 •

edited

Loading

klytje commented May 23, 2024 •

edited

Loading

klytje commented May 23, 2024 •

edited

Loading

klytje commented Oct 23, 2024 •

edited

Loading