Some configuration errors cause scrcpy client to hang

Environment

OS: macOS
Scrcpy version: 3.0/2.7/dev
Installation method: manual build (both client and server freshly built)
Device model: Sony
Android version: 9

Client hangs in a windowless state when trying
lldb -- x/app/scrcpy --new-display=1920x1080
or
lldb -- x/app/scrcpy --video-source=camera
on an Android 9 device.
Not even ctrl-c quits it.
Only KILL signal does.
Tried to fiddle with the ConfigurationException handling and to understand the termination procedure, but it's not clear enough to me to be able to fix this.
lldb -- x/app/scrcpy --new-display=1920x1080
(lldb) target create "x/app/scrcpy"
Current executable set to '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64).
(lldb) settings set -- target.run-args  "--new-display=1920x1080"
(lldb) run
Process 9014 launched: '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64)
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  xx
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 319.4 MB/s (90900 bytes in 0.000s)
[server] INFO: Device: [Sony] Sony xx (Android 9)
[server] ERROR: New virtual display is not supported before Android 10
DEBUG: Interrupting socket
DEBUG: Server disconnected
DEBUG: Server terminated
[hanged here with an empty client window open, so pressed ctrl-c]
Process 9014 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
libsystem_kernel.dylib`__semwait_signal:
->  0x7fff720d1746 <+10>: jae    0x7fff720d1750 ; <+20>
    0x7fff720d1748 <+12>: movq   %rax, %rdi
    0x7fff720d174b <+15>: jmp    0x7fff720d021d ; cerror
    0x7fff720d1750 <+20>: retq
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff72054eea libsystem_c.dylib`nanosleep + 196
    frame #2: 0x0000000100902750 libSDL2-2.0.0.dylib`SDL_Delay_REAL + 83
    frame #3: 0x0000000100838352 libSDL2-2.0.0.dylib`SDL_WaitEventTimeout_REAL + 485
    frame #4: 0x000000010001e953 scrcpy`await_for_server(connected=0x00007ffeefbfef7e) at scrcpy.c:227:12
    frame #5: 0x000000010001d3ce scrcpy`scrcpy(options=0x00007ffeefbff0a8) at scrcpy.c:531:10
    frame #6: 0x0000000100003427 scrcpy`main_scrcpy(argc=2, argv=0x00007ffeefbff278) at main.c:92:52
    frame #7: 0x00000001000032f2 scrcpy`main(argc=2, argv=0x00007ffeefbff278) at main.c:111:12
    frame #8: 0x00007fff71f8dcc9 libdyld.dylib`start + 1
    frame #9: 0x00007fff71f8dcc9 libdyld.dylib`start + 1
(lldb) kill
Process 9014 exited with status = 9 (0x00000009) killed

Some ConfigurationExceptions exit nicely:
lldb -- x/app/scrcpy --video-encoder=junk
(lldb) target create "x/app/scrcpy"
Current executable set to '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64).
(lldb) settings set -- target.run-args  "--video-encoder=junk"
(lldb) run
Process 9093 launched: '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64)
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  xx
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 72.0 MB/s (90900 bytes in 0.001s)
[server] INFO: Device: [Sony] Sony xx (Android 9)
[server] DEBUG: Creating encoder by name: 'junk'
[server] WARN: Audio disabled: it is not supported before Android 11
[server] DEBUG: Audio encoder stopped
[server] ERROR: Video encoder 'junk' for h264 not found
List of video encoders:
    --video-codec=h264 --video-encoder=OMX.qcom.video.encoder.avc
    --video-codec=h264 --video-encoder=OMX.google.h264.encoder
    --video-codec=h265 --video-encoder=OMX.qcom.video.encoder.hevc
[server] DEBUG: Screen streaming stopped
[server] DEBUG: Device message sender stopped
[server] DEBUG: Controller stopped
DEBUG: Server disconnected
DEBUG: Server terminated
DEBUG: Server connected
DEBUG: Starting controller thread
DEBUG: Starting receiver thread
DEBUG: Receiver stopped
DEBUG: Using SCRCPY_ICON_PATH: app/data/icon.png
INFO: Renderer: metal
DEBUG: Trilinear filtering disabled (not an OpenGL renderer)
DEBUG: Demuxer 'video': starting thread
DEBUG: Demuxer 'audio': starting thread
WARN: Device disconnected
ERROR: Demuxer 'video': stream disabled due to connection error
WARN: Demuxer 'audio': stream explicitly disabled by the device
DEBUG: quit...
DEBUG: Controller stopped
Process 9093 exited with status = 2 (0x00000002)

Even though it's a bit weird that the Server apparently connects after disconnecting and terminating.
https://github.com/Genymobile/scrcpy/blob/da8ade/app/src/scrcpy.c#L332-L333
looks worrying. Could it be that since no stream gets created, no "stream stopped" event will ever be received?

Thank you for your report. I'll fix that.

I cannot reproduce on Linux:
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                device  Nexus_5
DEBUG: Device serial: xx
DEBUG: Using server: /usr/local/share/scrcpy/scrcpy-server
/usr/local/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 387.6 MB/s (90232 bytes in 0.000s)
[server] INFO: Device: [LGE] google Nexus 5 (Android 6.0.1)
[server] ERROR: New virtual display is not supported before Android 10
DEBUG: Interrupting socket
DEBUG: Server disconnected
DEBUG: Server terminated
ERROR: Server connection failed

Could you please add these logs:
diff --git app/src/scrcpy.c app/src/scrcpy.c
index dc9e237f3..f2b1ce464 100644
--- app/src/scrcpy.c
+++ app/src/scrcpy.c
@@ -312,6 +312,7 @@ sc_server_on_connection_failed(struct sc_server *server, void *userdata) {
     (void) server;
     (void) userdata;

+    LOGI("connection_failed");
     sc_push_event(SC_EVENT_SERVER_CONNECTION_FAILED);
 }

diff --git app/src/server.c app/src/server.c
index 584a3c347..87799c242 100644
--- app/src/server.c
+++ app/src/server.c
@@ -716,6 +716,7 @@ sc_server_on_terminated(void *userdata) {
     // then the client will be stuck forever on accept(). To avoid the problem,
     // wake up the accept() call (or any other) when the server dies, like on
     // stop() (it is safe to call interrupt() twice).
+    LOGI("sc_server_on_terminated()");
     sc_intr_interrupt(&server->intr);

     server->cbs->on_disconnected(server, server->cbs_userdata);
diff --git app/src/util/process.c app/src/util/process.c
index 9c4dcd9fc..4a6b14107 100644
--- app/src/util/process.c
+++ app/src/util/process.c
@@ -27,7 +27,9 @@ sc_pipe_read_all(sc_pipe pipe, char *data, size_t len) {
 static int
 run_observer(void *data) {
     struct sc_process_observer *observer = data;
+    LOGI("sc_process_observer wait");
     sc_process_wait(observer->pid, false); // ignore exit code
+    LOGI("sc_process_observer wait end");

     sc_mutex_lock(&observer->mutex);
     observer->terminated = true;

I get:
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                device  Nexus_5
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: d/server/scrcpy-server
d/server/scrcpy-server: 1 file pushed, 0 skipped. 528.3 MB/s (159589 bytes in 0.000s)
INFO: sc_process_observer wait
[server] INFO: Device: [LGE] google Nexus 5 (Android 6.0.1)
[server] ERROR: New virtual display is not supported before Android 10
INFO: sc_process_observer wait end
INFO: sc_server_on_terminated()
DEBUG: Interrupting socket
DEBUG: Server disconnected
DEBUG: Server terminated
INFO: connection_failed
ERROR: Server connection failed

x/app/scrcpy --new-display
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  xx
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 93.0 MB/s (90877 bytes in 0.001s)
INFO: sc_process_observer wait
[server] INFO: Device: [Sony] Sony xx (Android 9)
[server] ERROR: New virtual display is not supported before Android 10
INFO: sc_process_observer wait end
INFO: sc_server_on_terminated()
DEBUG: Interrupting socket
DEBUG: Server disconnected
DEBUG: Server terminated
^CDEBUG: User requested to quit
^C^C^C^C^C

killall -KILL scrcpy
needed to terminate it.
When run in lldb, after the hang:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff72054eea libsystem_c.dylib`nanosleep + 196
    frame #2: 0x0000000100902750 libSDL2-2.0.0.dylib`SDL_Delay_REAL + 83
    frame #3: 0x0000000100838352 libSDL2-2.0.0.dylib`SDL_WaitEventTimeout_REAL + 485
    frame #4: 0x000000010001e8c3 scrcpy`await_for_server(connected=0x00007ffeefbfef8e) at scrcpy.c:227:12
    frame #5: 0x000000010001d32e scrcpy`scrcpy(options=0x00007ffeefbff0b8) at scrcpy.c:532:10
    frame #6: 0x0000000100003387 scrcpy`main_scrcpy(argc=2, argv=0x00007ffeefbff280) at main.c:92:52
    frame #7: 0x0000000100003252 scrcpy`main(argc=2, argv=0x00007ffeefbff280) at main.c:111:12
    frame #8: 0x00007fff71f8dcc9 libdyld.dylib`start + 1
(lldb) kill
Process 21420 exited with status = 9 (0x00000009) killed

I see now that I have sdl2 2.30.8 installed and 2.30.9 is available. I can upgrade and check again.

On don't pass on connection_failed.

I don't understand what you mean.

thread apply all bt

My lldb doesn't understand this, but here are all the threads expanded in the GUI:
┌──<Threads>──────────────────────────────────────────┐
│ ◆─process 22068                                     │
│ ├─◆─thread #1: tid = 0x1d7a616, stop reason = signal│
│ │ ├─#0: __semwait_signal + 10                       │
│ │ ├─#1: nanosleep + 196                             │
│ │ ├─#2: SDL_Delay_REAL + 83                         │
│ │ ├─#3: SDL_WaitEventTimeout_REAL + 485             │
│ │ ├─#4: await_for_server + 35                       │
│ │ ├─#5: scrcpy + 1646                               │
│ │ ├─#6: main_scrcpy + 295                           │
│ │ ├─#7: main + 34                                   │
│ │ └─#8: start + 1                                   │
│ ├─◆─thread #2: tid = 0x1d7a647                      │
│ │ ├─#0: __workq_kernreturn + 10                     │
│ │ ├─#1: _pthread_wqthread + 390                     │
│ │ └─#2: start_wqthread + 15                         │
│ ├─◆─thread #3: tid = 0x1d7a648                      │
│ │ ├─#0: __accept + 10                               │
│ │ ├─#1: net_accept + 59                             │
│ │ ├─#2: net_accept_intr + 55                        │
│ │ ├─#3: sc_server_connect_to + 282                  │
│ │ ├─#4: run_server + 1721                           │
│ │ ├─#5: SDL_RunThread + 44                          │
│ │ ├─#6: RunThread + 9                               │
│ │ ├─#7: _pthread_start + 148                        │
│ │ └─#8: thread_start + 15                           │
│ ├─◆─thread #4: tid = 0x1d7a651                      │
│ │ ├─#0: __workq_kernreturn + 10                     │
│ │ ├─#1:                                             │
│ │ └─#2: start_wqthread + 15                         │
│ ├─◆─thread #5: tid = 0x1d7a674                      │
│ │ ├─#0: __workq_kernreturn + 10                     │
│ │ ├─#1: _pthread_wqthread + 390                     │
│ │ └─#2: start_wqthread + 15                         │
│ ├─◆─thread #7: tid = 0x1d7a6b1                      │
│ │ ├─#0: semaphore_wait_trap + 10                    │
│ │ ├─#1: caulk::mach::semaphore::wait() + 16         │
│ │ ├─#2: caulk::semaphore::timed_wait(double) + 106  │
│ │ ├─#3: caulk::concurrent::details::worker_thread::r│
│ │ ├─#4: void* caulk::thread_proxy<std::__1::tuple<ca│
│ │ ├─#5: _pthread_start + 148                        │
│ │ └─#6: thread_start + 15                           │
│ ├─◆─thread #8: tid = 0x1d7a6b2                      │
│ │ ├─#0: semaphore_wait_trap + 10                    │
│ │ ├─#1: caulk::mach::semaphore::wait() + 16         │
│ │ ├─#2: caulk::semaphore::timed_wait(double) + 106  │
│ │ ├─#3: caulk::concurrent::details::worker_thread::r│
│ │ ├─#4: void* caulk::thread_proxy<std::__1::tuple<ca│
│ │ ├─#5: _pthread_start + 148                        │
│ │ └─#6: thread_start + 15                           │
│ ├─◆─thread #9: tid = 0x1d7a6b5                      │
│ │ ├─#0: semaphore_timedwait_trap + 10               │
│ │ ├─#1: _dispatch_sema4_timedwait + 76              │
│ │ ├─#2: _dispatch_semaphore_wait_slow + 58          │
│ │ ├─#3: _dispatch_worker_thread + 284               │
│ │ ├─#4: _pthread_start + 148                        │
│ │ └─#5: thread_start + 15                           │
│ ├─◆─thread #10: tid = 0x1d7a6c2                     │
│ │ ├─#0: mach_msg_trap + 10                          │
│ │ ├─#1: mach_msg + 60                               │
│ │ ├─#2: __CFRunLoopServiceMachPort + 247            │
│ │ ├─#3: __CFRunLoopRun + 1319                       │
│ │ ├─#4: CFRunLoopRunSpecific + 462                  │
│ │ ├─#5: _NSEventThread + 132                        │
│ │ ├─#6: _pthread_start + 148                        │
│ │ └─#7: thread_start + 15                           │
│ ├─◆─thread #11: tid = 0x1d7a6c3                     │
│ │ ├─#0: __workq_kernreturn + 10                     │
│ │ ├─#1: _pthread_wqthread + 390                     │
│ │ └─#2: start_wqthread + 15                         │
│ ├─◆─thread #12: tid = 0x1d7a6c4                     │
│ │ ├─#0: __workq_kernreturn + 10                     │
│ │ ├─#1: _pthread_wqthread + 390                     │
│ │ └─#2: start_wqthread + 15                         │
│ ├─◆─thread #13: tid = 0x1d7a6c5                     │
│ │ ├─#0: __workq_kernreturn + 10                     │
│ │ ├─#1: _pthread_wqthread + 390                     │
│ │ └─#2: start_wqthread + 15                         │
│ ├─◆─thread #14: tid = 0x1d7a6c6                     │
│ │ ├─#0: __workq_kernreturn + 10                     │
│ │ ├─#1: _pthread_wqthread + 390                     │
│ │ └─#2: start_wqthread + 15                         │
│ └─◆─thread #15: tid = 0x1d7a6c7                     │
│   ├─#0: __workq_kernreturn + 10                     │
│   ├─#1: _pthread_wqthread + 390                     │
│   └─#2: start_wqthread + 15                         │
│                                                     │

My lldb doesn't understand this

ChatGPT says:

In LLDB, the equivalent of thread apply all bt from GDB is the command:
thread backtrace all
Or its shorthand:
thread bt all
This command displays the backtrace for all threads, similar to how thread apply all bt works in GDB.

Thanks.
thread backtrace all
worked. (Not the shorthand, though.)
Anyway:
(lldb) thread backtrace all
  thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff72054eea libsystem_c.dylib`nanosleep + 196
    frame #2: 0x0000000100902750 libSDL2-2.0.0.dylib`SDL_Delay_REAL + 83
    frame #3: 0x0000000100838352 libSDL2-2.0.0.dylib`SDL_WaitEventTimeout_REAL + 485
    frame #4: 0x000000010001e8c3 scrcpy`await_for_server(connected=0x00007ffeefbfef8e) at scrcpy.c:227:12
    frame #5: 0x000000010001d32e scrcpy`scrcpy(options=0x00007ffeefbff0b8) at scrcpy.c:532:10
    frame #6: 0x0000000100003387 scrcpy`main_scrcpy(argc=2, argv=0x00007ffeefbff280) at main.c:92:52
    frame #7: 0x0000000100003252 scrcpy`main(argc=2, argv=0x00007ffeefbff280) at main.c:111:12
    frame #8: 0x00007fff71f8dcc9 libdyld.dylib`start + 1
* thread #2
  * frame #0: 0x00007fff720d04be libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff7218eaa1 libsystem_pthread.dylib`_pthread_wqthread + 390
    frame #2: 0x00007fff7218db77 libsystem_pthread.dylib`start_wqthread + 15
  thread #3, name = 'scrcpy-server'
    frame #0: 0x00007fff720d53ae libsystem_kernel.dylib`__accept + 10
    frame #1: 0x00000001000292fb scrcpy`net_accept(server_socket=3) at net.c:202:9
    frame #2: 0x0000000100029807 scrcpy`net_accept_intr(intr=0x00000001000c4888, server_socket=3) at net_intr.c:38:24
    frame #3: 0x000000010002405a scrcpy`sc_server_connect_to(server=0x00000001000c4740, info=0x00000001000c4828) at server.c:574:17
    frame #4: 0x0000000100022099 scrcpy`run_server(data=0x00000001000c4740) at server.c:1046:10
    frame #5: 0x000000010087c7d8 libSDL2-2.0.0.dylib`SDL_RunThread + 44
    frame #6: 0x00000001008e733e libSDL2-2.0.0.dylib`RunThread + 9
    frame #7: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #8: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #4
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread
  thread #5
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread
  thread #7, name = 'AMCP Logging Spool'
    frame #0: 0x00007fff720cee26 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00007fff6bb5fb16 caulk`caulk::mach::semaphore::wait() + 16
    frame #2: 0x00007fff6bb5f9b2 caulk`caulk::semaphore::timed_wait(double) + 106
    frame #3: 0x00007fff6bb5f7c4 caulk`caulk::concurrent::details::worker_thread::run() + 30
    frame #4: 0x00007fff6bb5f1e4 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 45
    frame #5: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #6: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #8
    frame #0: 0x00007fff720cee26 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00007fff6bb5fb16 caulk`caulk::mach::semaphore::wait() + 16
    frame #2: 0x00007fff6bb5f9b2 caulk`caulk::semaphore::timed_wait(double) + 106
    frame #3: 0x00007fff6bb5f7c4 caulk`caulk::concurrent::details::worker_thread::run() + 30
    frame #4: 0x00007fff6bb5f1e4 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 45
    frame #5: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #6: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #9
    frame #0: 0x00007fff720cee3e libsystem_kernel.dylib`semaphore_timedwait_trap + 10
    frame #1: 0x00007fff71f34b6b libdispatch.dylib`_dispatch_sema4_timedwait + 76
    frame #2: 0x00007fff71f34f97 libdispatch.dylib`_dispatch_semaphore_wait_slow + 58
    frame #3: 0x00007fff71f42795 libdispatch.dylib`_dispatch_worker_thread + 284
    frame #4: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #5: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #10, name = 'com.apple.NSEventThread'
    frame #0: 0x00007fff720cedea libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fff720cf160 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x00007fff38309135 CoreFoundation`__CFRunLoopServiceMachPort + 247
    frame #3: 0x00007fff38307c02 CoreFoundation`__CFRunLoopRun + 1319
    frame #4: 0x00007fff3830707e CoreFoundation`CFRunLoopRunSpecific + 462
    frame #5: 0x00007fff3571dbf4 AppKit`_NSEventThread + 132
    frame #6: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #7: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #11
    frame #0: 0x00007fff720d04be libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff7218eaa1 libsystem_pthread.dylib`_pthread_wqthread + 390
    frame #2: 0x00007fff7218db77 libsystem_pthread.dylib`start_wqthread + 15
  thread #12
    frame #0: 0x00007fff720d04be libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff7218eaa1 libsystem_pthread.dylib`_pthread_wqthread + 390
    frame #2: 0x00007fff7218db77 libsystem_pthread.dylib`start_wqthread + 15
  thread #13
    frame #0: 0x00007fff720d04be libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff7218eaa1 libsystem_pthread.dylib`_pthread_wqthread + 390
    frame #2: 0x00007fff7218db77 libsystem_pthread.dylib`start_wqthread + 15
  thread #14
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread
  thread #15
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread

│ ├─◆─thread #3: tid = 0x1d7a648                      │
│ │ ├─#0: __accept + 10                               │
│ │ ├─#1: net_accept + 59                             │
│ │ ├─#2: net_accept_intr + 55                        │

So it seems you are blocked on net_accept, but your logs show:

DEBUG: Interrupting socket

So it seems shutdown() does not interrupt an accept()…
Could you please add these logs:
diff --git app/src/util/net.c app/src/util/net.c
index d43d1c7aa..81500cc79 100644
--- app/src/util/net.c
+++ app/src/util/net.c
@@ -195,8 +195,10 @@ net_accept(sc_socket server_socket) {
     socklen_t sinsize = sizeof(csin);

 #ifdef HAVE_SOCK_CLOEXEC
+    LOGI("net_accept()");
     sc_raw_socket raw_sock =
         accept4(raw_server_socket, (SOCKADDR *) &csin, &sinsize, SOCK_CLOEXEC);
+    LOGI("net_accept() end");
 #else
     sc_raw_socket raw_sock =
         accept(raw_server_socket, (SOCKADDR *) &csin, &sinsize);
@@ -254,6 +256,7 @@ net_interrupt(sc_socket socket) {
     }
     return true;
 #else
+    LOGI("shutdown socket");
     return !shutdown(raw_sock, SHUT_RDWR);
 #endif
 }

I get:
$ ./run d --new-display
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                device  Nexus_5
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: d/server/scrcpy-server
d/server/scrcpy-server: 1 file pushed, 0 skipped. 743.9 MB/s (159589 bytes in 0.000s)
INFO: net_accept()
INFO: sc_process_observer wait
[server] INFO: Device: [LGE] google Nexus 5 (Android 6.0.1)
[server] ERROR: New virtual display is not supported before Android 10
INFO: sc_process_observer wait end
INFO: sc_server_on_terminated()
DEBUG: Interrupting socket
INFO: shutdown socket
DEBUG: Server disconnected
DEBUG: Server terminated
INFO: net_accept() end
INFO: connection_failed
ERROR: Server connection failed

With all the extra logging:
lldb -- x/app/scrcpy --new-display
(lldb) target create "x/app/scrcpy"
Current executable set to '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64).
(lldb) settings set -- target.run-args  "--new-display"
(lldb) run
Process 22552 launched: '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64)
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  G8441
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 259.9 MB/s (90877 bytes in 0.000s)
INFO: sc_process_observer wait
[server] INFO: Device: [Sony] Sony G8441 (Android 9)
[server] ERROR: New virtual display is not supported before Android 10
INFO: sc_process_observer wait end
INFO: sc_server_on_terminated()
DEBUG: Interrupting socket
INFO: shutdown socket
DEBUG: Server disconnected
DEBUG: Server terminated
Process 22552 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
libsystem_kernel.dylib`__semwait_signal:
->  0x7fff720d1746 <+10>: jae    0x7fff720d1750 ; <+20>
    0x7fff720d1748 <+12>: movq   %rax, %rdi
    0x7fff720d174b <+15>: jmp    0x7fff720d021d ; cerror
    0x7fff720d1750 <+20>: retq

(lldb) thread backtrace all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff72054eea libsystem_c.dylib`nanosleep + 196
    frame #2: 0x0000000100902750 libSDL2-2.0.0.dylib`SDL_Delay_REAL + 83
    frame #3: 0x0000000100838352 libSDL2-2.0.0.dylib`SDL_WaitEventTimeout_REAL + 485
    frame #4: 0x000000010001e8a3 scrcpy`await_for_server(connected=0x00007ffeefbfef8e) at scrcpy.c:227:12
    frame #5: 0x000000010001d30e scrcpy`scrcpy(options=0x00007ffeefbff0b8) at scrcpy.c:532:10
    frame #6: 0x0000000100003367 scrcpy`main_scrcpy(argc=2, argv=0x00007ffeefbff280) at main.c:92:52
    frame #7: 0x0000000100003232 scrcpy`main(argc=2, argv=0x00007ffeefbff280) at main.c:111:12
    frame #8: 0x00007fff71f8dcc9 libdyld.dylib`start + 1
  thread #3, name = 'scrcpy-server'
    frame #0: 0x00007fff720d53ae libsystem_kernel.dylib`__accept + 10
    frame #1: 0x00000001000292db scrcpy`net_accept(server_socket=3) at net.c:204:9
    frame #2: 0x00000001000297f7 scrcpy`net_accept_intr(intr=0x00000001000c4888, server_socket=3) at net_intr.c:38:24
    frame #3: 0x000000010002403a scrcpy`sc_server_connect_to(server=0x00000001000c4740, info=0x00000001000c4828) at server.c:574:17
    frame #4: 0x0000000100022079 scrcpy`run_server(data=0x00000001000c4740) at server.c:1046:10
    frame #5: 0x000000010087c7d8 libSDL2-2.0.0.dylib`SDL_RunThread + 44
    frame #6: 0x00000001008e733e libSDL2-2.0.0.dylib`RunThread + 9
    frame #7: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #8: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #7, name = 'AMCP Logging Spool'
    frame #0: 0x00007fff720cee26 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00007fff6bb5fb16 caulk`caulk::mach::semaphore::wait() + 16
    frame #2: 0x00007fff6bb5f9b2 caulk`caulk::semaphore::timed_wait(double) + 106
    frame #3: 0x00007fff6bb5f7c4 caulk`caulk::concurrent::details::worker_thread::run() + 30
    frame #4: 0x00007fff6bb5f1e4 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 45
    frame #5: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #6: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #8
    frame #0: 0x00007fff720cee26 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00007fff6bb5fb16 caulk`caulk::mach::semaphore::wait() + 16
    frame #2: 0x00007fff6bb5f9b2 caulk`caulk::semaphore::timed_wait(double) + 106
    frame #3: 0x00007fff6bb5f7c4 caulk`caulk::concurrent::details::worker_thread::run() + 30
    frame #4: 0x00007fff6bb5f1e4 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 45
    frame #5: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #6: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #10, name = 'com.apple.NSEventThread'
    frame #0: 0x00007fff720cedea libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fff720cf160 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x00007fff38309135 CoreFoundation`__CFRunLoopServiceMachPort + 247
    frame #3: 0x00007fff38307c02 CoreFoundation`__CFRunLoopRun + 1319
    frame #4: 0x00007fff3830707e CoreFoundation`CFRunLoopRunSpecific + 462
    frame #5: 0x00007fff3571dbf4 AppKit`_NSEventThread + 132
    frame #6: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #7: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #11
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread
(lldb) kill
Process 22552 exited with status = 9 (0x00000009) killed

Hmmm… more:
diff --git app/src/server.c app/src/server.c
index 0e449deae..cf9e82486 100644
--- app/src/server.c
+++ app/src/server.c
@@ -1044,12 +1044,18 @@ run_server(void *data) {
         goto error_connection_failed;
     }

+    LOGI("sc_server_connect_to()");
     ok = sc_server_connect_to(server, &server->info);
+    LOGI("sc_server_connect_to() returned %s", ok ? "true" : "false");
     // The tunnel is always closed by server_connect_to()
     if (!ok) {
+        LOGI("sc_process_terminate(%d)", pid);
         sc_process_terminate(pid);
+        LOGI("sc_process_wait(%d, true)", pid);
         sc_process_wait(pid, true); // ignore exit code
+        LOGI("sc_process_observer_join()");
         sc_process_observer_join(&observer);
+        LOGI("sc_process_observer_destroy()");
         sc_process_observer_destroy(&observer);
         goto error_connection_failed;
     }

lldb -- x/app/scrcpy --new-display
(lldb) target create "x/app/scrcpy"
Current executable set to '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64).
(lldb) settings set -- target.run-args  "--new-display"
(lldb) run
Process 22996 launched: '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64)
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  G8441
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 301.2 MB/s (90877 bytes in 0.000s)
INFO: sc_server_connect_to()
INFO: sc_process_observer wait
[server] INFO: Device: [Sony] Sony G8441 (Android 9)
[server] ERROR: New virtual display is not supported before Android 10
INFO: sc_process_observer wait end
INFO: sc_server_on_terminated()
DEBUG: Interrupting socket
INFO: shutdown socket
DEBUG: Server disconnected
DEBUG: Server terminated
[----- hanged here -----]
Process 22996 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
libsystem_kernel.dylib`__semwait_signal:
->  0x7fff720d1746 <+10>: jae    0x7fff720d1750 ; <+20>
    0x7fff720d1748 <+12>: movq   %rax, %rdi
    0x7fff720d174b <+15>: jmp    0x7fff720d021d ; cerror
    0x7fff720d1750 <+20>: retq
(lldb) thread backtrace all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff72054eea libsystem_c.dylib`nanosleep + 196
    frame #2: 0x0000000100902750 libSDL2-2.0.0.dylib`SDL_Delay_REAL + 83
    frame #3: 0x0000000100838352 libSDL2-2.0.0.dylib`SDL_WaitEventTimeout_REAL + 485
    frame #4: 0x000000010001e783 scrcpy`await_for_server(connected=0x00007ffeefbfef8e) at scrcpy.c:227:12
    frame #5: 0x000000010001d1ee scrcpy`scrcpy(options=0x00007ffeefbff0b8) at scrcpy.c:532:10
    frame #6: 0x0000000100003247 scrcpy`main_scrcpy(argc=2, argv=0x00007ffeefbff280) at main.c:92:52
    frame #7: 0x0000000100003112 scrcpy`main(argc=2, argv=0x00007ffeefbff280) at main.c:111:12
    frame #8: 0x00007fff71f8dcc9 libdyld.dylib`start + 1
  thread #3, name = 'scrcpy-server'
    frame #0: 0x00007fff720d53ae libsystem_kernel.dylib`__accept + 10
    frame #1: 0x000000010002923b scrcpy`net_accept(server_socket=4) at net.c:204:9
    frame #2: 0x0000000100029757 scrcpy`net_accept_intr(intr=0x00000001000c4888, server_socket=4) at net_intr.c:38:24
    frame #3: 0x0000000100023f9a scrcpy`sc_server_connect_to(server=0x00000001000c4740, info=0x00000001000c4828) at server.c:574:17
    frame #4: 0x0000000100021f69 scrcpy`run_server(data=0x00000001000c4740) at server.c:1047:10
    frame #5: 0x000000010087c7d8 libSDL2-2.0.0.dylib`SDL_RunThread + 44
    frame #6: 0x00000001008e733e libSDL2-2.0.0.dylib`RunThread + 9
    frame #7: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #8: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #6, name = 'AMCP Logging Spool'
    frame #0: 0x00007fff720cee26 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00007fff6bb5fb16 caulk`caulk::mach::semaphore::wait() + 16
    frame #2: 0x00007fff6bb5f9b2 caulk`caulk::semaphore::timed_wait(double) + 106
    frame #3: 0x00007fff6bb5f7c4 caulk`caulk::concurrent::details::worker_thread::run() + 30
    frame #4: 0x00007fff6bb5f1e4 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 45
    frame #5: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #6: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #7
    frame #0: 0x00007fff720cee26 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00007fff6bb5fb16 caulk`caulk::mach::semaphore::wait() + 16
    frame #2: 0x00007fff6bb5f9b2 caulk`caulk::semaphore::timed_wait(double) + 106
    frame #3: 0x00007fff6bb5f7c4 caulk`caulk::concurrent::details::worker_thread::run() + 30
    frame #4: 0x00007fff6bb5f1e4 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 45
    frame #5: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #6: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #10, name = 'com.apple.NSEventThread'
    frame #0: 0x00007fff720cedea libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fff720cf160 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x00007fff38309135 CoreFoundation`__CFRunLoopServiceMachPort + 247
    frame #3: 0x00007fff38307c02 CoreFoundation`__CFRunLoopRun + 1319
    frame #4: 0x00007fff3830707e CoreFoundation`CFRunLoopRunSpecific + 462
    frame #5: 0x00007fff3571dbf4 AppKit`_NSEventThread + 132
    frame #6: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #7: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #11
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread
  thread #12
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread
  thread #13
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread
(lldb) kill
Process 22996 exited with status = 9 (0x00000009) killed

lldb -- x/app/scrcpy --new-display
(lldb) target create "x/app/scrcpy"
Current executable set to '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64).
(lldb) settings set -- target.run-args  "--new-display"
(lldb) run
Process 23450 launched: '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64)
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  G8441
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 75.1 MB/s (90877 bytes in 0.001s)
INFO: sc_server_connect_to()
INFO: accept()
INFO: sc_process_observer wait
[server] INFO: Device: [Sony] Sony G8441 (Android 9)
[server] ERROR: New virtual display is not supported before Android 10
INFO: sc_process_observer wait end
INFO: sc_server_on_terminated()
DEBUG: Interrupting socket
INFO: shutdown socket
DEBUG: Server disconnected
DEBUG: Server terminated
[----- hanged here -----]
Process 23450 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
libsystem_kernel.dylib`__semwait_signal:
->  0x7fff720d1746 <+10>: jae    0x7fff720d1750 ; <+20>
    0x7fff720d1748 <+12>: movq   %rax, %rdi
    0x7fff720d174b <+15>: jmp    0x7fff720d021d ; cerror
    0x7fff720d1750 <+20>: retq
(lldb) thread backtrace all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff720d1746 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff72054eea libsystem_c.dylib`nanosleep + 196
    frame #2: 0x0000000100902750 libSDL2-2.0.0.dylib`SDL_Delay_REAL + 83
    frame #3: 0x0000000100838352 libSDL2-2.0.0.dylib`SDL_WaitEventTimeout_REAL + 485
    frame #4: 0x000000010001e753 scrcpy`await_for_server(connected=0x00007ffeefbfef8e) at scrcpy.c:227:12
    frame #5: 0x000000010001d1be scrcpy`scrcpy(options=0x00007ffeefbff0b8) at scrcpy.c:532:10
    frame #6: 0x0000000100003217 scrcpy`main_scrcpy(argc=2, argv=0x00007ffeefbff280) at main.c:92:52
    frame #7: 0x00000001000030e2 scrcpy`main(argc=2, argv=0x00007ffeefbff280) at main.c:111:12
    frame #8: 0x00007fff71f8dcc9 libdyld.dylib`start + 1
  thread #3, name = 'scrcpy-server'
    frame #0: 0x00007fff720d53ae libsystem_kernel.dylib`__accept + 10
    frame #1: 0x000000010002921b scrcpy`net_accept(server_socket=3) at net.c:205:9
    frame #2: 0x0000000100029747 scrcpy`net_accept_intr(intr=0x00000001000c4888, server_socket=3) at net_intr.c:38:24
    frame #3: 0x0000000100023f6a scrcpy`sc_server_connect_to(server=0x00000001000c4740, info=0x00000001000c4828) at server.c:574:17
    frame #4: 0x0000000100021f39 scrcpy`run_server(data=0x00000001000c4740) at server.c:1047:10
    frame #5: 0x000000010087c7d8 libSDL2-2.0.0.dylib`SDL_RunThread + 44
    frame #6: 0x00000001008e733e libSDL2-2.0.0.dylib`RunThread + 9
    frame #7: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #8: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #6, name = 'AMCP Logging Spool'
    frame #0: 0x00007fff720cee26 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00007fff6bb5fb16 caulk`caulk::mach::semaphore::wait() + 16
    frame #2: 0x00007fff6bb5f9b2 caulk`caulk::semaphore::timed_wait(double) + 106
    frame #3: 0x00007fff6bb5f7c4 caulk`caulk::concurrent::details::worker_thread::run() + 30
    frame #4: 0x00007fff6bb5f1e4 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 45
    frame #5: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #6: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #7
    frame #0: 0x00007fff720cee26 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00007fff6bb5fb16 caulk`caulk::mach::semaphore::wait() + 16
    frame #2: 0x00007fff6bb5f9b2 caulk`caulk::semaphore::timed_wait(double) + 106
    frame #3: 0x00007fff6bb5f7c4 caulk`caulk::concurrent::details::worker_thread::run() + 30
    frame #4: 0x00007fff6bb5f1e4 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 45
    frame #5: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #6: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #9, name = 'com.apple.NSEventThread'
    frame #0: 0x00007fff720cedea libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fff720cf160 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x00007fff38309135 CoreFoundation`__CFRunLoopServiceMachPort + 247
    frame #3: 0x00007fff38307c02 CoreFoundation`__CFRunLoopRun + 1319
    frame #4: 0x00007fff3830707e CoreFoundation`CFRunLoopRunSpecific + 462
    frame #5: 0x00007fff3571dbf4 AppKit`_NSEventThread + 132
    frame #6: 0x00007fff72192109 libsystem_pthread.dylib`_pthread_start + 148
    frame #7: 0x00007fff7218db8b libsystem_pthread.dylib`thread_start + 15
  thread #10
    frame #0: 0x00007fff7218db68 libsystem_pthread.dylib`start_wqthread
  thread #11
    frame #0: 0x0000000000000000
(lldb) kill
Process 23450 exited with status = 9 (0x00000009) killed

Just for reference with all the logging, when it exits nicely:
lldb -- x/app/scrcpy --video-encoder=junk
(lldb) target create "x/app/scrcpy"
Current executable set to '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64).
(lldb) settings set -- target.run-args  "--video-encoder=junk"
(lldb) run
Process 23503 launched: '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64)
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  G8441
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 88.0 MB/s (90877 bytes in 0.001s)
INFO: sc_process_observer wait
INFO: sc_server_connect_to()
INFO: accept()
[server] INFO: Device: [Sony] Sony G8441 (Android 9)
INFO: accept() end
INFO: accept()
INFO: accept() end
INFO: accept()
INFO: accept() end
[server] DEBUG: Creating encoder by name: 'junk'
[server] WARN: Audio disabled: it is not supported before Android 11
[server] DEBUG: Audio encoder stopped
INFO: sc_server_connect_to() returned true
[server] DEBUG: Screen streaming stopped
[server] ERROR: Video encoder 'junk' for h264 not found
List of video encoders:
    --video-codec=h264 --video-encoder=OMX.qcom.video.encoder.avc
    --video-codec=h264 --video-encoder=OMX.google.h264.encoder
    --video-codec=h265 --video-encoder=OMX.qcom.video.encoder.hevc
[server] DEBUG: Device message sender stopped
[server] DEBUG: Controller stopped
INFO: sc_process_observer wait end
INFO: sc_server_on_terminated()
DEBUG: Server disconnected
DEBUG: Server terminated
DEBUG: Server connected
DEBUG: Starting controller thread
DEBUG: Starting receiver thread
DEBUG: Receiver stopped
DEBUG: Using SCRCPY_ICON_PATH: app/data/icon.png
INFO: Renderer: metal
DEBUG: Trilinear filtering disabled (not an OpenGL renderer)
DEBUG: Demuxer 'video': starting thread
DEBUG: Demuxer 'audio': starting thread
WARN: Device disconnected
ERROR: Demuxer 'video': stream disabled due to connection error
WARN: Demuxer 'audio': stream explicitly disabled by the device
DEBUG: quit...
DEBUG: Controller stopped
INFO: shutdown socket
INFO: shutdown socket
INFO: shutdown socket
Process 23503 exited with status = 2 (0x00000002)

When building:
./server/build_without_gradle.sh && meson setup x --buildtype=debug \
  -Dprebuilt_server=build_manual/scrcpy-server && ninja -Cx

Platform: android-35
Build-tools: 35.0.0
Build dir: /Users/Shared/src/scm/android/scrcpy/build_manual
Generating java from aidl...
Compiling java sources...
Dexing...
Server generated in /Users/Shared/src/scm/android/scrcpy/build_manual/scrcpy-server
The Meson build system
Version: 1.4.1
Source dir: /Users/Shared/src/scm/android/scrcpy
Build dir: /Users/Shared/src/scm/android/scrcpy/x
Build type: native build
Project name: scrcpy
Project version: 3.0
C compiler for the host machine: cc (clang 18.1.8 "Homebrew clang version 18.1.8")
C linker for the host machine: cc ld64 609.8
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: YES (/usr/local/bin/pkg-config) 2.3.0
Run-time dependency libavformat found: YES 60.3.100
Run-time dependency libavcodec found: YES 60.3.100
Run-time dependency libavutil found: YES 58.2.100
Run-time dependency libswresample found: YES 4.10.100
Run-time dependency sdl2 found: YES 2.30.8
Run-time dependency libusb-1.0 found: YES 1.0.27
Checking for function "strdup" : YES
Checking for function "asprintf" : YES
Checking for function "vasprintf" : YES
Checking for function "nrand48" : YES
Checking for function "jrand48" : YES
Checking for function "reallocarray" : NO
Header "sys/socket.h" has symbol "SOCK_CLOEXEC" : NO
Configuring config.h using configuration
Build targets in project: 13

scrcpy 3.0

  User defined options
    buildtype      : debug
    prebuilt_server: build_manual/scrcpy-server

Found ninja-1.12.1 at /usr/local/bin/ninja
ninja: Entering directory `x'
[129/129] Linking target app/scrcpy

OK, so your shutdown() does not interrupt accept(). Weird. 🤔

I guess we have to close() the socket in addition (like on Windows) in net_interrupt().
Could you try this dirty hack:
diff --git app/src/util/intr.c app/src/util/intr.c
index 22bd121a7..48171237e 100644
--- app/src/util/intr.c
+++ app/src/util/intr.c
@@ -63,6 +63,7 @@ sc_intr_interrupt(struct sc_intr *intr) {
     if (intr->socket != SC_SOCKET_NONE) {
         LOGD("Interrupting socket");
         net_interrupt(intr->socket);
+        net_close(intr->socket); // hack
         intr->socket = SC_SOCKET_NONE;
     }
     if (intr->process != SC_PROCESS_NONE) {

OKAAYY!
lldb -- x/app/scrcpy --new-display
(lldb) target create "x/app/scrcpy"
Current executable set to '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64).
(lldb) settings set -- target.run-args  "--new-display"
(lldb) run
Process 23943 launched: '/src/scm/android/scrcpy/x/app/scrcpy' (x86_64)
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  G8441
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 229.3 MB/s (90877 bytes in 0.000s)
INFO: sc_server_connect_to()
INFO: sc_process_observer wait
INFO: accept()
[server] INFO: Device: [Sony] Sony G8441 (Android 9)
[server] ERROR: New virtual display is not supported before Android 10
INFO: sc_process_observer wait end
INFO: sc_server_on_terminated()
DEBUG: Interrupting socket
INFO: shutdown socket
INFO: accept() end
DEBUG: Server disconnected
DEBUG: Server terminated
WARN: Could not close server socket
INFO: sc_server_connect_to() returned false
INFO: sc_process_terminate(23957)
INFO: sc_process_wait(23957, true)
INFO: sc_process_observer_join()
INFO: sc_process_observer_destroy()
INFO: connection_failed
ERROR: Server connection failed
Process 23943 exited with status = 1 (0x00000001)

Please test branch macos_close_on_interrupt.

Building generates lots of these warnings:
../app/src/util/net.h:33:10: warning: 'SC_SOCKET_NONE' macro redefined [-Wmacro-redefined]
   33 | # define SC_SOCKET_NONE NULL
      |          ^
../app/src/util/net.h:15:10: note: previous definition is here
   15 | # define SC_SOCKET_NONE -1
      |          ^

But it works fine now:
x/app/scrcpy --new-display
scrcpy 3.0 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  xx                      device  G8441
DEBUG: Device serial: xx
DEBUG: Using SCRCPY_SERVER_PATH: x/server/scrcpy-server
x/server/scrcpy-server: 1 file pushed, 0 skipped. 127.5 MB/s (90879 bytes in 0.001s)
[server] INFO: Device: [Sony] Sony G8441 (Android 9)
[server] ERROR: New virtual display is not supported before Android 10
DEBUG: Interrupting socket
DEBUG: Server disconnected
DEBUG: Server terminated
ERROR: Server connection failed

Also tried
x/app/scrcpy --video-encoder=junk
and plain
x/app/scrcpy
and they also work fine.

Oops, please retry with this additional change:
diff --git app/src/util/net.h app/src/util/net.h
index d1e14df08..94789954a 100644
--- app/src/util/net.h
+++ app/src/util/net.h
@@ -12,7 +12,6 @@
 # define SC_RAW_SOCKET_NONE INVALID_SOCKET
 #else // not _WIN32
 # include <sys/socket.h>
-# define SC_SOCKET_NONE -1
   typedef int sc_raw_socket;
 # define SC_RAW_SOCKET_NONE -1
 #endif

Was already testing it. ;)
Builds and works perfectly now.

Merged into dev :rocket:


⚠ Bofrost.fr has degraded performance

In 5b64d2c, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1269 ms

Resolved: Bofrost.fr performance has improved in 176f05a.


Problem trying to compile Admob and Google play services

I'm trying to compile a version of the template for AdMob and Google Play Services. I was successful in compiling the Google Play Services version in this repository.
https://github.com/kloder-games/godot-gpgs
Now I'm trying to compile AdMob so I can use both modules in my game.
I get this error:
Execution failed for task ': transformClassesWithDexForDebug'.

com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: java.util.concurrent.ExecutionException: com.android.dex.DexException: Multiple dex files define Lcom / google / android / gms / internal / zztd;

Could you help me? 😅

I solved the problem. If someone goes through something like this, just check the config.py file and make sure all versions of the libraries that are called by the gradle are the same. :cake:


Update to rustc 0.13.0-nightly (ad9e75938 2015-01-05 00:26:28 +0000).

related: https://github.com/rust-lang/rust/commit/400c3a0d

duplicated: #51


Rename refinement rules for V types.

It turns out nobody had ever tried to invoke a refinement rule for V types before today, because they were impossible to invoke. Let's see if you can spot the issue:
in the lexer:
<INITIAL>{lower}{identChr}* => (Tokens.VARNAME (posTupleWith (size yytext) yytext));

in the parser:
atomicRawTac
  : REFINE VARNAME (Ast.$$ (O.RULE_PRIM VARNAME, []))

in the refinement rule lookup:
     | "V/eqtype" => Lcf.rule V.EqType

lmao!! I actually knew about this at one point but I forgot to open a ticket. Taste it! 😎

I really want capitalized V...


miniflux: 2.2.0 -> 2.2.1

Description of changes
https://miniflux.app/releases/2.2.1.html

miniflux: add updateScript
miniflux: 2.2.0 -> 2.2.1
miniflux: move to by-name

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I don't think go 1.23 is in stable, so we'd need to loosen that requirement to backport.

Ah yes, you are right. Guess no backport then^^


Update go deps, vendor and prune.

This results in a build that works without changes, but also which doesn't fix any issues.
There are 2 example files now, one for 0.12 syntax, and one for 0.11 syntax.
This was built with the current 0.13.0 version of the terraform library to not be too out of date.

This should pass all current tests. This adds an environment variable so that request and responses will only display when TF_AO_DEBUG is set. I have no attachment to that name, it's probably best if it changes.
spacey@bagpig:~/go/src/github.com/appoptics/terraform-provider-appoptics (upgrade-to-0.12)$ TF_ACC=1 APPOPTICS_TOKEN='<token>' go test -v ./...
?   	github.com/appoptics/terraform-provider-appoptics	[no test files]
=== RUN   TestProvider
--- PASS: TestProvider (0.00s)
=== RUN   TestProvider_impl
--- PASS: TestProvider_impl (0.00s)
=== RUN   TestAccAppOpticsAlertMinimal
--- PASS: TestAccAppOpticsAlertMinimal (1.86s)
=== RUN   TestAccAppOpticsAlertBasic
--- PASS: TestAccAppOpticsAlertBasic (1.37s)
=== RUN   TestAccAppOpticsAlertFull
--- PASS: TestAccAppOpticsAlertFull (3.50s)
=== RUN   TestAccAppOpticsAlertUpdated
--- PASS: TestAccAppOpticsAlertUpdated (10.99s)
=== RUN   TestAccAppOpticsAlertRename
--- PASS: TestAccAppOpticsAlertRename (11.04s)
=== RUN   TestAccAppOpticsAlertFullUpdate
--- PASS: TestAccAppOpticsAlertFullUpdate (3.55s)
=== RUN   TestAccAppOpticsMetrics
--- PASS: TestAccAppOpticsMetrics (31.81s)
=== RUN   TestAccAppOpticsServiceBasic
--- PASS: TestAccAppOpticsServiceBasic (2.44s)
=== RUN   TestAccAppOpticsServiceUpdated
--- PASS: TestAccAppOpticsServiceUpdated (12.03s)
=== RUN   TestAccAppOpticsSpaceChartBasic
--- FAIL: TestAccAppOpticsSpaceChartBasic (0.01s)
    testing.go:572: Step 0 error: config is invalid: 2 problems:

        - Invalid resource type: The provider provider.appoptics does not support resource type "appoptics_space_chart".
        - Invalid resource type: The provider provider.appoptics does not support resource type "appoptics_space".
=== RUN   TestAccAppOpticsSpaceChart_Full
--- FAIL: TestAccAppOpticsSpaceChart_Full (0.01s)
    testing.go:572: Step 0 error: config is invalid: 3 problems:

        - Invalid resource type: The provider provider.appoptics does not support resource type "appoptics_space_chart".
        - Invalid resource type: The provider provider.appoptics does not support resource type "appoptics_space".
        - Invalid resource type: The provider provider.appoptics does not support resource type "appoptics_space".
=== RUN   TestAccAppOpticsSpaceChart_Updated
--- FAIL: TestAccAppOpticsSpaceChart_Updated (0.01s)
    testing.go:572: Step 0 error: config is invalid: 2 problems:

        - Invalid resource type: The provider provider.appoptics does not support resource type "appoptics_space_chart".
        - Invalid resource type: The provider provider.appoptics does not support resource type "appoptics_space".
=== RUN   TestAccAppOpticsSpaceBasic
--- FAIL: TestAccAppOpticsSpaceBasic (0.01s)
    testing.go:572: Step 0 error: config is invalid: Invalid resource type: The provider provider.appoptics does not support resource type "appoptics_space".
FAIL
FAIL	github.com/appoptics/terraform-provider-appoptics/appoptics	78.627s
FAIL


EKS cluster without node group is not working

I have issues
I'm submitting a...

[x] bug report
[ ] feature request
[ ] support request - read the FAQ first!
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
I have created EKS cluster using this module with fargate & now I'm trying to delete EC2 nodes created by this module by commenting node_groups line. But it is not working getting following error.

If this is a bug, how to reproduce? Please include a code sample if relevant.
What's the expected behavior?
I want to deploy EKS cluster without EC2 nodes
Are you able to fix this problem and submit a PR? Link here if you have already.
Environment details

Affected module version: latest
OS: NA (terraform cloud)
Terraform version: NA (terraform cloud)

Any other relevant info

Error: Cycle: module.eks-cluster.module.external-dns.var.cluster_oidc_issuer_url (expand), module.eks-cluster.module.external-dns.module.service_account_assume_role_policy.var.eks_openid_connect_provider_url (expand), module.eks-cluster.module.external-dns.module.service_account_assume_role_policy.var.namespaces (expand), module.eks-

Error: Cycle: module.eks-cluster.module.external-dns.var.cluster_oidc_issuer_url (expand), module.eks-cluster.module.external-dns.module.service_account_assume_role_policy.var.eks_openid_connect_provider_url (expand), module.eks-cluster.module.external-dns.module.service_account_assume_role_policy.var.namespaces (expand), module.eks-

Posting error again as it was not visible


Firebase auth

firebase OTP is not working in android version 12 and below after uploading application into play store
can some one help me to fix this issue
i am using SDK version
SDK: ">=2.17.5 <4.0.0"
firebase_core: ^2.15.0
cloud_firestore: any
firebase_auth: ^4.7.2

Please follow the template.


Lazy-loading icons

Last one (sorry for filling your issues here!):
We have a large collection of icons which will always be loaded in full on page load (3.5 MB in our case).
It would be great if icons would only be fetched when opening the picklist and if there was server side filtering applied.
I know this is an issue of the core as well, see https://github.com/getkirby/kirby/issues/6043, but I think with icon sets this will become an issue for this plugin quicky.

I'll probably not implement this until its either addressed in core or there's some other easy way to do this that doesn't involve moving away from the Core Multiselect/Tags field structure, as I don't really have a use case for this in my own projects and this would add a lot of extra complexity to the plugin (I mostly only allow a selection of icons if using a pack, or icons are designed by us anyway). I'm willing to work on a funded feature request if this is a blocker for your project.

You could try using a SVG sprite which should minimize the initial payload.

I totally understand that :+1:
It's not a problem for us right now because we can reduce the provided icons in this particular project.


Implementation Plan: Move Airflow and API to openverse.org

Fixes

Fixes https://github.com/WordPress/openverse/issues/2038 by @sarayourfriend
Part of https://github.com/WordPress/openverse/issues/2037
Description

I've requested review from @AetherUnbound and @dhruvkb:

Madison, you are the person (I believe) most familiar with Airflow deployment details, so your input the Airflow configuration in particular is critical. You are also deeply familiar with our infrastructure configuration overall.
Dhruv, you are extremely perceptive about the interconnected dependencies of our API and frontend, and our services in general, and I think you'll be a great person to review the plan. Reviewing this plan may also increase your exposure to any areas of our infrastructure with which you are not already familiar. There are also potential changes to our Terraform configuration for GitHub, and I suspect you'll have interest in those as well.

This discussion is following the Openverse decision-making process. Information about this process can be found on the Openverse documentation site. Requested reviewers or participants will be following this process. If you are being asked to give input on a specific detail, you do not need to familiarise yourself with the process and follow it.
Current round
This discussion is currently in the Decision round.
The deadline for review of this round is 2 February 2024.
Testing Instructions

Read the plan and leave any questions.
Checklist

[x] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[N/A] I added or updated tests for the changes I made (if applicable).
[x] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.
[N/A] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@dhruvkb and @AetherUnbound, I haven't fully proofread this, but I plan to do that and then undraft it tomorrow before I go AFK until the end of the month. As mentioned in the PR description, there's no big rush to review this until February, because I'm gone until then anyway and wouldn't be able to respond to questions or start revision. However, it is a rather long plan, so starting to review it sooner than later is a good idea.

@AetherUnbound @dhruvkb Thank you for your reviews. I've made minor revisions for editorial changes (thanks, Madison) and added a new explicit step to spin down the existing Airflow instance before deploying the new one, to avoid any potential (though apparently unlikely) issues with multiple instances running on the same databases.

@AetherUnbound @dhruvkb I've moved this into the decision round. I kept the deadline to 2 February because that's still five days. Dhruv has already approved, and the changes are minor (just adding steps we've agreed to) so I am not worried about an explicit re-approval. The decision rests with you, Madison! Please let me know if there are any blockers to resolve.

Creating issues for this plan now!


Getting started guide - base

Create the initial bas document for the getting started guide.
It needs to include:

[x] Starting rancher with embedded CAPI disabled
[x] Installing CAPI operator
[x] Installing Rancher Turtles

Currently blocked by https://github.com/rancher-sandbox/rancher-turtles/issues/18


runtime: intermittent slice bounds out of range panic on linux/mipsle

What version of Go are you using (go version)?

$ go version
go version go1.19.5 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
I'm building from linux/amd64; I'm cross-compiling to GOOS=linux GOARCH=mipsle
The target device is running Linux kernel version 3.15.0.
The target device is relatively memory-constrained:
$ free
             total         used         free       shared      buffers
Mem:        254268       184452        69816            0            0
-/+ buffers:             184452        69816
Swap:            0            0            0

However, if I intentionally exhaust the memory from my Go code, I get an "out of memory" panic, as expected, not the panic I am reporting in this bug.
On the target device, /proc/cpuinfo lists the CPU as (repeated four times for processors/cores 0-3):
processor               : 0
cpu model               : MIPS 1004Kc V2.12
BogoMIPS                : 266.64
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : mips16 dsp mt
shadow register sets    : 1
kscratch registers      : 0
core                    : 1
VCED exceptions         : not available
VCEI exceptions         : not available
VPE                     : 1

What did you do?
Using Go 1.19.5 on Linux/amd64, I built the following program using:
$ GOOS=linux GOARCH=mipsle CGO_ENABLED=0 go build -o mipstest -ldflags="-s -w"
package main

import (
	"bufio"
	"log"
	"os"
	"regexp"
)

func main() {
	var fileData string

	scanner := bufio.NewScanner(os.Stdin)
	gotBegin := false

	for scanner.Scan() {
		line := scanner.Text()
		if match, _ := regexp.MatchString("----CMDDATA END----", line); match {
			break
		}

		if gotBegin {
			fileData += line
		}

		if !gotBegin {
			if match, _ := regexp.MatchString("----CMDDATA BEGIN----", line); match {
				gotBegin = true
			}
		}
	}

	if err := scanner.Err(); err != nil {
		log.Fatal(err)
	}
}

I built an ~800k, 28,000 line sample input file for the program with the following commands:
$ echo "----CMDDATA BEGIN----" > samplefile.txt
$ i=0
$ while [ $i -lt 28000 ]; do
    echo "abcdefghijklmnopqrstuvwxyz12" >> samplefile.txt
    i=$(expr $i + 1)
  done
$ echo "----CMDDATA END----" >> samplefile.txt

I then transferred the binary and the samplefile.txt to the MIPS system and run with:
$ ./mipstest < samplefile.txt
What did you expect to see?
I expected the program to run to completion. Or, if this ultimately is related to a low-memory condition, I'd expect something other than a slice bounds out of range panic.
What did you see instead?
Out of 100 runs, 41 of the runs resulted in the program terminating with a panic:
fatal error: slice bounds out of range

runtime stack:
runtime.throw({0x109c2e, 0x19})
        /usr/lib/go/src/runtime/panic.go:1047 +0x54 fp=0x839f7c sp=0x839f68 pc=0x52208
runtime.panicCheck1(0x4c3e0, {0x109c2e, 0x19})
        /usr/lib/go/src/runtime/panic.go:57 +0xfc fp=0x839f90 sp=0x839f7c pc=0x4f3f0
runtime.goPanicSliceAcap(0x800138, 0x200)
        /usr/lib/go/src/runtime/panic.go:138 +0x54 fp=0x839fb0 sp=0x839f90 pc=0x4f7e0
runtime.wbBufFlush1(0x81a000)
        /usr/lib/go/src/runtime/mwbbuf.go:287 +0x16c fp=0x839fe0 sp=0x839fb0 pc=0x4c3e0
runtime.wbBufFlush.func1()
        /usr/lib/go/src/runtime/mwbbuf.go:201 +0x44 fp=0x839fe8 sp=0x839fe0 pc=0x4c1a8
runtime.systemstack()
        /usr/lib/go/src/runtime/asm_mipsx.s:188 +0x7c fp=0x839fec sp=0x839fe8 pc=0x88224

[...]

I have attached a couple complete representative examples of the full stack traces. In one case, I got a very different looking panic -- see panic.different.txt, which has "fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)".
A successful run of the program with the samplefile.txt takes a couple minutes on this platform. Sometimes the panics occur very quickly after beginning execution, but other times they occur farther into the execution time.
Attachments
main.go.txt
samplefile.txt
panic.1.txt
panic.2.txt
panic.different.txt

(attn @golang/mips; CC @golang/runtime)
If the machine is memory constrained, it seems likely that the runtime is missing an error check somewhere in a memory-allocation path.

CC @golang/runtime
That's odd. That might be some kind of memory corruption, since I don't see how this slicing operation could fail like that. (The other kind of failure is interesting, too.) This is a relatively simple program, so it's not great that it's falling over so easily.
Here's a few things to try:

GODEBUG=gccheckmark=1 (looks for bugs in concurrent GC)
GODEBUG=gcshrinkstackoff=1 (disables stack shrinking, since this looks potentially like some kind of stack corruption)
GODEBUG=asyncpreemptoff=1 (disables asynchronous preemption signals, just because)

@bcmills To me, this doesn't look like a symptom of running out of memory, and in general we do a decent job of surfacing out of memory errors that we can catch (after some improvements in that area, some years ago). What we can't catch is something like the Linux OOM killer turning on when a page is demanded, but I don't think we'd crash like this.
Perhaps I'm missing your point though.

runtime.goPanicSliceAcap(0x800138, 0x200)

Here the slice index is 0x800138, which looks like an address. (The cap 0x200 looks correct, which matches the write barrier buffer size.) Looks like a memory corruption. Agreed that this doesn't look like running out of memory.

The target device is running Linux kernel version 3.15.0.

Would it be possible to try newer kernels? Thanks.

The target device is running Linux kernel version 3.15.0.

Would it be possible to try newer kernels? Thanks.

Yes, there are newer firmware versions available which I suspect upgrade the kernel. However, we only have one of these devices and a firmware update would be a one-way operation, so I'd lose the ability to further investigate or test potential fixes against this current kernel version.

I agree that this doesn't look like OOM too. 69MiB of free memory is enough for your case. I can't reproduce the issue at all (no panic or OOM) on Loongson 3A4000 with a 16MiB memory limit.
The most probable cause is memory corruption, either a software/kernel problem or a hardware one. As upgrading the kernel is impossible, though broken RAM seems not very common, could you do some memory tests (e.g. https://pyropus.ca./software/memtester/)?

The target device is running Linux kernel version 3.15.0.

firmware

I suspect that the manufacturer offers firmware with their downstream kernel, which is expected to be not so robust. In such a case, only knowing that its version is, sometimes, not enough. Could you please tell that what the device is and do the manufacturer offers the source code of their downstream kernel?

a firmware update would be a one-way operation, so I'd lose the ability to further investigate or test potential fixes against this current kernel version.

I don't think the manufacturer will apply a strict downgrade restriction (e.g. e-fuse). If it deserves a try to you, dump the ROM with a flasher and it should be able to be used to flash it back at any time.

Trying the GODEBUG options suggested by @mknyszek:

GODEBUG=gccheckmark=1 (looks for bugs in concurrent GC)

No change in behavior -- 48% failure rate across 25 test runs; same panics as before.

GODEBUG=gcshrinkstackoff=1 (disables stack shrinking, since this looks potentially like some kind of stack corruption)

No change in behavior -- 32% failure rate across 25 test runs; same panics as before.

GODEBUG=asyncpreemptoff=1 (disables asynchronous preemption signals, just because)

Aha! No panics across 25 test runs. Whatever this is doing, it seems to avoid causing the conditions that lead to the panic.

@racingmars That suggests to me a possible kernel bug. We've seen both Linux and Illumos (Illumos-derivative? and maybe some BSD variant but I forget) kernel bugs with issues in their signal delivery implementation. Usually something very subtle like a page fault in the signal handler causing a register's state to not get properly restored.
What GODEBUG=asyncpreemptoff=1 is disabling is a mechanism that uses OS signals to preempt running goroutines. This makes Go programs deliver signals to themselves much more frequently than other applications typically would. As a result, it's had a habit of triggering latent bugs in kernel implementations.
It's possible it's still an issue on the Go side, as we have of course discovered bugs in this path since it was released in Go 1.14. But a firmware/kernel upgrade might be sufficient to just solve your problem. Also, if GODEBUG=asyncpreemptoff=1 is a sufficient workaround, I suggest following through with that in the meantime. The downside is you might lose some performance.

Thanks @mknyszek -- (and cc @Rongronggg9 regarding firmware/kernel update)
I've ordered a second device of the same model (sorry I can't say what it is, but since it's security-related and due to organization paranoia I'm restricted from saying what it is in a public forum) so I'll be able to upgrade the firmware on that one without risking losing the reproducible test case on this 3.15.0 kernel version in case that's useful in the future.
It'll be about a week before it arrives, probably, but I'll follow up with a report on whether or not upgrading makes the problem go away.
Thanks!

Sorry for the delay in the follow-up, but I was able to get more hardware and investigate this further.
On another device with the same kernel version (3.15.0), the problem was reproducible, so it wasn't due to bad hardware on the first device.
After upgrading to the next oldest firmware version available to me, which uses kernel version 4.4.27, the problem is no longer reproducible. The test Go program and my real application run 100% reliably. So it does appear something was fixed in the mipsle kernel along the way related to how Go is depending on signals.
If folks come across this issue by searching for the error message in the future, the summary is:

Upgrade to a newer kernel to fix the problem, if possible.
Otherwise, setting the environment variable GODEBUG=asyncpreemptoff=1 as a work-around will allow the program to run reliably but with a performance penalty on older kernel versions.


Can hours be omitted from a day in the timeline?

More of a question really. I would like to know if it were possible to omit certain hours from within a day in the timeline.
For example I would like to build out a calendar view that contain events. This timeline will only show  for each day starting from an hour that the first event is at and ending when the last event that day is over.
For example:
Day 1:
  2 events:
     Event A: starts from 10AM, ends at 2PM
     Event B: starts from 3PM ends at 6PM

Day 2:
  2 events:
     Event A: starts from 12PM, ends at 4PM
     Event B: starts from 4PM ends at 5PM

The timeline would only show hours from 10AM to 6PM for day 1, and the timeline would show only hours 12PM to 5PM for day 2. I'm going through the docs but I can't seem to find any combination of props for which I could achieve the above scenario.
Am I missing something?
Thanks!

While this request is for flexible time-frames per day, I'd like to know if some kind of fixed time-frame is possible. Kind of like working-hours, where you specify when the day starts/ends (08:00-18:00) and hours outside of that window are not shown.

Hey! Right now, this is not possible and it would require some bigger changes to the timeline to work. But it's not theoretically impossible :).
The timeline treats time as a continuously flowing number of milliseconds (from the UNIX Epoch). The internals of the timeline rely on this number being continuous and make the assumption that the same difference in time is always the same difference in pixels (width).
To make it jagged - skipping a few hours here and there - would break this assumption and greatly complicate the code of the timeline.
However, what could work instead is to replace the unix time with a different continuous number, where the meaning to each millisecond is attributed externally from the calendar. So for example t=0 is today at 1pm, t=3599 is today at 2pm-1sec, but t=3600 is today at 6pm. (2pm to 4pm skipped).
We seem to only use the moment functions moment(time), .startOf('day'), .valueOf(), .add(1, 'hour') and .day() (to get the weekday).
You would need to reimplement those functions, find a way to hot-swap them with the regular moment library and possibly rewrite the time-related functions in utils.js (iterateTimes, getMinUnit, getNextUnit).
Should be fun 😀
If anyone wants to work on it, please go ahead! I can provide guidance... but since we don't need it for anything we're building ourselves, we're not going to invest time in this.

Closing due to inactivity and narrowness of feature request

Hey there ! @mariusandra would you still provide guidance if i decided to work on this feature ? :)

Hi @maxsd , I'm unfortunately not involved with this library anymore and don't have time to help. Good luck!


adding multi language support

I want to add multi language support system to the website which can help us understand in their native language.
@tushargupta1504 can you assign me this issue.

I would like to work on this issue. Could you please assign me this task


version to setup environment

Hi, I tried installing with 2 versions torch-2.0.1  and torch 1.12.1 but I faced lib errors and not easy to fix. Can you provide a stable version that you can run before?
thanks

For torch-2.0.1

@tuongtranngoc The torch-2.0.1 and torch1.12.1 is a stable version that I developed with. Could you please paste the lib error message, let's see what I can figure out


Add cask for DataGrip 1.0

Thank you for the contribution. It needed some fixes, so they were made in 4db3f936c7d1f6a5c90eaf49766ba9473983e801. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.

@adityadalal924 Hi, thanks for including that. Just out of curiosity, was that "audit" done by some tool or you in person? I ask cause I've ran rubocop and got no errors.
What was fixed is a removal of a blank newline. If that's the case, https://github.com/caskroom/homebrew-cask/blob/master/CONTRIBUTING.md is also wrong as examples there do care about blank lines. I didn't spot any more differences. Was that the case?

rubocop won't throw up any errors, but our convention has been to put a blank line between shasum and url, for readability.
You are correct in that I don't think any of the stylistic conventions are formally written down anywhere (but it's basically empty line after shasum, and empty line between stanzas). However, if you use brew cask create, it will use that format automatically.
We'll look into adding that to the contributing document to clarify things for further PRs where people create the Cask file manually.


Don't log command failures in EjsonSecretProvisioner

In all cases other than secret_exists?, we already raise an error with the stderr text if the command fails, making the failure logging redundant. And for secret_exists? we don't want to log an error on failure, because the failure is very likely 404. Here's an example of the useless warning this gets rid of:

I guess there's no way to just filter out the 404?
code lgtm

Other than scanning the err text for NotFound, not so much. 😞


QUESTION: Move buffer left/right?

Hi,
Is there a way to move the buffer left/right? I’ve read the docs but didn't see a way to do so. Thanks.

You can switch a buffer w/ the previous or next buffer, or with any other buffer by mapping <Plug>(cokeline-switch-prev), <Plug>(cokeline-switch-next), <Plug>(cokeline-switch-i). See Mappings for more infos.


AllowClear decorator throws exception when no placeholder is specified

There is no null check on placeholder property, so if you do clear select2 without placeholder set an this.placeholder is undefined exception is thrown:
selection/allowClear.js
    this.$element.val(this.placeholder.id).trigger('change');

Or maybe placeholder was meant to be required in combination with allowClear: true

This was handled in https://github.com/select2/select2/issues/3016, placeholder is meant to be required with allowClear: true for now.


Nephilim Legende: code refactoring, new incarnation periods and a bugfix

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: <   >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: <   > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: <   > (i.e. Dungeons & Dragons, FATE)

[ ] I have followed the Character Sheets Standards when building this sheet.

[ ] This sheet has been made on behalf of, or by, the game's publisher.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description

Code refactoring. In fact the entire sheet has been put under Pug and Sass languages
Added missing incarnation eras
Added dates to all incarnation eras
Fixed a rolltemplate bug on some dice rolls

Character Sheet Info Roll20 Internal Use only.

Hello @NorWhal ,
I confirm the two points. I took a special care on quality checks and no data should be lost by users.
Thank you for your consideration.


 Change primary term label to sexually aggressive behavior, using sexually aggressive behaviour as a synonym.

Done.


Toolbar cann't display full when ckeditor is full screen

If you have a question, you can ask the official RailsAdmin mailing list: https://groups.google.com/forum/#!forum/rails_admin
The issue tracker is for issues only. Large number of questions makes it unmaintainable.
Thanks!


rustus: 0.7.4 -> 0.7.6

https://github.com/s3rius/rustus/releases/tag/0.7.6
Description of changes
adds the ability to download a file by name.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 266523 run on x86_64-linux 1
1 package built:

rustus


Unable to compile develop

Running make results in
error[E0433]: failed to resolve: use of undeclared crate or module `multihash`
  --> /Users/dignifiedquire/.cargo/registry/src/index.crates.io-6f17d22bba15001f/multihash-0.18.1/src/multihash_impl.rs:11:34
   |
11 | #[derive(Copy, Clone, Debug, Eq, Multihash, PartialEq)]
   |                                  ^^^^^^^^^ use of undeclared crate or module `multihash`
   |
   = note: this error originates in the derive macro `Multihash` (in Nightly builds, run with -Z macro-backtrace for more info)

You could try to add the multihash-impl feature to multihash in the Cargo.toml.

additional note: it seems to only fail on macos, and not on linux 🤷

after nuking my clone (which was already fresh) and redoing the setup it now works..no idea what the problem was

hmm, I've never seen this on a fresh clone but haven't tried on mac... @avichalp does this ring a bell?

Not sure what happened there. I just did a fresh clone on MacOS 14.2.1 and it worked fine.


Recommanded URITemplate extraction method?

Hi,
I don't see any URITemplate extraction method... did I miss it or is there a recommanded companion to do it, please?

I have seen the alternatives in your readme (uri-template & uri-templates) but I prefer to use yours.

What exactly do you mean by "URITemplate extraction method"?

Extract some values from an URI, based on the template, a few like this: https://github.com/rezigned/uri-template.js#extraction

extraction is not covered by RFC6570 and therefore wasn't implemented in URI.js

It's ok but why not a URI.js "companion" using your template structure? :)


fix: flicker when starting pan: panOffset value race condition

What: the bug
When onGestureUpdate is called, it may be using the previous value for panOffset (rather than the value just set in onGestureStart). This seems to cause a flicker on slow devices since a translation is shown that is from a different screen.
I see this flicker most obviously on my Android simulator (please see video demonstration below), but the problem exists on other devices as well.
Why
This is due to updates to shared values created via useSharedValue() updating asynchronously (see https://docs.swmansion.com/react-native-reanimated/docs/core/useSharedValue/#remarks ).
This flicker seemed to get worse after this commit https://github.com/dohooo/react-native-reanimated-carousel/commit/b654f439e905bc1d45f5cbb1fd291f3a82848368 - "feat: replaced onScrollBegin with onScrollStart" (I'm not sure if there's a corresponding PR?).
This is due to the order of the handlers being triggered: onBegin then onStart then onUpdate ...

Before this commit, the panOffset was saved during onBegin -- which would often happen much longer before onUpdate.
After this commit, the panOffset is saved during onStart -- which might happen immediately before onUpdate and thus may not allow enough time for the asynchronous update to occur.

What: proposed fix
Let's add a check to make sure that panOffset has a valid value before we try to use it.

When a pan is not active, panOffset will have a value of undefined.
(Upon pan start, in onGestureStart, set panOffset to its correct value. This is not a change from existing code.)
In onGestureUpdate and onGestureEnd, check to ensure that panOffset is not undefined before attempting to use it.
In onGestureEnd, reset panOffset to undefined (since pan is no longer active).

Screengrab video recordings
These recordings were taken on an Android simulator.
buggy behavior on 4.0.0-alpha.10 (unpatched)
Notice the flicker to a different "page" when starting pan (i.e. starting touch).
https://github.com/dohooo/react-native-reanimated-carousel/assets/589004/94d33111-2d01-42af-a182-458e83e4d086
improved behavior with patch
https://github.com/dohooo/react-native-reanimated-carousel/assets/589004/f3cd5968-136e-433b-b5ce-152bf4720dc9

@nmassey have you found a workaround while you wait this to be merged? I have a release blocked because of this (I guess)

@nmassey have you found a workaround while you wait this to be merged? I have a release blocked because of this (I guess)

I use yarn patch to get this in (along with a couple of other tweaks I have).
Are you on the Discord?

@nmassey I just joined that Discord, but if you can share the patch here, will be awesome!

I had created and applied this patch, but it doesn't fix the issue I mention in https://github.com/dohooo/react-native-reanimated-carousel/issues/590 (which I thiiiink it's the same as you are trying to fix here)
diff --git a/node_modules/react-native-reanimated-carousel/src/components/ScrollViewGesture.tsx b/node_modules/react-native-reanimated-carousel/src/components/ScrollViewGesture.tsx
index 41e39b4..f71128f 100644
--- a/node_modules/react-native-reanimated-carousel/src/components/ScrollViewGesture.tsx
+++ b/node_modules/react-native-reanimated-carousel/src/components/ScrollViewGesture.tsx
@@ -65,7 +65,7 @@ const IScrollViewGesture: React.FC<PropsWithChildren<Props>> = (props) => {
   const maxPage = dataLength;
   const isHorizontal = useDerivedValue(() => !vertical, [vertical]);
   const max = useSharedValue(0);
-  const panOffset = useSharedValue(0);
+  const panOffset = useSharedValue<number | undefined>(undefined); // set to undefined when not actively in a pan gesture
   const touching = useSharedValue(false);
   const validStart = useSharedValue(false);
   const scrollEndTranslation = useSharedValue(0);
@@ -290,6 +290,20 @@ const IScrollViewGesture: React.FC<PropsWithChildren<Props>> = (props) => {
   const onGestureUpdate = useCallback((e: PanGestureHandlerEventPayload) => {
     "worklet";

+    if (panOffset.value === undefined) {
+      // This may happen if `onGestureStart` is called as a part of the
+      // JS thread (instead of the UI thread / worklet). If so, when
+      // `onGestureStart` sets panOffset.value, the set will be asynchronous,
+      // and so it may not actually occur before `onGestureUpdate` is called.
+      //
+      // Keeping this value as `undefined` when it is not active protects us
+      // from the situation where we may use the previous value for panOffset
+      // instead; this would cause a visual flicker in the carousel.
+
+      // console.warn("onGestureUpdate: panOffset is undefined");
+      return;
+    }
+
     if (validStart.value) {
       validStart.value = false;
       cancelAnimation(translation);
@@ -334,6 +348,10 @@ const IScrollViewGesture: React.FC<PropsWithChildren<Props>> = (props) => {
   const onGestureEnd = useCallback((e: GestureStateChangeEvent<PanGestureHandlerEventPayload>, _success: boolean) => {
     "worklet";

+    if (panOffset.value === undefined) {
+      return;
+    }
+
     const { velocityX, velocityY, translationX, translationY } = e;
     scrollEndVelocity.value = isHorizontal.value
       ? velocityX
@@ -379,6 +397,8 @@ const IScrollViewGesture: React.FC<PropsWithChildren<Props>> = (props) => {

     if (!loop)
       touching.value = false;
+
+    panOffset.value = undefined;
   }, [
     size,
     loop,

I had created and applied this patch, but it doesn't fix the issue I mention in #590 (which I thiiiink it's the same as you are trying to fix here)
...

In addition to patching the source code, you'll also need to patch the relevant built lib/ files in the plugin. (When you use the plugin from your code, those are the actual JS files that get used.)
You can either patch the source code by hand (possible, but annoying), or patch the target plugin in its own repo and rebuild it to generate the relevant lib/ code (and then copy those files over). I sent some instructions for how I do this on Discord.
Note that you can confirm that your patch is running by adding some easily-recognizable code to the relevant lib/ file. e.g. you can add console.log('hello 123') to a specific lib/ file to make sure that it is getting executed in your local development build.
I hope this helps! 🤓🙏 And, catch you on Discord!

@nmassey can you please share the versions of all the packages you are using?
I applied your PRs but still some small issues (which we talked in Discord) and I'm thinking it may be related to other libraries' versions

when it would be released? 😄

Incredible work, thank you! But before merging, could you gen a changeset for this PR?
npx changeset

I also see this problem on both emulator and real devices, but only android.

When will this patch be released?

Waiting for this patch sooo much too!

Any update for this issue? Would be nice to start using 4.0 but Alpha 12 still has flickering issues.

@dohooo any chance this can be merged soon?

Subscribing to know when this is merged.
Going back to old RNCarousel temporarily 🥺

hi @Crizzooo -  I've been using yarn patch to unblock me while waiting for these PRs to be merged 😕
Are you on the Discord?


Provide larger flags image and styles for mobile rendering

Can someone provide a larger flags image with the corresponding styles changed? The desirable size of each flag is at least 32x22 (double of what is already provided). The current image is too small for mobile.
Thanks!

You can create your own images and pass the path as a prop. This is not an issue with the component.


Fix "None" in ModelFilter

Somehow, while clicking on "None" in ModelFilter, program throws error saying that [] operator is out of range


Do not distribute test files

No longer distribute the test files.

I created this due problens with the conda-forge feedstock but @nicoddemus fixed the recipe without need to change this repo.


move doc on wiki to repo

let's move all pages on the wiki inside this repo (new doc folder), and replace the links on the wiki homepage to links to the repo (as done for INSTALL.md).
Move all documentation files inside doc

This will make things easier for keeping track of everything, for renaming, and for transitioning this into the SIRF-Superbuild


Feature/cleanup

Add .editorconfig for consistency
Implement IDisposable to clean up source stream
Enable additional code analysis (AnalysisMode = Recommanded)
Clean syntax, resolve additional warnings from above analysis

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

20 of 21 (95.24%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.06%) to 95.294%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

LineReader/LineReader.cs
20
21
95.24%

Totals

Change from base Build<PHONE_NUMBER>9:
0.06%

Covered Lines:
52

Relevant Lines:
53

💛  - Coveralls


new docs for provider

Thank you @heitorPB for the review! I've fixed the things.
@omerlavanet have a look, it's a beauty now with tabs and highlights :)


Interactive model editing actions and behaviours.

This PR adds a core of actions and behaviours that allow for the manual editing and curation of a model. It's the leading branch in current network, and is already merged with resize-spot-action and model-edit-actions.
The next steps will require the refactoring on how a model is modified in a view.

The finder-like and midnight-commander-like navigation behaviour should go in one class, and the UI should be able to switch from one to another.


Update bootstrapper

This Repo still needs the updated bootstrappers.

@ryanbrandenburg,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

Yeah, it wasn't on the list that I use to mass update repos, it should be now.


Fails to launch with 1.5.0

Getting the following error on startup with version 1.5.0, 1.4.0 seemingly did not have this
When disabling Fuzzy, game starts without issues

Hi @Boy0000, thanks for the report! I'll look into this.
As I currently cannot reproduce the error, can you give me the following information?
Did you use version 1.4.0 before upgrading to 1.5.0? What Minecraft Version do you use? Can you show me your fuzzy.json config? (.minecraft/config/fuzzy.json)

I believe i used 1.4.0 first, but not too sure
Reverting to 1.4.0 right nbow launches everything fine
1.20.2
config from 1.4.0 successfull boot

{
  "fuzzySearchCutoff": 0,
  "fuzzySearchLimit": 100,
  "clearOnJoin": false,
  "showScore": true,
  "enableShiftActions": true,
  "enableCommandBlockSync": true
}

Thanks! I'll let you know when I've fixed it.

Sidenote: Updating to 1.5.0 and deleting fuzzy.json did not fix the problem, same error

I have released v1.5.1, please let me know if this fixed your problem :)
https://modrinth.com/mod/fuzzy/version/OcrCANmL

seems to have fixed it! thanks for the quick fix 👍 love the mod

awesome, thank you!


prevent from undefined value for deltaX and deltaY

If the first event fired on scrollArea was click, the scrolling will die due to NaN is passed to top/left position state. This PR is trying to fix this issue.

Hi,
It look nice. I'll merge it in a few days.

Hi,
You are welcome. Hope it could make some helps ;)
Happy coding ~

On 9 Apr 2016, at 2:17 AM, Jakub Kłobus<EMAIL_ADDRESS>wrote:
Hi,
It look nice. I'll merge it in a few days.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/souhe/reactScrollbar/pull/37#issuecomment-207543670

What's the status w/ merging this?