The JVM running with the -Xprof option can crash while analysing a thread that's handling a SIGLWP.

Crashing thread - the JVM Profiler:

  xxxxx@xxxxx   (  xxxxx@xxxxx  ) terminated by signal ABRT (Abort)
0xff379dd8: __sigprocmask+0x0008:       retl
dbx> where -l
=>[1] libthread.so.1:__sigprocmask(0x0, 0xb4c00650, 0x0, 0xffffffff, 0xffffffff, 0x0), at 0xff379dd8
  [2] libthread.so.1:_resetsig(0xff38ca6c, 0x0, 0x0, 0x0, 0xb4c01e3c, 0xb4c01e40), at 0xff36f3c4
  [3] libthread.so.1:_sigon(0xff3944f8, 0xff394378, 0xb4c01e38, 0xb4c00724, 0x6, 0xff2ce178), at 0xff36eb80
  [4] libthread.so.1:_thrp_kill(0x0, 0xc, 0x6, 0xff38ca6c, 0xb4c01dc0, 0xff393cf4), at 0xff371954
  [5] libc.so.1:abort(0xff335f84, 0xb4c00818, 0x0, 0xfffffff8, 0x0, 0xb4c00839), at 0xff2b95a0
  [6] libjvm.so:os::abort(0x1, 0xfe5555aa, 0xb4c008c8, 0xfe582000, 0xfe5c9944, 0x3ee894), at 0xfe499d98
  [7] libjvm.so:os::handle_unexpected_exception(0x0, 0xa, 0xfe3890fc, 0xb4c01608, 0xfe1d7398, 0x0), at 0xfe4980ac
  [8] libjvm.so:JVM_handle_solaris_signal(0xfe3890fc, 0xb4c01608, 0xb4c01350, 0x3400, 0x3608, 0x0), at 0xfe1d7c6c
  [9] libthread.so.1:__sighndlr(0xa, 0xb4c01608, 0xb4c01350, 0xfe1d731c, 0xb4c01e48, 0xb4c01e28), at 0xff37be38
  ---- called from signal handler with signal 10 (SIGBUS) ------
  [10] libjvm.so:ThreadProfiler::record_interpreted_tick(0xd0308, 0xb4c01848, 0x0, 0xffca8, 0x481704, 0xfe38a2a8), at 0xfe3890fc
  [11] libjvm.so:ThreadProfiler::record_tick(0xd0308, 0xcf900, 0xfa400, 0x201960, 0x0, 0xa), at 0xfe38a2fc
  [12] libjvm.so:FlatProfiler::record_thread_ticks(0xfb050, 0xa, 0x0, 0x0, 0x0, 0x0), at 0xfe388c84
  [13] libjvm.so:PeriodicTask::real_time_tick(0xa, 0x0, 0xa, 0x0, 0x2, 0xb4c01cd5), at 0xfe4d86f4
  [14] libjvm.so:WatcherThread::run(0x2014d0, 0xd, 0x7f, 0xc, 0xff38ca6c, 0x0), at 0xfe2bfb64
  [15] libjvm.so:_start(0x2014d0, 0x0, 0x1, 0xff38e0d8, 0x1, 0xff38ca6c), at 0xfe2643e0
dbx>


The thread it was analysing:

dbx> where -l   xxxxx@xxxxx  
=>[1] libc.so.1:__lwp_sema_wait(0x4, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff319f94
  [2] libthread.so.1:_park(0xaf381dc0, 0xaf381e78, 0x0, 0x0, 0x0, 0x0), at 0xff36b2f8
  [3] libthread.so.1:_swtch(0x5, 0xff38ca6c, 0xaf381e54, 0xaf381e50, 0xaf381e4c, 0xaf381e48), at 0xff36ae4c
  [4] libthread.so.1:_dopreempt(0x0, 0xff38ca6c, 0x0, 0x0, 0x0, 0x0), at 0xff36cf30
  [5] libthread.so.1:_sigsuspnd(0xaf381dc0, 0xaf380848, 0xaf380590, 0x0, 0x0, 0x0), at 0xff36f6c4
  [6] libthread.so.1:__sighndlr(0x21, 0xaf380848, 0xaf380590, 0xff36f6e0, 0xaf381e28, 0x0), at 0xff37be38
  ---- called from signal handler with signal 33 (SIGLWP) ------
  [7] 0xf980a0b8(0xd10c96e0, 0xbeda9220, 0xbf18a008, 0x0, 0x1, 0xaf3808c8), at 0xf980a0b7
...stacktrace continues...



  xxxxx@xxxxx   2005-06-23 10:57:53 GMT
Posted Date : 2005-08-09 17:25:25.0

Moving away from Solaris 7 would mean the "new" thread library is available, which removes this situation (SIGLWP).

Possibly -XX:+UseBoundThreads will workaround the problem - confirmation not yet received.

  xxxxx@xxxxx   2005-06-23 10:57:53 GMT

This should be fixed since 1.5 by the combination of 2 features; safepoint polling and the fact that -Xprof now uses safepoints instead of suspend/resume.  I'm unable to reproduce since 1.5 so this bug will be closed.

*** (#1 of 1): [ UNSAVED ]   xxxxx@xxxxx  
Posted Date : 2007-01-23 17:06:26.0