The program block at stlport_vc646!_STL::__node_alloc<1,0>::_M_allocate +0x14f

[suds]

The program is based on Ice 3.10 and I using vc6 as my compiler,so stlport 4.6 is also a component .
After running for several days,the program do not responsed any command.So I manually crash the relative process using drwtsn32 .accroding to the dump log of drwtsn I found that the program is blocked.
And here are some call stack as below:

[call stack 1]
kernel32!Sleep+0xf
stlport_vc646!_STL::__node_alloc<1,0>::_M_allocate +0x14f
stlport_vc646!_STL::__node_alloc<1,0>::allocate+0x 27
WeiwooService!_STL::allocator<Ice::Identity>::allo cate+0x1c (CONV: thiscall)
....

[call stack 2]
kernel32!Sleep+0xf
stlport_vc646!_STL::__node_alloc<1,0>::_M_allocate +0x14f
ice31!Ice::ConnectionI::run+0x3fc9
ice31!Ice::ConnectionI::run+0x3ed2
ice31!Ice::ConnectionI::run+0x3d6f
...

[call stack 3]
kernel32!Sleep+0xf
stlport_vc646!_STL::__node_alloc<1,0>::_M_dealloca te+0x13a
freeze31!Freeze::NoSuchElementException::ice_print +0x1e50
...

[call stack 4]
kernel32!Sleep+0xf
stlport_vc646!_STL::__stl_debug_engine<bool>::_Ter minate+0x127
stlport_vc646!_STL::basic_string<char,_STL::char_t raits<char>,_STL::allocator<char> >::basic_string<char,_STL::char_traits<char>,_STL: :allocator<char> >+0xa3
ice31!Ice::ProtocolException::ProtocolException+0x 3f
ice31!Ice::ConnectionI::message+0xce

There are at least 6+ thread blocked at the function '::__node_alloc<1,0>::_M_allocate' .So I think that's why the program doesn't respond any command.

I also found a post at the stlport's forum which is about stlport deadlock.
STLport: Discussion Forum

BTW: according to service log,I found that there was a exception threw out before the program blocked.But I don't think this exception can cause the stlport block!

Thank you very much for giving me some tips on this issue!

[bernard]

I would be more concerned with the call to _Terminate than the node allocations.

Can you:
- upgrade to Ice 3.2.0
- use a debug version of Ice and your application to get better stack traces

Also, if you suspect a bug in STLPort, please upgrade to the latest version and rebuild Ice with that version (Ice does not need a specific version of STLPort).

Best regards,
Bernard

[suds]

Hi,thank you for your advise.
I'll build ice myself in th efuture.
But there are something I need your help
Here is a call stack which comes from a dump file
[call stack]
iceutil31!IceUtil::BadThreadControlException::BadT hreadControlException+0xd9
freeze31!Freeze::NoSuchElementException::ice_print +0x3b34
freeze31!Freeze::NoSuchElementException::ice_print +0x18a1
freeze31!Freeze::catalogName+0x4d7f
iceutil31!IceUtil::Thread::start+0x269
msvcrt!endthreadex+0xa3
kernel32!GetModuleHandleA+0xdf
....


I do care about why there is a BadThreadControlException and what's mean of this exception?

Back to the problem of my program,I do believe that there is a thread terminated abnormally at some time,so the other thread can't go on because the terminated thread hold some CriticSection or mutex which other threads want to use. but I can't judge which thread is gone.So I want to find out which thread is terminated abnormally,That's why I want to ask you the meaning of the exception.


For my poor english,hope these words can express what I want to say.

[bernard]

BadThreadControlException is only raised in IceUtil::ThreadControl::join and detach, when the target thread control was not properly initialized.

Before you post your next stack traces, please switch to the debug (/MDd) version of Ice 3.2.0!

Cheers,
Bernard