Archived

This forum has been archived. Please start a new discussion on GitHub.

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

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+0x27
WeiwooService!_STL::allocator<Ice::Identity>::allocate+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_deallocate+0x13a
freeze31!Freeze::NoSuchElementException::ice_print+0x1e50
...

[call stack 4]
kernel32!Sleep+0xf
stlport_vc646!_STL::__stl_debug_engine<bool>::_Terminate+0x127
stlport_vc646!_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >+0xa3
ice31!Ice::ProtocolException::ProtocolException+0x3f
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!

Comments

  • bernard
    bernard Jupiter, FL
    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
  • Hi,thank you for your advise.
    I'll build ice myself in th efuture.
    But there are something I need your help:D
    Here is a call stack which comes from a dump file
    [call stack]
    iceutil31!IceUtil::BadThreadControlException::BadThreadControlException+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
    bernard Jupiter, FL
    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