dtrace discuss - Dec 2009 - Thread's stack section was deleted

Some stack sections in the application disappeared, Both pstack/dbx
can not find the call stack and only knows they stopped in lwp_park.

below pmap resoults showed that the stack of thread 9 disappeared

FAA74000      32      32      32       -   8K rw--R    [ stack tid=12 ]
FAB78000       8       8       -       -    - rw--R    [ anon ]
FAB7A000       8       8       8       -   8K rw--R    [ stack tid=11 ]
FAC7A000       8       8       -       -    - rw--R    [ stack tid=10 ]
FAD78000       8       8       8       -   8K rw--R    [ anon ]
FAE78000      16      16       -       -    - rw--R    [ stack tid=8 ]
FAF74000       8       8       -       -    - rw--R    [ anon ]
FAF76000      24      24      24       -   8K rw--R    [ stack tid=7 ]
FB078000      16      16       -       -    - rw--R    [ stack tid=6 ]

So I wonder if it is possible for some other threads to unmap those
stack sections mistakenly. I tried to use dtrace to check who called
munmap but found nothing when even more threads lost their stack space.
Later, some more stranger thing happened, some stack losted previously
come back!

Things like below:


Previously, I can''t find thread#4 this morning by pstack
-----------------  lwp# 4 / thread# 4  --------------------
 fbac8a08 lwp_park (0, 0, 0)

however, now I can find it by pstack . why ?

-----------------  lwp# 4 / thread# 4  --------------------
 fbac8a08 lwp_park (0, 0, 0)
 fbac2a1c cond_wait_queue (fb27b960, 188900, 0, 0, 1c00, 0) + 4c
 fbac2f64 cond_wait (fb27b960, 188900, ffffffff, fffffff8, ffffffe0,
fb27b979) + 10  fbac2fa0 pthread_cond_wait (fb27b960, 188900, 0,
fb27bbc8, 1, 0) + 8
 fc6b76b4 int
ACE_OS::cond_timedwait(_pthread_cond*,_pthread_mutex*,ACE_Time_Value*)
(fb27b960, 188900, 0, 0, b, 0) + 8c  fc6b7d9c int
ACE_Condition_Thread_Mutex::wait(ACE_Thread_Mutex&,const
ACE_Time_Value*) (fb27b960, 188900, 0, 0, fb27bc68, 1) + 24
 fc6b7de8 int ACE_Condition_Thread_Mutex::wait(const ACE_Time_Value*)
(fb27b960, 0, 188930, 0, 0, 2e) + 20
 fc778658 int
ACE_Token::ACE_Token_Queue_Entry::wait(ACE_Time_Value*,ACE_Thread_Mutex&)
(fb27b958, 0, 188900, 188930, fb3e1200, 8b2e8) + 20  fc777b8c int
ACE_Token::shared_acquire(void(*)(void*),void*,ACE_Time_Value*,ACE_Token::ACE_Token_Op_Type)
(1888e8, fc77ab40, 0, 0, 1, fc69e7e4) + 2f4
 fc77ab14 int
ACE_Token::acquire_read(void(*)(void*),void*,ACE_Time_Value*) (1888e8,
fc77ab40, 0, 0, 75, fda008) + 34  fc7787a0 int
ACE_TP_Token_Guard::acquire_read_token(ACE_Time_Value*) (fb27baf4, 0, 0,
4, b, 1) + b0  fc778bdc int
ACE_TP_Reactor::handle_events(ACE_Time_Value*) (188248, 0, 4, fb27bbc8,
1, 0) + 4c
 fc742588 int ACE_Reactor::handle_events(ACE_Time_Value*) (1b5d50, 0,
fcb03154, 0, b, fbb303a8) + 40
 fca573a4 int TAO_ORB_Core::run(ACE_Time_Value*,int) (117488, 0, 0, 12,
fb27bc68, 1) + 364
 fca47544 void CORBA::ORB::run(ACE_Time_Value*) (13e788, 0, 0, 10, 1cf4,
fbb36000) + 2c  fca474c0 void CORBA::ORB::run() (13e788, 13e788, 0, 0,
fb3e1200, 10) + 10
 fdcd3794 void*FMK_CorbaThreadPool::poolThread(void*) (1e3a08, fb27c000,
0, 0, fdcd35a0, 1) + 1f4
 fbac8968 _lwp_start (0, 0, 0, 0, 0, 0)


So, Is it possible for me to find out who is doing these kind of jobs
behind?

Thanks and Rds.
Lamb.