new operator w/o (std::nothrow) aborts, when "Exceptions: disabled"

[mhightower83]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in the current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: ESP-12
• Core Version: [76cda9b]
• Development Env: Arduino IDE
• Operating System: Ubuntu

Settings in IDE

• Module: Adafruit HUZZAH

• Flash Mode: qio

• Flash Size: 4MB

• lwip Variant: v2 Lower Memory

• Reset Method: nodemcu

• Flash Frequency: 40Mhz

• CPU Frequency: 80Mhz

• Upload Using: SERIAL

• Upload Speed: 115200(serial upload only)

• Exceptions: Disabled

Problem Description

With "Exceptions: Disabled" selected from the Arduino IDE.
A build using the new operator without (std::nothrow) causes a crash, when out of memory.
Fails with "Abort called" and stack trace.
No opportunity to test for NULL.

This test sketch also fails with Arduino ESP8266 Core 2.5.0; however, it works (returns NULL) in Core 2.4.2.

And before rerunning each test, I did a git pull against the branch and ran ./get.py from the tools directory.

MCVE Sketch

void setup() {
  Serial.begin(115200);
  delay(20);
  Serial.printf("\nUp and running ...\n");
//  char *p = new (std::nothrow) char[128000];  // This will return NULL
  char *p = new char[128000];  //This fails with "Abort called" and stack trace

  if (p == NULL) {
    Serial.printf("\n\"new\" failed as it should! PASS!\n");
  } else {
    Serial.printf("\n\"new\" worked, it should not have!, FAIL!\n");
  }
}

void loop() {
}

Debug Messages

Up and running ...

Abort called

>>>stack>>>

ctx: cont
sp: 3ffffdd0 end: 3fffffc0 offset: 01b0
3fffff80:  40201d52 00000014 3ffee294 4020a4d4  
3fffff90:  3fffdad0 00000000 3ffee294 40201058  
3fffffa0:  feefeffe feefeffe 3ffee2bc 40201874  
3fffffb0:  feefeffe feefeffe 3ffe84f4 40100a41  
<<<stack<<<

last failed alloc call: 4020A504(128000)

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v76cda9bd
~ld


Decoding stack results
0x40201d52: delay(unsigned long) at /home/mhightow/Arduino/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_wiring.cpp line 57
0x4020a4d4: operator new[](unsigned int) at ../../../../../dl/gcc-xtensa/libstdc++-v3/libsupc++/new_opv.cc line 33
0x40201058: setup() at /home/mhightow/Arduino/test/nothrow3/nothrow3.ino line 14
0x40201874: loop_wrapper() at /home/mhightow/Arduino/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp line 129

This issue may be related to #6251 (comment)

[earlephilhower]

That's the correct, expected behavior. New still had a failure. It'll try and throw an exception, but the core will redirect it to an abort and the code will end (since it's really an unhandled exception).

No-exceptions mode just means your code isn't blown up by 2x by exception frames (ehxxx in the elf) and handler code.

[mhightower83]

Sorry, I guess I missed something somewhere. Dyslexia occasionally creates some reading comprehension issues for me. I just wanted to say, the need to add (std::nothrow), is new behavior for 2.5.0, which requires editing existing libraries that worked before.

In 2.4.2 and before we didn't need the (std::nothrow) to avoid the crash, abort. If the alloc failed, we just needed to follow up with a test for NULL.

[earlephilhower]

You're correct about earlier versions.

Unfortunately, while you were probably conscientious and checking for new failure I would bet that the vast majority of folks just ran and crashed sometime later. This also covers the case where plain variable constructors hit a problem. Can't check for NULL or partially built objects there, so throwing is the only way to generically signal "something bad happened."

[mcspr]

Sorry for not posting my earlier question as an issue.

While complex objects may be a problem, bunch of the code uses "old" Arduino-inherited style to allocate basic types (i.e. mixing up malloc() and new):

Arduino/cores/esp8266/cbuf.cpp

Line 49 in 29bedfa

if(!newbuf) {

Arduino/libraries/ESP8266WiFi/src/WiFiClientSecureBearSSL.cpp

Line 1056 in c18b402

if (!_sc || !_iobuf_in || !_iobuf_out) {

If the future thing is to finally enable exceptions, the intent here is to allow user app to catch badalloc exception?

Sidenote: I happen to notice this on ESP32, which behaves the same (but with a lot more memory to spare). So this may not be as surprising thing to happen as I initially thought.

[earlephilhower]

Yes. Throw() and catch() worked on GCC 4.8 until we lost the non-32-b-read-on-pgmem exception handler from the pre3.0.0 SDK (since pre3.0.0 was incredibly buggy). In gcc 9.1 I've just got a patch to rewrite the eh_frame parser working w/o any non-32b accesses and I hope to backport that very soon.

[earlephilhower]

@devyte, @d-a-v, any thoughts? It may be possible to pull new.o from the no-exceptions libs and revert to our basic malloc() wrapper (i.e. instead of crashing on a failed alloc), but I'm not too keen on it. We've already had new std::shared_ptr fail in bad ways when not crashing on new[] failure of the contained type.

[devyte]

The correct solution would be to fix all code that uses new and expects it to not throw, and change it to new(nothrow). That is what the language standard mandates.
We could make new behave like new(nothrow) when exceptions are disabled right now to maintain backwards compat and not have things break out there with minor releases. But for 3.x I think we should adhere to the language standard, i. e. : if you want to assure nothrow, either use new(nothrow) or malloc and new in place, per C++ documentation.