Check for null return when calling malloc().

[ywkaras]

[SolidWallOfCode]

Is this something we want to do? The exception will cause a crash, the same as the null pointer returned from malloc.

[ywkaras]

Is this something we want to do? The exception will cause a crash, the same as the null pointer returned from malloc.

It would be more obvious what happened. Don't we print the 'what()" for an uncaught standard exception to stderr?

[bryancall]

The consensus in the PR and issue scrub is to crash on the null pointer from malloc.

[ywkaras]

The consensus in the PR and issue scrub is to crash on the null pointer from malloc.

Won't an uncaught exception cause TS to crash?

I added a throw to the libswoc code in since that seemed the appropriate thing in a stand-alone library.

[ywkaras]

wkaras ~/TSX/TS/bin
B$ ./traffic_server &
[1] 31141
wkaras ~/TSX/TS/bin
B$ Traffic Server 10.0.0 Jul 27 2022 17:57:39 c1287bc2.home-wkaras.bf2.ows.oath.cloud
traffic_server: using root directory '/home/wkaras/TSX/TS'
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

[1]+  Aborted                 (core dumped) ./traffic_server
wkaras ~/TSX/TS/bin
B$ 

[maskit]

I added a throw to the libswoc code in since that seemed the appropriate thing in a stand-alone library.

Do we want to make a fork of libswoc? I'd rather not touch it.

[ywkaras]

I added a throw to the libswoc code in since that seemed the appropriate thing in a stand-alone library.

Do we want to make a fork of libswoc? I'd rather not touch it.

I don't know what the strategy (if any) is for coordinating the copy of libswoc within TS with the libswoc repo.

If we run out of memory, std::bad_alloc may be thrown by use of STL containers in TS. The monster is already under the bed, even if we pull the blanket over our head.

[ywkaras]

The consensus is to just let TS crash ugly if this happens.