Will this be re-opened or should we create a new issue to repeat the request?

lldb against the brew-installed version seems to show it crashing in drawMessage

Process 80635 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x18ac3dd8c)
    frame #0: 0x000000018ac3dd8c libsystem_c.dylib`__chk_fail_overlap + 24
libsystem_c.dylib`__chk_fail_overlap:
->  0x18ac3dd8c <+24>: brk    #0x1

libsystem_c.dylib`__memccpy_chk:
    0x18ac3dd90 <+0>:  pacibsp
    0x18ac3dd94 <+4>:  stp    x22, x21, [sp, #-0x30]!
    0x18ac3dd98 <+8>:  stp    x20, x19, [sp, #0x10]
Target 0: (cbonsai) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x18ac3dd8c)
  * frame #0: 0x000000018ac3dd8c libsystem_c.dylib`__chk_fail_overlap + 24
    frame #1: 0x000000018abcc60c libsystem_c.dylib`__chk_overlap + 48
    frame #2: 0x000000018abcd8c4 libsystem_c.dylib`__strncat_chk + 112
    frame #3: 0x00000001000064d4 cbonsai`drawMessage + 348
    frame #4: 0x0000000100007074 cbonsai`main + 1280
    frame #5: 0x000000018a9b0274 dyld`start + 2840
(lldb)

It is really odd that the version I compiled myself is working OK.

I made the following patch to clean up a compilter warning, and to try to avoid the same issue in drawMessage FWIW.

--- a/cbonsai.c
+++ b/cbonsai.c
@@ -567,8 +567,9 @@ int drawMessage(const struct config *conf, struct ncursesObjects *objects, char*
                // append this character to word buffer,
                // if it's not space or NULL and it can fit
                if (!(isspace(thisChar) || thisChar == '\0') && wordLength < (int) (sizeof(wordBuffer) / sizeof(wordBuffer[0]))) {
-                       strncat(wordBuffer, &thisChar, 1);
+                       wordBuffer[wordLength] = thisChar;
                        wordLength++;
+                       wordBuffer[wordLength] = '\0';
                        linePosition++;
                }

@@ -624,7 +625,7 @@ int drawMessage(const struct config *conf, struct ncursesObjects *objects, char*

                if (conf->verbosity >= 2) {
                        updateScreen(1);
-                       mvwprintw(objects->treeWin, 11, 5, "word buffer: |% 15s|", wordBuffer);
+                       mvwprintw(objects->treeWin, 11, 5, "word buffer: |%15s|", wordBuffer);
                }
                if (thisChar == '\0') break;    // quit when we reach the end of the message
                i++;

I find that the version of cbonsai installed from homebrew crashes with the -m flag.

[1] 60885 trace trap cbonsai -m hello

However, building it myself locally, it works fine. M1 Pro here.

This page refers to a binary lg which I am unable to locate in the Fedora repositories. Could this either be improved to describe how to install this tool, or the reference removed? Thank you.

Andy Piper (866f9e20) at 26 Sep 19:25

The instructions in the README are incorrect - it should be

git clone https://gitlab.com/dedSyn4ps3/enviroplus-dashboard.git

Confirming that I've tested the revised downloader script on 7.2.2 and this is now working (I have not tried the updates to the copy script / overlay stuff, I just wanted to grab some TIC-80 content!)

The current installed version of mosquitto shipped in 7.2.2 is vulnerable to CVE-2019-11779. Please update to a more recent 2.x version.

Currently, recalbox ships a very old an insecure version of mosquitto.

Please update this to the 2.x version of mosquitto and the associated Paho client.

OK, I think I’ve got it. Setting the Zeroconf module to only use the Default interface seems to be the trick for me. Leaving it to use the default setting as in the code, i.e. All interfaces, causes the discovery to seemingly never return.

In my case:

zeroconf = Zeroconf(interfaces = InterfaceChoice.Default)

followed by a ServiceBrowser discovery of ._elg._tcp.local. returns instantly.

Annoying because clearly this may not be the case in every network topology, but it is definitely an issue here.

I am having no issues using pyleglight when I provide an IP address, but I’m fighting with the discovery piece. Even at a long timeout, it never seems to populate the response data on a call to discover().

I’ve been trying to walk it through in the Python REPL using the zeroconf module, and it seems a bit tricky - I only get a response after a second command is issued. I’m trying to narrow this down. Have you seen anything similar?