Boost logo

Boost :

From: Vaclav Cechura (v2cechura_at_[hidden])
Date: 2007-11-24 06:46:40

As I wrote in my post, I tried to allocate the mutex in main using "new" but
it did not helped. And the cause seems to be in the thread initialization
process long before my mutex is used. Actually the mutex that causes the
crash is an mutex object that boost::thread creates during startup.


-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Neil Groves
Sent: Saturday, November 24, 2007 11:41 AM
To: boost_at_[hidden]
Subject: Re: [boost] FW: [Boost-users] [threads] Using boost::mutexraises
access violation exception

I have experienced a similar issue with boost::mutex when the mutex was
instantiated from DllMain (in a DLL). The Windows implementation uses a
Critical Section. I have found that under many startup / shutdown cases the
InitializeCriticalSection returns null. I cannot find documentation that
states that this happens. The solution is to create the boost::mutex in
another manner. Hence if you stop the boost::mutex from being a global
variable I think the problem will disappear.

I hope this helps,
Neil Groves

-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of v2cechura
Sent: 23 November 2007 14:31
To: boost_at_[hidden]
Subject: [boost] FW: [Boost-users] [threads] Using boost::mutex raises
access violation exception

I posted this to the user's list (no answer till now), but later came to the
conclusion that developer's list might be a better place.
Any help on th issue appreciated.


-----Original Post------

I just recently installed and built boost library (1.34.1) using bcbboost. I
wanted to try the boost::thread class. This simple code gives me "Access
Violation" in Borland C++ Builder 2006 when boost::mutex is

#include <iostream>
#include <boost/thread.hpp>
boost::xtime xt = {2};

boost::mutex console; // line A

void thr() // int n, boost::mutex & display {
        for (int i = 0; i < 10; i++)
                        boost::mutex::scoped_lock l(console); // line B
                        std::cout << "thr" << 1 << ":" << i << std::endl;
        } // end for

int main(int argc, char* argv[])
        boost::thread_group tg;

        char c;
        std::cin >> c ;
        return 0;

If line A and line B are commented-out then the error is gone.

The project is a multithreaded console application, both boost.threads and
rtl are static-linked.

Caller stack is:
:7c812a5b kernel32.RaiseException + 0x52 :004129aa ___raiseDebuggerException
+ 0x1A
:00412a84 ; ___raiseDebuggerException
:7c9037bf ntdll.RtlConvertUlongToLargeInteger + 0x7a :7c90378b
ntdll.RtlConvertUlongToLargeInteger + 0x46 :7c90eafa
ntdll.KiUserExceptionDispatcher + 0xe :0041FA2B
boost::mutex::do_unlock(this=NULL, =:0012FDE8)
:0041E3A2 boost::detail::thread::lock_ops<boost::mutex>::unlock(m=NULL,
state=:0012FDE8) :0041E12D
boost::condition::do_wait<boost::mutex>(this=:0012FEA4, mutex=NULL)
>(this=:0012FEA4, lock=:0012FE5C) :0041D42F
:0041D201 boost::thread::thread(this=:00000FCC, threadfunc=:00000FC8)

I put mutex.cpp in my directory and BCB2006 locates the error to be here:

void mutex::do_unlock()
    if (m_critical_section) //------------- Access violation HERE

The access violation is raised when thread::thread constructor is called.

Looking at the caller stack I noticed that mutex parameter is NULL from some
point and it results in this==NULL for the last call. Note that this mutex
parameter is not the mutex "console"
object I use in the program. It is a mutex that boost.threads library uses
during thread initialization. On the other hand there is some dependance on
mutex "console" because when I comment it out the error is gone.

I maked console a pointer with appropriate changes to source and created it
using new but it did not help.

Am I missing something?

Any help appreciated. Does anybody have experiences with boost::thread and
mutex under BCB(2006,2007...)?



Unsubscribe & other changes:

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at