IDE 2.3.6 hangs in Ubnuntu 22.04 with MATE

Development Tools IDE 2.x
1

Recently installed 2.3.6, after using 1.x (whatever latest was in Snap) without trouble for years. Upgraded so that I could not be in sandbox and work with ESP8266 boards.

In any case, the simplest sketches to either Uno R3s or ESP8266 boards compile and upload fine but at that point using the IDE becomes impossible to use (lag time between keystrokes and response, mouse events and response), the serial output window never updates and I end up having to kill the IDE via pkill.

Downgraded to 2.3.2 after seeing issues regarding ESP8266 with 2.3.6 but IDE still hangs.

I will add that compiling and uploading to both boards work fine via arduino-cli so issue is in IDE.

Thanks for any pointers to get this working.
Cheers

2

Hi @opalko. Please try this experiment and then report the results:

:red_exclamation_mark: This procedure is not intended to solve the problem. The purpose is to gather more information.

  1. Select File > Examples > 01.Basics > BareMinimum from the Arduino IDE menus.
    The "BareMinimum" example sketch will open in a new Arduino IDE window.
  2. Upload the sketch to your ESP8266 board as usual.
  3. Wait for the upload to finish successfully.

Please add a reply here on this forum topic to tell us whether the problem with the responsiveness of the Arduino IDE UI still occurs when the board is running this "BareMinimum" sketch.

ⓘ In this experiment, the "BareMinimum" sketch is serving as a "known good" sketch that doesn't contain any code that might cause performance problems If the problem occurs when your real sketch is running on the board, but doesn't occur when "BareMinimum" is running on it, then we will know for certain that the problem is caused by something in the real sketch's code and we can focus our attention exclusively on identifying the problematic code.

3

Thanks! Well, this is interesting. I tried the BareMinimum sketch and it compiled and uploaded without issue and without any locking up of the IDE. I then loaded the sketch I tried before and it worked fine also. I had made no changes to the code (below). One weird thing that happened is that the first time I ran my sketch after the BareMinimum one was that the IP address was echoed back on the serial monitor continuously (with an increasing timestamp) even though it shouldn’t. I pressed the reset button on the ESP8266 and this time it ran and echoed the IP address only once. I’m perplexed at both of these odd behaviors which only happened with the IDE.

#include <ESP8266WiFi.h>
const char* ssid     = "NoThisIsntMySSID";
const char* password = "ThisIsntMyPasswordEither";

void connectWiFi() {
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  unsigned long start = millis();
  while (WiFi.status() != WL_CONNECTED && millis() - start < 15000) {
    delay(250);
  }
}

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(115200);
  Serial.println("Starting...");
  Serial.println("Starting...");
  Serial.println("Starting...");
  connectWiFi();
  if (WiFi.status() == WL_CONNECTED) {
    Serial.print("IP: "); Serial.println(WiFi.localIP());
  } else {
    Serial.println("WiFi connect timeout");
  }
}

void loop() {
  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN)); delay(500);
}
4

Thanks for the update! Even though it is not as satisfying as finding an explanation for the problem, I guess we can be happy enough that the problem is no longer occurring.

If it comes back later, let us know and we'll see if we are able to investigate further.

My hypothesis was that the problem was caused by this bug:

Your sketch code is correctly configured to add appropriate newlines so that no problematic long line would be produced. It is maybe possible that such code could still result in content without newlines in the case where the serial data is being corrupted due to a mismatch between the baud rate of the sketch program and that configured in Serial Monitor (which can produce gibberish output in Serial Monitor depending on the conditions). However, even then I would not expect the bug to be encountered as your code only produces a small quantity of output, which would not be problematic even if all on a single line.

Your statement about the program producing continuous output does move things back towards the realm of my hypothesis being plausible. However, but your comment on timestamps does indicate that line breaks were being produced, and the bug is only known to cause problems in the case where there are long lines. There is no problem with handling large quantities of reasonable length lines.