crash_handler code makes safepoint polling threads look like they crashed

In debugging a crash, where one thread hit an assert, we were waylaid trying to figure out why two other threads also looked like they failed because in this core file two other threads called report_and_die from crash_handler from a Java frame:

   0x7f2af82d7794: mov 0x108(%r15),%r10
   0x7f2af82d779b: movabs $0x4637f38c0,%r8
=> 0x7f2af82d77a5: test %eax,(%r10)
r15 is the thread
r15 0x7f2a706ff800 139820251740160
r10 is the thing we can't read
r10 0x7f2b0d231008 139822880722952
(gdb) x 0x7f2b0d231008
0x7f2b0d231008: Cannot access memory at address 0x7f2b0d231008
(gdb) print *(Thread*)0x7f2a706ff800
$2 = {<ThreadShadow> = {<CHeapObj<(MemoryType)2>> = {<No data fields>},
    _vptr.ThreadShadow = 0x7f2b0c4eacf8 <vtable for JavaThread+16>, _pending_exception = 0x0, _exception_file = 0x0,
...
  _threads_do_token = 66652, _rcu_counter = 0, _polling_page = 0x7f2b0d231008,

This is the polling page address.

I don't know why the signal handler is not JVM_handle_linux_signal for this thread anymore, which would have done the right thing for the safepoint polling address (and other signals that that code handles). It shouldn't be crash_handler anyway.