new操作符直接触发Core Dump问题咨询：异常捕获失效与栈数组异常

Alright, let's break this down—this is a weird one because allocating 100 bytes (either on heap or stack) should never trigger a core dump under normal circumstances. The fact that both heap and stack allocations crash tells us the issue isn't with the 100-byte request itself, but something deeper going on in your program or environment.

First: Stop blaming the 100-byte allocation #

Even in memory-constrained systems, 100 bytes is trivial. std::bad_alloc is thrown when the OS can't fulfill a large allocation request, not for tiny chunks like this. And a stack array of 100 bytes would only overflow the stack if your program has already eaten up nearly all available stack space (e.g., via infinite recursion or massive stack variables declared earlier).

Possible root causes (and how to debug them) #

1. Pre-existing memory corruption

This is the most likely culprit. If your code before this allocation has already overwritten memory it shouldn't have—like:

• Writing past the end of a heap-allocated buffer (corrupting heap metadata)
• Overflowing a stack variable (corrupting the stack frame or return address)
• Using a dangling pointer to write to invalid memory

...then any subsequent memory operation (including a tiny new or stack array) can trigger a crash. The crash happens at the allocation line, but the bug is somewhere earlier in your code.

How to check:
Compile your program with AddressSanitizer (add -fsanitize=address to your GCC/Clang compile flags) and run it. It will pinpoint exactly where the memory corruption occurred, even if it's lines before the crash.

2. Compile options disabling C++ exceptions

If you're using flags like -fno-exceptions, the C++ runtime won't throw std::bad_alloc—instead, new will return a null pointer. But returning null shouldn't cause a core dump at the new line itself. However, if your program has other issues (like memory corruption), this could mask the real problem.

How to verify:
Write a tiny test program to check if exceptions work:

#include <iostream>
#include <stdexcept>

int main() {
    try {
        throw std::runtime_error("Test exception");
    } catch (const std::exception& e) {
        std::cout << "Caught exception: " << e.what() << "\n";
        return 0;
    }
    return 1;
}

Compile and run this. If it doesn't print the caught message, you've got exceptions disabled.

3. Extremely limited stack space (rare)

Most systems default to an 8MB stack, which is way more than enough for 100 bytes. But if you've manually reduced the stack size (e.g., with ulimit -s on Linux, or linker flags like -Wl,--stack,1024), and your program has already used nearly all of it, adding a 100-byte stack array could push it over the edge.

How to check:
On Linux, run ulimit -s to see the current stack size limit. In GDB, you can inspect the stack pointer to see how much space is left before the crash.

4. System-level memory exhaustion (unlikely)

If your system is completely out of RAM and swap, the OS will usually kill processes via the OOM killer instead of letting them core dump on a tiny allocation. But in some edge cases (e.g., embedded systems with no swap), this might happen.

How to check:
On Linux, run free -h to see available memory before running your program.

Next steps to fix this #

1. Run with AddressSanitizer first—it's the fastest way to find memory corruption bugs.
2. Check your compile flags to ensure exceptions are enabled if you're relying on them.
3. Review code before the crash point—look for any buffer overflows, dangling pointers, or incorrect memory writes.

内容的提问来源于stack exchange，提问作者cforever