0004979: win32: GetLastError and threads

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0004979

OCaml

OCaml general

public

2010-02-17 00:09

2011-05-29 12:19

Reporter

gerd

Assigned To

xleroy

Priority

normal

Severity

minor

Reproducibility

always

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

3.11.1

Target Version

Fixed in Version

3.12.0+dev

Summary

0004979: win32: GetLastError and threads

Description

Just got an error Sys_error("Mutex.lock: error code 0") in a win32 program using threads heavily. I wondered how that was possible. Apparently, the true reason of the error is hidden, and the error code 0 is a lie. (It's usually an invalid descriptor.)

So I dug a bit deeper into the ocaml runtime, and found this (systhreads/win32.c):

CAMLprim value caml_mutex_lock(value mut)
{
  int retcode;
  Begin_root(mut) /* prevent deallocation of mutex */
    enter_blocking_section();
    retcode = WaitForSingleObject(Mutex_val(mut), INFINITE);
    leave_blocking_section();
  End_roots();
  if (retcode == WAIT_FAILED) caml_wthread_error("Mutex.lock");
  return Val_unit;
}

In caml_wthread_error, the win32 function GetLastError is used to obtain the error code. However, this code was already overwritten in leave_block_section (there is a WaitForSingleObject right at the beginning to get the master lock).

Suggested fix: Get the error code before leave_blocking_section, and pass it to caml_wthread_error.

Tags

No tags attached.

Attached Files

Relationships

Notes
(0005246) doligez (manager) 2010-02-17 14:20	There is a second bug in the above code: the heap is accessed (by Mutex_val) from within the blocking section.

(0005393) xleroy (administrator) 2010-04-27 10:03	Fixed as part of a general refactoring of systhreads implementation. Will go in 3.12.0.

Issue History
Date Modified	Username	Field	Change
2010-02-17 00:09	gerd	New Issue
2010-02-17 14:20	doligez	Note Added: 0005246
2010-04-02 14:04	xleroy	Assigned To	=> xleroy
2010-04-02 14:04	xleroy	Status	new => acknowledged
2010-04-27 10:03	xleroy	Note Added: 0005393
2010-04-27 10:03	xleroy	Status	acknowledged => resolved
2010-04-27 10:03	xleroy	Resolution	open => fixed
2010-04-27 10:03	xleroy	Fixed in Version	=> 3.12.0+dev
2011-05-29 12:19	xleroy	Status	resolved => closed