Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The app is crashing no matter what #159

Open
TomerGamerTV opened this issue Jan 14, 2022 · 15 comments
Open

The app is crashing no matter what #159

TomerGamerTV opened this issue Jan 14, 2022 · 15 comments
Assignees
Labels
waiting for reply Awaiting for feedback from user/reporter

Comments

@TomerGamerTV
Copy link

no matter how much time i click the exe file/reinstall it or disable the antivirus it just doesn't work.

i tried running the same installer in a sandbox and it somehow worked, i dont understand what is the problem

@KiraSokolov
Copy link

Same on Mac

@raspher
Copy link

raspher commented Mar 18, 2022

Fedora 35 works normally, at least freshly installed

@user334
Copy link

user334 commented Jul 26, 2022

Same here: app instantly closes without any window appearing. And there's no way to get it running.
Freshly installed on Maos 12.4 on an Intel MBP, tried the latest 1.8.1 and 1.8.0 versions

@DEgITx
Copy link
Owner

DEgITx commented Aug 24, 2022

Guys can you reckec on MacOS?

@DEgITx DEgITx added the waiting for reply Awaiting for feedback from user/reporter label Aug 24, 2022
@user334
Copy link

user334 commented Aug 29, 2022

Hey @DEgITx!
Sorry for a bit delayed reply.
I have just tested the latest 1.9.0 version on macOS 12.5.1 and sadly nothing has changed: the app instantly closes after an opening.

CleanShot.2022-08-28.at.13.55.20.mp4

@user334
Copy link

user334 commented Sep 22, 2022

Hey @DEgITx!
Any news?
I've just tested the latest 1.9.0 on a latest macOS 12.6 and sadly nothing has changed so far -- the app closes the moment I open it.
I found some macOS builtin app called "Console" which has some logs for app crashes, I suppose (newbie in a modern macOS world here). I see there appears a new one each time I try to open your app. So I'm attaching an example of this log of the crash.
searchd-2022-09-22-134839.ips.zip
Hope it helps!
Regards, Anton

@DEgITx
Copy link
Owner

DEgITx commented Nov 28, 2022

Can you please clarify arch of the mac os version. If it arm64, there is still no support, but planned.

@user334
Copy link

user334 commented Nov 28, 2022

Hi @DEgITx!
All of my previous reports here were about an Intel-based macs and therefore about an x86-64 versions of OS. Now I'm on arm version but for some time I can still perform a test on an Intel-based mac.

@user334
Copy link

user334 commented Dec 6, 2022

I've just tried to run this program again on a Intel-based mac and macOS 13 and it still crashes. Here's crashlogs

There are this lines:

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib
Referenced from: <B15AF09F-0BA7-310D-BBC3-79C3182C6747> /Applications/Rats on The Boat.app/Contents/MacOS/searchd
Reason: tried: '/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib' (no such file), '/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib' (no such file), '/usr/local/lib/libssl.1.1.dylib' (no such file), '/usr/lib/libssl.1.1.dylib' (no such file, not in dyld cache)
(terminated at launch; ignore backtrace)

After that I've tried on an arm-based mac and it also crashes with the same message.
Hope it helps.

@TuTAH1
Copy link

TuTAH1 commented Mar 1, 2023

I tryed to open it in Windows, but it closes immideatly, without even showing the interface. I can only see in the task manager, that the Rats process is appears and disappears in a moment.

@DEgITx
Copy link
Owner

DEgITx commented Mar 1, 2023

@TuTAH1 please create new issue and attach rats.log from appdata folder

@user334
Copy link

user334 commented Mar 2, 2023

Hey @DEgITx
I've just tried to run the latest 1.10.0 on an arm64 mac with macos 13.2.1 and the result is still the same - the program closes almost instantly without showing any windows. Here are the logs: rats_on_the_boat_1.10_crash_logs.zip

@FernandoMiguel
Copy link

./Rats\ on\ The\ Boat
[6/24/2023 10:58:50 AM] [system] Rats 1.11.0
[6/24/2023 10:58:50 AM] [system] Platform: darwin
[6/24/2023 10:58:50 AM] [system] Arch: x64
[6/24/2023 10:58:50 AM] [system] OS Release: 22.6.0
[6/24/2023 10:58:50 AM] [system] CPU: Apple M1 Pro
[6/24/2023 10:58:50 AM] [system] CPU Logic cores: 10
[6/24/2023 10:58:50 AM] [system] Total memory: 32768.00 MB
[6/24/2023 10:58:50 AM] [system] Free memory: 518.45 MB
[6/24/2023 10:58:50 AM] [system] NodeJS: v18.14.0
[6/24/2023 10:58:50 AM] [system] Desktop server
(node:83064) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `Rats on The Boat --trace-deprecation ...` to show where the warning was created)
[6/24/2023 10:58:50 AM] [udp-tracker] listening udp tracker respose on 0.0.0.0:4446
[6/24/2023 10:58:50 AM] [sphinx] Sphinx Path: /Applications/Rats on The Boat.app/Contents/MacOS/x64/searchd
[6/24/2023 10:58:50 AM] [sphinx] writed sphinx config to /Users/x/Library/Application Support/Rats on The Boat
[6/24/2023 10:58:50 AM] [sphinx] db path: /Users/fernando/Library/Application Support/Rats on The Boat
[6/24/2023 10:58:51 AM] [sphinx] sphinx closed with code null and signal SIGABRT
[6/24/2023 10:58:51 AM] [sphinx] sphinx closing...
[6/24/2023 10:58:51 AM] [sphinx] stoping with sphinx stopwait

@user334
Copy link

user334 commented Jun 27, 2023

New comment here - new try to run this app on a newer macOS :D
But now with a result!

For whatever reason this app tries to run x86-64 version of the included binaries by default even despite there are arm versions lying nearby already. And any such a run results in the instant app crash with the message in the log which is shown above and the couple of messages in an internal macOS' app "Console" with that error:

Process:               searchd [12623]
Path:                  /Applications/Rats on The Boat.app/Contents/MacOS/x64/searchd
Identifier:            searchd
Version:               ???
Code Type:             X86-64 (Translated)
Parent Process:        Rats on The Boat [12613]
Responsible:           Rats on The Boat [12613]

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: /usr/local/opt/openssl@3/lib/libssl.3.dylib
Referenced from: <4C4C447D-5555-3144-A1BC-FCBDE62A79D4> /Applications/Rats on The Boat.app/Contents/MacOS/x64/searchd
Reason: tried: '/usr/local/opt/openssl@3/lib/libssl.3.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/openssl@3/lib/libssl.3.dylib' (no such file), '/usr/local/opt/openssl@3/lib/libssl.3.dylib' (no such file), '/usr/local/lib/libssl.3.dylib' (no such file), '/usr/lib/libssl.3.dylib' (no such file, not in dyld cache)
(terminated at launch; ignore backtrace)

I've tried to mask those x64 binaries for app to not to use them by simply renaming the corresponding folder but the app throws an 'ENOENT' error to me which means it can't find a file\folder and thus can't spawn a "searchd" process. And then it just hangs up. No interface and no any other actions from the app occurs. The only way to close it then is the force kill via the "System Monitor" app.

[6/27/2023 6:38:00 PM] [system] Exception: Error: spawn /Users/anton/searchd ENOENT

So it only tries to load files from x64 folder.
Then I've tried to just move arm versions of those binaries from an arm64 folder to an x64 folder and the program crashed again but with a slightly different log:

Process:               searchd [13688]
Path:                  /Applications/Rats on The Boat.app/Contents/MacOS/x64/searchd
Identifier:            searchd
Version:               ???
Code Type:             ARM-64 (Native)
Parent Process:        Rats on The Boat [13683]
Responsible:           Terminal [13648]

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: /opt/homebrew/*/libssl.3.dylib
Referenced from: <4C4C444C-5555-3144-A16F-3AAAC4EEEF00> /Applications/Rats on The Boat.app/Contents/MacOS/x64/searchd
Reason: tried: '/opt/homebrew/*/libssl.3.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/*/libssl.3.dylib' (no such file), '/opt/homebrew/*/libssl.3.dylib' (no such file), '/usr/local/lib/libssl.3.dylib' (no such file), '/usr/lib/libssl.3.dylib' (no such file, not in dyld cache)
(terminated at launch; ignore backtrace)

Sooo... looks like this app desperately wants those libssl.3.dylib library. Let's give it one! :D
IDK whether it should be preincluded in a macOS installation or not but I've found it only inside one of the applications I have installed on my machine. So I've made a hardlink to this libssl.3.dylib file in a '/usr/local/lib' location. And it worked! The app then asked about a 'libcrypto.3.dylib' so I've made same trick with it.
And now this app works perfectly! (I've had to remove all it's userdata to start fresh because it was stuck on an "optimising torrents" step)

To conclude:

  1. This app lacks libssl.3.dylib and libcrypto.3.dylib on macOS. This is the reason of it's crashes and this issue. I suspect they should be included\staticly linked into the package. What I did is a dirty hack just to find a problem.
  2. This app has some arm64 binaries included but it somehow refuses to run them on an M1 machine.

@DEgITx please take a look, hope it helps :)

@user334
Copy link

user334 commented Jun 29, 2023

Regardless my 2-nd conclusion above.
I'm not sure but this may happen because of this check:

try {
if (process.platform === 'darwin' && process.arch === 'arm64' && fs.existsSync(fs.realpathSync(path.join(__dirname, '/../../../MacOS/arm64')) + `/${app}`)) {
return fs.realpathSync(path.join(__dirname, '/../../../MacOS/arm64')) + `/${app}`
}
} catch (e) {}

Since the whole app is an Intel-one and runs under Rosetta I assume the value that Node returns in that check is not arm64 but x86-64. So this check fails and the next check which checks only the platform and not the architecture returns an x64 sub-directory.

I've found this issue in a Node's GH that probably has a solution for that situation: nodejs/node#41900 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting for reply Awaiting for feedback from user/reporter
Projects
None yet
Development

No branches or pull requests

7 participants