Problem mit macOS Monterey

compactflash · 1. November 2021 um 15:49

Hallo , ich dachte ich werde wahnsinnig … weil alle meine fertigen Boards ca. alle 10 Sekunden booten . Nicht nur die aktuell geflashten sondern auch ältere Versionen die immer funktioniert haben .
Bin gerade dahinter gekommen das es an meinem neuen iMac24 nach dem Update am letzten Donnerstag auf macOS Monterey liegt , vorher mit Big Sur war es nicht . Mein alter iMac mit High Sierra und die iPhones haben das Problem auch nicht .
Das passiert auch wenn das Fenster garnicht aktiv geöffnet ist . Hat richtig Spass gemacht . Board neu geflasht und dann Dauerreboot . Wer denkt da an eine aktive Verbindung im Hintergrund zu Safari ? Hat mich 3 Tage gekostet .
Kann das jemand nachvollziehen ?

VG

tueddy · 1. November 2021 um 16:12

Ist es das gleiche Problem wie in diesem Thread beschrieben?

compactflash · 1. November 2021 um 16:25

Hi , danke für den Hinweis, das hatte ich in meiner „Panik“ total vergessen .

biologist · 1. November 2021 um 17:32

Also irgendwas verkackt Apple da gerade.
Mindestens unter 10.15.7 stürzen Safari und auch Firefox ab, wenn man die Seite dieser Bank aufruft: https://www.sparda-sw.de. Ich dachte erst an einen Hardware-Defekt, wir haben das Problem hier aber gleich auf zwei Macs und nachdem ich im Macuser-Forum mal gefragt hatte, konnte dort jmd. vom gleichen Problem berichten.

Keine Ahnung was da los ist. Tritt erst seit ein paar Tagen auf.

tueddy · 1. November 2021 um 21:07

Das ist wohl ein Problem mit dem aktuellen WebKit, daher Crash sowohl in iOS und macOS. Funktioniert es denn Ihr in macOS Montery Setting safari =>Advanced=>Experimental Features=>NSURLSession WebSocket to off solves the issue ausschaltet? Das wäre zumindest ein kurfristiger Workaround. Kann das hier nicht testen weil ich mit dem macOS Update noch warte (aus Erfahrung )
Mir war auf iOS aufgefallen das der ESPuino schon crasht wenn man „espuino.local“ nur anfängt zu tippen. Safari lädt dann die Seite schon im Hinterggrund vor um sie dann schneller anzueigen.

compactflash · 1. November 2021 um 21:15

Ja , dann geht es

compactflash · 1. November 2021 um 21:20

Das ist bei Monterey auch so

tueddy · 1. November 2021 um 21:37

Um der Ursache auf den Grund zu gehen hier der dekodierte Backtrace:

CORRUPT HEAP: multi_heap.c:431 detected at 0x3ffee674
abort() was called at PC 0x4009b3b4 on core 1

ELF file SHA256: 0000000000000000

Backtrace: 0x400963ac:0x3ffe9d30 0x40096625:0x3ffe9d50 0x4009b3b4:0x3ffe9d70 0x4009ba8c:0x3ffe9d90 0x40082a19:0x3ffe9db0 0x40082a4a:0x3ffe9dd0 0x4008aea1:0x3ffe9df0 0x4000beaf:0x3ffe9e10 0x4010a3d4:0x3ffe9e30 0x400df05d:0x3ffe9ed0 0x4023b49f:0x3ffe9f00 0x4023c91d:0x3ffe9f20 0x400ff7c5:0x3ffe9f70 0x400ff7e1:0x3ffe9fb0 0x40106abe:0x3ffe9fd0 0x40106b41:0x3ffea010 0x401072b6:0x3ffea030 0x40098076:0x3ffea060
  #0  0x400963ac:0x3ffe9d30 in invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
  #1  0x40096625:0x3ffe9d50 in abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
  #2  0x4009b3b4:0x3ffe9d70 in multi_heap_assert at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/multi_heap.c:380
      (inlined by) multi_heap_malloc_impl at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/multi_heap.c:431
  #3  0x4009ba8c:0x3ffe9d90 in multi_heap_malloc at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/multi_heap_poisoning.c:305
  #4  0x40082a19:0x3ffe9db0 in heap_caps_malloc at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/heap_caps.c:354
  #5  0x40082a4a:0x3ffe9dd0 in heap_caps_malloc_default at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/heap_caps.c:354
  #6  0x4008aea1:0x3ffe9df0 in _malloc_r at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/newlib/syscalls.c:37
  #7  0x4000beaf:0x3ffe9e10 in ?? ??:0
  #8  0x4010a3d4:0x3ffe9e30 in Print::printf(char const*, ...) at C:\users\dirk\.platformio\packages\framework-arduinoespressif32\cores\esp32/Print.cpp:261
  #9  0x400df05d:0x3ffe9ed0 in onWebsocketEvent(AsyncWebSocket*, AsyncWebSocketClient*, AwsEventType, void*, unsigned char*, unsigned int) at .pio/libdeps/ttgo_t8/ArduinoJson/src/ArduinoJson/Deserialization/DeserializationError.hpp:20
  #10 0x4023b49f:0x3ffe9f00 in std::_Function_handler<void (AsyncWebSocket*, AsyncWebSocketClient*, AwsEventType, void*, unsigned char*, unsigned int), void (*)(AsyncWebSocket*, AsyncWebSocketClient*, AwsEventType, void*, unsigned char*, unsigned int)>::_M_invoke(std::_Any_data const&, AsyncWebSocket*&&, AsyncWebSocketClient*&&, AwsEventType&&, void*&&, unsigned char*&&, unsigned int&&) at c:\users\dirk\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\5.2.0/functional:1871
  #11 0x4023c91d:0x3ffe9f20 in std::function<void (AsyncWebSocket*, AsyncWebSocketClient*, AwsEventType, void*, unsigned char*, unsigned int)>::operator()(AsyncWebSocket*, AsyncWebSocketClient*, AwsEventType, void*, unsigned char*, unsigned int) const at .pio\libdeps\ttgo_t8\ESP Async WebServer\src/StringArray.h:53
      (inlined by) AsyncWebSocket::_handleEvent(AsyncWebSocketClient*, AwsEventType, void*, unsigned char*, unsigned int) at .pio\libdeps\ttgo_t8\ESP Async WebServer\src/AsyncWebSocket.cpp:864
  #12 0x400ff7c5:0x3ffe9f70 in AsyncWebSocketClient::_onData(void*, unsigned int) at .pio\libdeps\ttgo_t8\ESP Async WebServer\src/StringArray.h:53
  #13 0x400ff7e1:0x3ffe9fb0 in std::_Function_handler<void (void*, AsyncClient*, void*, unsigned int), AsyncWebSocketClient::AsyncWebSocketClient(AsyncWebServerRequest*, AsyncWebSocket*)::{lambda(void*, AsyncClient*, void*, unsigned int)#7}>::_M_invoke(std::_Any_data const&, void*&&, AsyncClient*&&, std::_Any_data const&, unsigned int&&) at .pio\libdeps\ttgo_t8\ESP Async WebServer\src/StringArray.h:53
      (inlined by) _M_invoke at c:\users\dirk\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\5.2.0/functional:1871
  #14 0x40106abe:0x3ffe9fd0 in std::function<void (void*, AsyncClient*, void*, unsigned int)>::operator()(void*, 
AsyncClient*, void*, unsigned int) const at .pio\libdeps\ttgo_t8\AsyncTCP@src-7fb2940bccb78b8d2de6915ae328b7fc\src/AsyncTCP.cpp:1116
      (inlined by) AsyncClient::_recv(tcp_pcb*, pbuf*, signed char) at .pio\libdeps\ttgo_t8\AsyncTCP@src-7fb2940bccb78b8d2de6915ae328b7fc\src/AsyncTCP.cpp:934
  #15 0x40106b41:0x3ffea010 in AsyncClient::_s_recv(void*, tcp_pcb*, pbuf*, signed char) at .pio\libdeps\ttgo_t8\AsyncTCP@src-7fb2940bccb78b8d2de6915ae328b7fc\src/AsyncTCP.cpp:1116
  #16 0x401072b6:0x3ffea030 in _async_service_task(void*) at .pio\libdeps\ttgo_t8\AsyncTCP@src-7fb2940bccb78b8d2de6915ae328b7fc\src/AsyncTCP.cpp:1116
      (inlined by) _async_service_task at .pio\libdeps\ttgo_t8\AsyncTCP@src-7fb2940bccb78b8d2de6915ae328b7fc\src/AsyncTCP.cpp:197
  #17 0x40098076:0x3ffea060 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)

Rebooting...
ets Jun  8 2016 00:22:57

Bin da jetzt kein Experte aber es sieht doch so aus als ob der Crash ausgelöst wird durch die JSON Deserialisierung in bool processJsonRequest(char *_serialJson). Sollte sich das im Code nicht abfangen lassen?

tueddy · 2. November 2021 um 16:27

Evt. habe ich eine Lösung, getestet hier mit Safari auf iOS 15.1:
Die Zeile mit client->ping(); in Web.cpp auskommentieren:

void onWebsocketEvent(AsyncWebSocket *server, AsyncWebSocketClient *client, AwsEventType type, void *arg, uint8_t *data, size_t len) {

    if (type == WS_EVT_CONNECT) {
        //client connected
        Serial.printf("ws[%s][%u] connect\n", server->url(), client->id());
        //client->printf("Hello Client %u :)", client->id());
        //client->ping();

Ich habe dann keinen Crash mehr. Der neue Safari schließt wohl das Websocket und der Ping geht dann auf einen nicht mehr vorhandenen Client? Nebenwirkungen kann ich nicht feststellen. Könnt Ihr das bestätigen? Auch mit macOS Monterey?

compactflash · 2. November 2021 um 16:45

Sieht gut aus , es geht mit Monterey .

Das hier verstehe ich nicht , habe davon keine Ahnung . Habe nochmals einiges getestet und nichts negatives festgestellt . Gut gemacht .

biologist · 3. November 2021 um 08:06

So sehr ich von den aktuellen Macbook pros begeistert bin, so sehr muss ich auch konstatieren, dass auf Software-Ebene aktuell wieder viel Scheisse bei Apple passiert. Das hier ist schon wieder der nächste Bock: MacBook geht nicht mehr an: Apple-Updates können Firmware-Probleme bereiten | heise online.

Führe ich jetzt ein #define APPLE_GERAFFEL_WORKAROUND ein?

tueddy · 3. November 2021 um 15:11

@biologist: Ich würde kein zusätzlichen #define machen sondern einfach den client->ping(); auskommentieren. Wer weiß wann Apple das Problem behebt. Es sind ja jetzt schon mehrere Leute hier darüber gestolpert.
Ich sehe auch nicht ganz den Nutzen des Ping nachdem die Verbindung hergestellt wurde. Wozu ist der gut? Die Weboberfläche läuft auch ganz hervorragend ohne. Habe testweise den ESPuino in deep-sleep geschickt und wieder aufgeweckt. Auch dann wird die Verbindung zur Weboberfläche sauber wieder aufgebaut.

biologist · 3. November 2021 um 15:35

Das war auch mehr ein Spaß mit dem eigenen Define .
Ich selbst habe halt keine Möglichkeit es zu testen. Aber ich kann’s mal rausnehmen.

biologist · 3. November 2021 um 16:47

Here we go:

Christian · 3. November 2021 um 19:41

Wird auch nicht weiter genutzt. Das ist die Ping/Pong Funktion auf „Protokoll-Ebene“. Server → Client. Der Browser antwortet auch darauf.
Die Auswertung dieser Antwort könnte dann auch raus:

github.com

biologist79/ESPuino/blob/5b7b981d1311fc646baf277a0bfe37c39c2b218b/src/Web.cpp#L549


      
              //client connected
              Serial.printf("ws[%s][%u] connect\n", server->url(), client->id());
              //client->printf("Hello Client %u :)", client->id());
              //client->ping();
          } else if (type == WS_EVT_DISCONNECT) {
              //client disconnected
              Serial.printf("ws[%s][%u] disconnect\n", server->url(), client->id());
          } else if (type == WS_EVT_ERROR) {
              //error was received from the other end
              Serial.printf("ws[%s][%u] error(%u): %s\n", server->url(), client->id(), *((uint16_t *)arg), (char *)data);
          } else if (type == WS_EVT_PONG) {
              //pong message was received (in response to a ping request maybe)
              Serial.printf("ws[%s][%u] pong[%u]: %s\n", server->url(), client->id(), len, (len) ? (char *)data : "");
          } else if (type == WS_EVT_DATA) {
              //data packet
              AwsFrameInfo *info = (AwsFrameInfo *)arg;
              if (info->final && info->index == 0 && info->len == len) {
                  //the whole message is in a single frame and we got all of it's data
                  Serial.printf("ws[%s][%u] %s-message[%llu]: ", server->url(), client->id(), (info->opcode == WS_TEXT) ? "text" : "binary", info->len);
          
                  if (processJsonRequest((char *)data)) {

Aktuell ist ja ein Ping vom Client → Server implementiert.