ttscoff / bunch

Documentation repository for Bunch.app
https://bunchapp.co
115 stars 5 forks source link

Bunch sometimes crashes with uncaught NSRangeException #258

Open steuke opened 2 years ago

steuke commented 2 years ago

Hi,

first of all, Brett, thank you so much for making this awesome tool available! I have only recently started using it, but I think I will love.

Unfortunately, I am encountering intermittent crashes due to a NSRangeException for my main use case: running shell scripts.

Is there anything that I should be doing differently?

The context

I have a bunch that executes a bash-script, which in turn executes a single terraform-command.

The bunch testing-destroy.bunch:

---
title: 🚫 Testing DESTROY
toggles: false
---
#[run]
$ /Users/REDACTED/provisioning/testing/destroy.sh (display d:1 50%x50% right,bottom #222 #38c5eb a:95% l:n)

The script being called (destroy.sh):

#!/usr/bin/env bash
set -eu
cd /Users/REDACTED/provisioning/testing/
terraform destroy -auto-approve

The Bunch log (log level = debug)

This is the log immediately before the crash:

2022-09-25 10:33:36: 🔘Generating status menu
2022-09-25 10:34:18: ⚪[testing-destroy] Open >>>>>>>>>>>>>>>>>>>>>
2022-09-25 10:34:18: ⚪[testing-destroy] Running Shell Script (/Users/stefan/development/crunmetric-com/infrastructure/provisioning/testing/destroy.sh (display d:1 50%x50% right,bottom #222 #38c5eb a:95% l:n))
2022-09-25 10:34:18: 🔘Generating status menu
2022-09-25 10:34:18: 🔘Generating status menu

The exception (truncated)

Process:               Bunch [25580]
Path:                  /Applications/Bunch.app/Contents/MacOS/Bunch
Identifier:            com.brettterpstra.Bunch
Version:               1.4.11 (166)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Bunch [25580]
User ID:               501

Date/Time:             2022-09-25 10:34:22.859 +0200
OS Version:            macOS 11.6.8 (20G730)
Report Version:        12
Bridge OS Version:     6.6 (19P6066)
Anonymous UUID:        6B1BFD77-1A91-D3C8-0D79-71CA9D99A038

Sleep/Wake UUID:       6DDF0C7B-F466-402D-9ABE-27A0B2B04DC8

Time Awake Since Boot: 190000 seconds
Time Since Wake:       1500 seconds

System Integrity Protection: enabled

Crashed Thread:        3  Dispatch queue: com.apple.root.background-qos

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

Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSCFString rangeOfString:options:range:locale:]: Range {22072, 18446744073709551615} out of bounds; string length 22071'
abort() called
terminating with uncaught exception of type NSException

Application Specific Backtrace 1:
0   CoreFoundation                      0x00007fff2089dbeb __exceptionPreprocess + 242
1   libobjc.A.dylib                     0x00007fff205d6d92 objc_exception_throw + 48
2   Foundation                          0x00007fff21559a43 -[NSString rangeOfString:options:range:locale:] + 549
3   Foundation                          0x00007fff21559810 -[NSString rangeOfString:options:range:] + 29
4   Bunch                               0x000000010c114862 Bunch + 428130
5   Bunch                               0x000000010c114ebc Bunch + 429756
6   Bunch                               0x000000010c1138fa Bunch + 424186
7   Bunch                               0x000000010c10d001 Bunch + 397313
8   Bunch                               0x000000010c0b05b9 Bunch + 17849
9   Bunch                               0x000000010c0db2a2 Bunch + 193186
10  CoreFoundation                      0x00007fff20819483 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
11  CoreFoundation                      0x00007fff208b4ef9 ___CFXRegistrationPost_block_invoke + 49
12  CoreFoundation                      0x00007fff208b4e74 _CFXRegistrationPost + 496
13  CoreFoundation                      0x00007fff207ea70e _CFXNotificationPost + 736
14  Foundation                          0x00007fff2155cbc8 -[NSNotificationCenter postNotificationName:object:userInfo:] + 59
15  Foundation                          0x00007fff2166ab25 _performFileHandleSource + 1132
16  CoreFoundation                      0x00007fff20823cec __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
17  CoreFoundation                      0x00007fff20823c54 __CFRunLoopDoSource0 + 180
18  CoreFoundation                      0x00007fff208239d4 __CFRunLoopDoSources0 + 242
19  CoreFoundation                      0x00007fff208223fc __CFRunLoopRun + 893
20  CoreFoundation                      0x00007fff208219bc CFRunLoopRunSpecific + 563
21  Foundation                          0x00007fff216431cf -[NSConcreteTask waitUntilExit] + 324
22  Bunch                               0x000000010c0db1cf Bunch + 192975
23  Bunch                               0x000000010c0b0440 Bunch + 17472
24  libdispatch.dylib                   0x00007fff20580623 _dispatch_call_block_and_release + 12
25  libdispatch.dylib                   0x00007fff20581806 _dispatch_client_callout + 8
26  libdispatch.dylib                   0x00007fff20590976 _dispatch_root_queue_drain + 676
27  libdispatch.dylib                   0x00007fff20590f70 _dispatch_worker_thread2 + 92
28  libsystem_pthread.dylib             0x00007fff20728417 _pthread_wqthread + 244
29  libsystem_pthread.dylib             0x00007fff2072742f start_wqthread + 15

Thread 0:: Dispatch queue: com.apple.main-thread
[truncated]

Let me know if you need more info.

Best Stefan

ttscoff commented 2 years ago

Ok, so the crash is happening when the display window tries to scroll to the last line, but there isn't any content in STDOUT or STDERR. I've added a guard for this in the next beta.

Couple things I noticed while testing:

Watch for the new beta later today. There are a couple of other pretty major changes in it that will need testing before this makes it into the stable release.

-Brett

On 25 Sep 2022, at 3:52, Stefan Ukena wrote:

Hi,

first of all, Brett, thank you so much for making this awesome tool available! I have only recently started using it, but I think I will love.

Unfortunately, I am encountering intermittent crashes due to a NSRangeException for my main use case: running shell scripts.

Is there anything that I should be doing differently?

The context

I have a bunch that executes a bash-script, which in turn executes a single terraform-command.

The bunch testing-destroy.bunch:

---
title: 🚫 Testing DESTROY
toggles: false
---
#[run]
$ /Users/REDACTED/provisioning/testing/destroy.sh (display d:1 50%x50% 
right,bottom #222 #38c5eb a:95% l:n)

The script being called (destroy.sh):

#!/usr/bin/env bash
set -eu
cd /Users/REDACTED/provisioning/testing/
terraform destroy -auto-approve

The Bunch log (log level = debug)

This is the log immediately before the crash:

2022-09-25 10:33:36: 🔘Generating status menu
2022-09-25 10:34:18: ⚪[testing-destroy] Open >>>>>>>>>>>>>>>>>>>>>
2022-09-25 10:34:18: ⚪[testing-destroy] Running Shell Script 
(/Users/stefan/development/crunmetric-com/infrastructure/provisioning/testing/destroy.sh 
(display d:1 50%x50% right,bottom #222 #38c5eb a:95% l:n))
2022-09-25 10:34:18: 🔘Generating status menu
2022-09-25 10:34:18: 🔘Generating status menu

The exception (truncated)

Process:               Bunch [25580]
Path:                  /Applications/Bunch.app/Contents/MacOS/Bunch
Identifier:            com.brettterpstra.Bunch
Version:               1.4.11 (166)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Bunch [25580]
User ID:               501

Date/Time:             2022-09-25 10:34:22.859 +0200
OS Version:            macOS 11.6.8 (20G730)
Report Version:        12
Bridge OS Version:     6.6 (19P6066)
Anonymous UUID:        6B1BFD77-1A91-D3C8-0D79-71CA9D99A038

Sleep/Wake UUID:       6DDF0C7B-F466-402D-9ABE-27A0B2B04DC8

Time Awake Since Boot: 190000 seconds
Time Since Wake:       1500 seconds

System Integrity Protection: enabled

Crashed Thread:        3  Dispatch queue: 
com.apple.root.background-qos

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

Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', 
reason: '*** -[__NSCFString rangeOfString:options:range:locale:]: 
Range {22072, 18446744073709551615} out of bounds; string length 
22071'
abort() called
terminating with uncaught exception of type NSException

Application Specific Backtrace 1:
0   CoreFoundation                      0x00007fff2089dbeb 
__exceptionPreprocess + 242
1   libobjc.A.dylib                     0x00007fff205d6d92 
objc_exception_throw + 48
2   Foundation                          0x00007fff21559a43 -[NSString 
rangeOfString:options:range:locale:] + 549
3   Foundation                          0x00007fff21559810 -[NSString 
rangeOfString:options:range:] + 29
4   Bunch                               0x000000010c114862 Bunch + 
428130
5   Bunch                               0x000000010c114ebc Bunch + 
429756
6   Bunch                               0x000000010c1138fa Bunch + 
424186
7   Bunch                               0x000000010c10d001 Bunch + 
397313
8   Bunch                               0x000000010c0b05b9 Bunch + 
17849
9   Bunch                               0x000000010c0db2a2 Bunch + 
193186
10  CoreFoundation                      0x00007fff20819483 
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
11  CoreFoundation                      0x00007fff208b4ef9 
___CFXRegistrationPost_block_invoke + 49
12  CoreFoundation                      0x00007fff208b4e74 
_CFXRegistrationPost + 496
13  CoreFoundation                      0x00007fff207ea70e 
_CFXNotificationPost + 736
14  Foundation                          0x00007fff2155cbc8 
-[NSNotificationCenter postNotificationName:object:userInfo:] + 59
15  Foundation                          0x00007fff2166ab25 
_performFileHandleSource + 1132
16  CoreFoundation                      0x00007fff20823cec 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
17  CoreFoundation                      0x00007fff20823c54 
__CFRunLoopDoSource0 + 180
18  CoreFoundation                      0x00007fff208239d4 
__CFRunLoopDoSources0 + 242
19  CoreFoundation                      0x00007fff208223fc 
__CFRunLoopRun + 893
20  CoreFoundation                      0x00007fff208219bc 
CFRunLoopRunSpecific + 563
21  Foundation                          0x00007fff216431cf 
-[NSConcreteTask waitUntilExit] + 324
22  Bunch                               0x000000010c0db1cf Bunch + 
192975
23  Bunch                               0x000000010c0b0440 Bunch + 
17472
24  libdispatch.dylib                   0x00007fff20580623 
_dispatch_call_block_and_release + 12
25  libdispatch.dylib                   0x00007fff20581806 
_dispatch_client_callout + 8
26  libdispatch.dylib                   0x00007fff20590976 
_dispatch_root_queue_drain + 676
27  libdispatch.dylib                   0x00007fff20590f70 
_dispatch_worker_thread2 + 92
28  libsystem_pthread.dylib             0x00007fff20728417 
_pthread_wqthread + 244
29  libsystem_pthread.dylib             0x00007fff2072742f 
start_wqthread + 15

Thread 0:: Dispatch queue: com.apple.main-thread
[truncated]

Let me know if you need more info.

Best Stefan

-- Reply to this email directly or view it on GitHub: https://github.com/ttscoff/bunch/issues/258 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

ttscoff commented 2 years ago

Beta 1.4.12 b167 is out now and should fix your issue and my findings above. Let me know if you test it out. You can download the beta at https://bunchapp.co/download/.

steuke commented 2 years ago

Hi Brett,

thank you so much for taking the time to look into this! I have

Unfortunately, at that time the crash still appeared, again with a NSRangeException. However, you mentioning that it might have todo with the output of the script. So I piped the output to a file and it turns out, it outputs a whole lot of unprintable characters, like ESC (hex 1B), which is used for coloring the output. I then added a parameter -no-color which will stop terraform from outputting those unprintable characters. My destroy.sh script now looks like this, and seems to be working now. 👍

#!/bin/bash
set -eu
cd /Users/REDACTED/provisioning/testing/
terraform destroy -no-color -auto-approve

I hope that the -no-color switch has done the trick. That would also explain why it does not crash on every run: because depending on the state of the infrastructure it is running against, the output and thus the colors might be different. Just a guess.

I am happy with this solution, so feel free to close this issue.

If you would like to investigate further, let me know and will try to find a way to help.

Thanks again! Best Stefan

ttscoff commented 2 years ago

Huh. Technically the display window should be able to handle ANSI colored output. And the range exception was happening because in my testing there wasn't ANYTHING in the output string. I'll look into this further when I get a chance, glad it's working for now.

BTW, I think I fixed it so you can use env bash again now.

-Brett

On 26 Sep 2022, at 16:00, Stefan Ukena wrote:

Hi Brett,

thank you so much for taking the time to look into this! I have

  • installed the beta
  • changed #!/usr/bin/env bash to #!/usr/bash, just to be save
  • double checked that the script is executable

Unfortunately, at that time the crash still appeared, again with a NSRangeException. However, you mentioning that it might have todo with the output of the script. So I piped the output to a file and it turns out, it outputs a whole lot of unprintable characters, like ESC (hex 1B), which is used for coloring the output. I then added a parameter -no-color which will stop terraform from outputting those unprintable characters. My destroy.sh script now looks like this, and seems to be working now. 👍

#!/bin/bash
set -eu
cd /Users/REDACTED/provisioning/testing/
terraform destroy -no-color -auto-approve

I hope that the -no-color switch has done the trick. That would also explain why it does not crash on every run: because depending on the state of the infrastructure it is running against, the output and thus the colors might be different. Just a guess.

I am happy with this solution, so feel free to close this issue.

If you would like to investigate further, let me know and will try to find a way to help.

Thanks again! Best Stefan

-- Reply to this email directly or view it on GitHub: https://github.com/ttscoff/bunch/issues/258#issuecomment-1258626445 You are receiving this because you commented.

Message ID: @.***>