How's that surprising?
You allocate a too big matrix so that the allocation fails, apparently you had exceptions disabled or else you get
bjacob@cahouette:~$ g++ oom.cpp -o oom -I eigen
bjacob@cahouette:~$ ./oom
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
Even with exceptions disabled you could still easily check that allocation succeeded (M.data() != null).

I don't think allocation is failing, at least not on my machine. If I compile and run
#include <Eigen/Core>
#include <iostream>
int main()
{
Eigen::MatrixXd M(19604, 29601);
if(M.data() == NULL)
return 0;
M.setZero();
}
I get the same segfault, with the same stack trace.

Created attachment 218[details]
in Memory.h, check byte sizes for overflow
This takes care of half of the problem, and is already enough to address your case.
This makes us throw a std::bad_alloc on integer overflow when computing the byte size. My understanding of the c++ standard is that that's all what the regular operator new is supposed to be doing on bad allocation. Likewise our own allocation routines already have a comment saying:
* On allocation error, the returned pointer is undefined,
* but if exceptions are enabled then a std::bad_alloc is thrown.
So at this point we're not guaranteeing a null pointer on error anyways (so I was wrong in my first reply when I said that M.data()==null could be used as a test).
The other half of the problem will be to handle the case where width*height overflows.

Created attachment 225[details]
force inlining of overflow helpers
Here's a follow-up attempting to force the compiler to inline these helper functions.
This fixes for me the regression reported to the eigen mailing list in the "Significant perf regression probably due to bug 363 patches" thread.
Let me know if you like the EIGEN_ALWAYS_INLINE changes in particular. I think it makes more sense this way.