Closed erikaking-sh closed 3 years ago
We cannot reproduce the error on our end. However we tried to improve the logging to find the root cause. Could you try the latest beta? It is downloadable via https://beta-downloads.kreya.app/Kreya-macos.zip (checksum is available here: https://beta-downloads.kreya.app/appcast.json).
If the launch fails, logs should be written to ~/.config/Kreya
. If there is no log file written, could you try to set the LogLevel to Information
by setting an environment variable KREYA_LOGGING_LEVEL=Information
.
The failure occurred the same with the new app. It was unable to be opened. There are no logs written. In fact there is no .config file. I set the env variable and it didn't seem to matter. Do I need to place the checksum file somewhere?
Checksum file is not needed by the app, it is available for you to verify the download.
Could you try to launch the app via terminal with the following command (if the kreya app is located in /Applications
): KREYA_LOGGING_LEVEL=Information /Applications/Kreya.app/Contents/MacOS/Kreya.app
. Are there any errors reported to stdout/stderr?
Ok.... I did verify the download. The UI comes up with no issues when running from the command line, but from SpotLight or App Folder. There are no errors reported in stdout/stderr. I did however upload my crash report from the console when it's not working.
I also found a diag report from a previous crash. Kreya.app-DiagReport.txt
I played around with permissions to no avail. That actually made the command line command stop working for a bit.
We released v1.3.1 yesterday, could you please try it again? Preferably both via SpotLight and Console. We improved (among other things) resilience and logging.
The following information would be interesting to us:
~/.config/Kreya
folder exist?Kreya.db
file in there?~/.config/Kreya/kreya.log
file into this issue?Sorry that we couldn't fix this issue yet and thank you for your patience.
PS: To add stack traces and other large contents you can use <details><summary>[Title]</summary>[Contents]</details>
inside github issues. This displays the content in a collapsible which keeps the issue more readable.
Hello, I apologize for the delay. I tried v1.3.1. I have tried it again with the same results. Using Spotlight, there is not ~/.config/Kreya folder. No contents Kreya.db or kreya.log. Here are the contents that I do have.
From the terminal, everything opens up just fine.
Thanks for trying it again and for your patience. We are not really sure what is causing this problem, especially since launching Kreya from a terminal works, but not via Spotlight.
It may be a permission problem, because one of the first things we try to do is to create the kreya.db file... This should usually be placed in ~/.config/Kreya
. If the environment variable $XDG_CONFIG_HOME
is set, could you also check $XDG_CONFIG_HOME/Kreya
for Kreya files?
Are you using the same user when launching via terminal? Since Kreya works via terminal, the kreya.db
and kreya.log
files should be created in one of the two locations. However, if Kreya does not have write permissions, it will crash and no logs will be written.
XDG_CONFIG_HOME is not set. But it is also not set for any members of my team where Kreya works. I am using the same user for all Kreya launches. The file seems to write kreya.db from whatever folder that it is launched.
I think we have found the root cause thanks to your analysis and attempts. The problem is, that if the directory ~/.config
or $XDG_CONFIG_HOME
does not exist, a fallback /.config
is used. Since this fallback directory is not writable, Kreya crashes. The log files cannot be written either, as they are written to the same directory.
The bugfix for this will be included in the next release (instead of the fallback we simply create the directory if it does not exist).
Workaround
A workaround is to create an empty directory .config
in the user home (mkdir ~/.config
) or to ensure the directory $XDG_CONFIG_HOME
exists (if $XDG_CONFIG_HOME
is set, mkdir "$XDG_CONFIG_HOME"
).
Could you let us know if the workaround works for you?
Creating the ~./config seemed to do the trick. Thanks for the support!
Release in Kreya 1.4.
Describe the bug Kreya will not open. Keeps crashing.
To Reproduce Steps to reproduce the behavior:
Expected behavior I expected Kreya application to open.
Screenshots
Environment (if possible, copy the information from the error dialog or the About menu): MacBook Pro 15, Intel i7
System Version: macOS 10.15.7 (19H524)
Kernel Version: Darwin 19.6.0
Kreya Version 1.2.1 (1.2.1)
**Additional context**
Process: Kreya.app [1826] Path: /Applications/Kreya.app/Contents/MacOS/Kreya.app Identifier: app.kreya Version: 1.2.1 (1.2.1) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Kreya.app [1826] User ID: 503 Date/Time: 2021-04-06 12:33:50.580 -0500 OS Version: Mac OS X 10.15.7 (19H524) Report Version: 12 Bridge OS Version: 5.2 (18P4347) Anonymous UUID: 7844325A-441D-E82A-F83A-8B135081BC1F Time Awake Since Boot: 1400 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff67b0333a __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff67bbfe60 pthread_kill + 430 2 libsystem_c.dylib 0x00007fff67a8a808 abort + 120 3 libcoreclr.dylib 0x000000010836292e PROCAbort + 30 4 libcoreclr.dylib 0x0000000107f35847 PROCEndProcess(void*, unsigned int, int) + 215 5 libcoreclr.dylib 0x00000001083653dc UnwindManagedExceptionPass1(PAL_SEHException&, _CONTEXT*) (.cold.1) + 44 6 libcoreclr.dylib 0x00000001081849d6 UnwindManagedExceptionPass1(PAL_SEHException&, _CONTEXT*) + 822 7 libcoreclr.dylib 0x0000000108184a66 DispatchManagedException(PAL_SEHException&, bool) + 134 8 libcoreclr.dylib 0x00000001080e80f4 IL_Throw(Object*) + 548 9 ??? 0x0000000117860f1e 0 + 4689628958 10 ??? 0x0000000117860903 0 + 4689627395 11 ??? 0x000000011785f6ab 0 + 4689622699 12 ??? 0x000000011785ed07 0 + 4689620231 13 ??? 0x000000011785ec5d 0 + 4689620061 14 ??? 0x000000011784976c 0 + 4689532780 15 ??? 0x0000000116d75cd2 0 + 4678180050 16 libcoreclr.dylib 0x00000001082253b9 CallDescrWorkerInternal + 124 17 libcoreclr.dylib 0x000000010807a09f MethodDescCallSite::CallTargetWorker(unsigned long const*, unsigned long*, int) + 1519 18 libcoreclr.dylib 0x0000000107f5577a RunMain(MethodDesc*, short, int*, PtrArray**) + 746 19 libcoreclr.dylib 0x0000000107f55ab3 Assembly::ExecuteMainMethod(PtrArray**, int) + 387 20 libcoreclr.dylib 0x0000000107f9263d CorHost2::ExecuteAssembly(unsigned int, char16_t const*, int, char16_t const**, unsigned int*) + 509 21 libcoreclr.dylib 0x0000000107f3efe2 coreclr_execute_assembly + 242 22 app.kreya 0x0000000107e74763 run_app_for_context(hostpolicy_context_t const&, int, char const**) + 1443 23 app.kreya 0x0000000107e75a6a corehost_main + 234 24 app.kreya 0x0000000107e52ef1 fx_muxer_t::handle_exec_host_command(std::__1::basic_string