wezterm crash when cannot found default_prog without any tips on macos #3928

cathaysia · 2023-07-03T04:19:04Z

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

WezTerm-macos-20230408-112425-69ae8472

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

I set

default_prog = { "zsh" },

then wezterm crash immediately and without any tips.

To Reproduce

No response

Configuration

default_prog = { "zsh" },

Expected Behavior

give a tips about the reason or fallback to the default shell.

Logs

No response

Anything else?

No response

Show the error message in the pane itself when a spawn attempt fails, regardless of the exit_behavior setting. refs: #3950 refs: #3928

wez · 2023-07-09T20:57:47Z

in main:

wezterm -n --config 'default_prog={"woot"}' now shows as:

while:

wezterm -n --config 'default_prog={"/bin/woot"}' now shows as:

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

cathaysia · 2023-07-10T01:30:53Z

I foun this action already complete. and I download it from https://wezfurlong.
org/wezterm/install/macos.html#installing-on-macos . But the problem seem not fixed. it's behavior just like before:

cathaysia · 2023-07-10T01:34:08Z

if I set default_prog={"/bin/woot"} or default_prog={"woot"} then I can see:

but default_prog={"zsh"} just like before.

wez · 2023-07-10T03:16:56Z

I foun this action already complete. and I download it from https://wezfurlong. org/wezterm/install/macos.html#installing-on-macos . But the problem seem not fixed. it's behavior just like before:

Is that what you see when it is set to zsh? What does the text say? I don't read that language?

cathaysia · 2023-07-10T04:19:43Z

that is :

+------------------------------------+
|    "wezterm-gui" quit unexpectedly |
|  press "restart" so reopen.        |
|  press "report" to see detalis and |
|  sent report to Apple              |              
+------------------------------------+
|     reopen                         |
+------------------------------------+
|    report                          |
+------------------------------------+
|    ignore                          |
+------------------------------------+

when I press report, I can see some memory info: https://gist.github.com/cathaysia/5c7152efc40f7d3cda508c6d40b11001

I build wezterm from source, then debug it by lldb. But I cannot step into sourcem, just some backtrace here:

$ lldb ./target/debug/wezterm                                                                                                             ✔
(lldb) target create "./target/debug/wezterm"
Current executable set to '/Users/xxx/wezterm/target/debug/wezterm' (arm64).
(lldb) run
Process 91681 launched: '/Users/xxx/wezterm/target/debug/wezterm' (arm64)
Process 91681 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=1, subcode=0x4a03000)
    frame #0: 0x0000000101095068 wezterm`_armv8_sve_probe
wezterm`:
->  0x101095068 <+0>: eor    z0.d, z0.d, z0.d
    0x10109506c <+4>: ret

wezterm`:
    0x101095070 <+0>: xar    z0.d, z0.d, z0.d, #0x20
    0x101095074 <+4>: ret
Target 0: (wezterm) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=1, subcode=0x4a03000)
  * frame #0: 0x0000000101095068 wezterm`_armv8_sve_probe
    frame #1: 0x00000001010954b8 wezterm`OPENSSL_cpuid_setup at armcap.c:367:9 [opt]
    frame #2: 0x00000001a8e341e0 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168
    frame #3: 0x00000001a8e75e94 dyld`invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 340
    frame #4: 0x00000001a8e691a4 dyld`invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 528
    frame #5: 0x00000001a8e142d8 dyld`dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 296
    frame #6: 0x00000001a8e681cc dyld`dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 192
    frame #7: 0x00000001a8e75958 dyld`dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 516
    frame #8: 0x00000001a8e30864 dyld`dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 448
    frame #9: 0x00000001a8e30c18 dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 220
    frame #10: 0x00000001a8e3426c dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const::$_1::operator()() const + 112
    frame #11: 0x00000001a8e30d98 dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 304
    frame #12: 0x00000001a8e54984 dyld`dyld4::APIs::runAllInitializersForMain() + 468
    frame #13: 0x00000001a8e192d0 dyld`dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3480
    frame #14: 0x00000001a8e17e18 dyld`start + 1964
(lldb)

wez · 2023-07-10T04:35:47Z

If you set default_prog={"zsh", "-n"} does it behave differently?
What if you use the full path to zsh? I'm not on my mac at the moment, but I think it is: default_prog={"/bin/zsh"}.
Do you have alternative zsh binary installed? Maybe there is an issue with it?

cathaysia · 2023-07-10T04:43:59Z

If you set default_prog={"zsh", "-n"} does it behave differently?

no, just like default_prog={"zsh"}

What if you use the full path to zsh? I'm not on my mac at the moment, but I think it is: default_prog={"/bin/zsh"}.

Yes, this is I'm use currently.

Do you have alternative zsh binary installed? Maybe there is an issue with it?

No, this zsh is come from macos.

cathaysia · 2023-07-10T04:48:13Z

Interestingly, wezterm works when I set default_prog = { "bash" }

wez · 2023-07-10T04:51:21Z

So /bin/zsh works but zsh does not?

cathaysia · 2023-07-10T04:52:42Z

yes, and I can create tab with zsh, just cannot boot a new wezterm.

…

________________________________ From: Wez Furlong ***@***.***> Sent: Monday, July 10, 2023 12:51:32 PM To: wez/wezterm ***@***.***> Cc: DragonBillow ***@***.***>; Author ***@***.***> Subject: Re: [wez/wezterm] wezterm crash when cannot found default_prog without any tips on macos (Issue #3928) So /bin/zsh works but zsh does not? ― Reply to this email directly, view it on GitHub<#3928 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKBJ6AI3Y4ASPMXFFTHSY2TXPOC5JANCNFSM6AAAAAAZ34U2FU>. You are receiving this because you authored the thread.Message ID: ***@***.***>

wez · 2023-07-10T05:03:46Z

re: lldb, I see the same thing here, but I don't have a crash or any other problems launching wezterm.
I think that trace is unrelated and that is some issue with lldb on arm macos.

Since you have build a debug build, can you run the debug build of wezterm outside of lldb and see if you get a better looking stack trace from the macos report dialog?

cathaysia · 2023-07-10T05:39:21Z

No, the report just like before: https://gist.github.com/cathaysia/7fc53a0cd4d9d0e97f4a2ea4563b8ab0

If lldb cannot be used to debug wezterm. I'm afraid there is no other means of debugging available. because gdb is not available on aarch64-darwin

wez · 2023-07-10T13:28:42Z

the debugger issue is with openssl:

iOS app is crashing on app launch with openssl 3.07 code with #20137 code PR openssl/openssl#20155

wez · 2023-07-10T13:32:14Z

Likely blocked from updating to a version with a fix by:

Update vendored version to openssl 3 sfackler/rust-openssl#1925

cathaysia · 2023-07-10T13:40:23Z

Ok, I'll try again when this PR is merged. It seems that the problem is related to Openssl. In addition, I remember that when these libraries of ice use webgpu, will wezterm consider replacing openssl with other implementations in the future (such as vulkan, diectx3D, etc.)?

wez · 2023-07-10T13:45:45Z

openssl is required by the ssh libraries used in wezterm (libssh, and libssh2), so it is unlikely to go away in the foreseeable future.

cathaysia · 2023-09-05T04:42:48Z

This issue has been fixed in the latest commit(914f18b), it's not clear why. I'll take the time to investigate.

cathaysia · 2023-09-05T05:38:15Z

This problem cannot be reproduced now, and I don't know why. But I guess it's a problem with macos itself.

github-actions · 2023-10-06T03:05:46Z

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

cathaysia added the bug Something isn't working label Jul 3, 2023

wez added a commit that referenced this issue Jul 9, 2023

hold pane open when spawn fails

c399ee6

Show the error message in the pane itself when a spawn attempt fails, regardless of the exit_behavior setting. refs: #3950 refs: #3928

wez mentioned this issue Jul 9, 2023

Unable to find command in PATH when using SpawnCommandInNewWindow set_environment_variables to edit the PATH #3950

Closed

wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Jul 9, 2023

wez added waiting-on-op Waiting for more information from the original poster and removed fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. labels Jul 10, 2023

github-actions bot removed the waiting-on-op Waiting for more information from the original poster label Jul 10, 2023

wez added the waiting-on-op Waiting for more information from the original poster label Jul 10, 2023

github-actions bot removed the waiting-on-op Waiting for more information from the original poster label Jul 10, 2023

wez mentioned this issue Jul 16, 2023

insta-crash on windows with no logs #2499

Closed

cathaysia closed this as completed Sep 5, 2023

github-actions bot locked as resolved and limited conversation to collaborators Oct 6, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

wezterm crash when cannot found default_prog without any tips on macos #3928

wezterm crash when cannot found default_prog without any tips on macos #3928

cathaysia commented Jul 3, 2023

wez commented Jul 9, 2023

cathaysia commented Jul 10, 2023

cathaysia commented Jul 10, 2023

wez commented Jul 10, 2023 •

edited

cathaysia commented Jul 10, 2023 •

edited

wez commented Jul 10, 2023

cathaysia commented Jul 10, 2023 •

edited

cathaysia commented Jul 10, 2023

wez commented Jul 10, 2023

cathaysia commented Jul 10, 2023 via email

wez commented Jul 10, 2023

cathaysia commented Jul 10, 2023

wez commented Jul 10, 2023

wez commented Jul 10, 2023

cathaysia commented Jul 10, 2023

wez commented Jul 10, 2023

cathaysia commented Sep 5, 2023

cathaysia commented Sep 5, 2023

github-actions bot commented Oct 6, 2023

wezterm crash when cannot found default_prog without any tips on macos #3928

wezterm crash when cannot found default_prog without any tips on macos #3928

Comments

cathaysia commented Jul 3, 2023

What Operating System(s) are you seeing this problem on?

Which Wayland compositor or X11 Window manager(s) are you using?

WezTerm version

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Describe the bug

To Reproduce

Configuration

Expected Behavior

Logs

Anything else?

wez commented Jul 9, 2023

cathaysia commented Jul 10, 2023

cathaysia commented Jul 10, 2023

wez commented Jul 10, 2023 • edited

cathaysia commented Jul 10, 2023 • edited

wez commented Jul 10, 2023

cathaysia commented Jul 10, 2023 • edited

cathaysia commented Jul 10, 2023

wez commented Jul 10, 2023

cathaysia commented Jul 10, 2023 via email

wez commented Jul 10, 2023

cathaysia commented Jul 10, 2023

wez commented Jul 10, 2023

wez commented Jul 10, 2023

cathaysia commented Jul 10, 2023

wez commented Jul 10, 2023

cathaysia commented Sep 5, 2023

cathaysia commented Sep 5, 2023

github-actions bot commented Oct 6, 2023

wez commented Jul 10, 2023 •

edited

cathaysia commented Jul 10, 2023 •

edited

cathaysia commented Jul 10, 2023 •

edited