Multi-thread locking routine crashes

[WSinc]

This is puzzling, since:

(1) I am not using multi-threads at all, and
(2) I didNOT modify my source code before this started happening.
It came on unexpectedly.

I turned off the anti-virus, but got the same thing.
When I try stepping thru the program from the very start, it crashes almost
immediately when I call a subroutine. Sometimes I can call a subroutine one or twice before it
happens. It is not consistent, so I can't isolate it to any code section.

Any explanation or way to prevent this?
I don't intend to use multi-threading here anytime.

Here is the assembly where it crashes - see below.

{

/*

* Create/open the lock, if necessary

*/

if ( _locktable[locknum].lock == NULL ) {

if ( !_mtinitlocknum(locknum) )

_amsg_exit( _RT_LOCK );

}

/*

* Enter the critical section.

*/

IT BOMBS HERE with an access violation
EnterCriticalSection( _locktable[locknum].lock );

}

/***

* _unlock - Release multi-thread lock

*

*Purpose:

* Note that it is legal for a thread to aquire _EXIT_LOCK1

* multiple times.

*

*Entry:

* locknum = number of the lock to release

*

*Exit:

*

*Exceptions:

[IanH]

The C code stretch that you've posted is from the C runtime library. You need to try and work out what your code was doing before it got there. In the Visual Studio Debugger you might be able to see what was going on from the call stack.

[jimdempseyatthecove]

If you are not using multi-threading then is your code bypassing the section that initializes the critical sections?
Apparently your single threaded code is still calling the critical sections and if you:

a) omit initialization of critical section
or
b) omit allocation of your _locktable[nnn] array

then your code will be in error

Jim Dempsey

[jeremy_h]

I saw examples of lock operation in CVF/VC6 that failed in IVF/VC9. Investigation revealed that IVF/VC9 would crash while trying to release an unseized lock. Our lock-handling routines had exception handlers that tried to release locks before returning, so if the handler was invoked when the lock had not been grabbed, it caused a crash.

I'm not suggesting that this new behavior is a defect, or whether it might be Microsoft's responsibility or Intel, only that you might find the behavior different from CVF/VC6.