You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7038 Reporter:@mlasson Status: closed (set by @xavierleroy on 2017-02-16T14:16:32Z) Resolution: fixed Priority: normal Severity: minor OS: linux 64 Version: 4.02.3 Fixed in version: 4.03.0+dev / +beta1 Category: otherlibs Monitored by: junsli
Bug description
As I was testing the ocaml runtime under limited memory, I discovered that the thread library is likely to segfault when there is not enough memory to allocate internal data structures.
Steps to reproduce
In trunk run :
$ ulimit -Sv 100000
$ make world.opt tests
The first command will limit the memory of sub-processes of your shell to 100Mb.
On my computer 11 tests segfaults, all of them are related to threads.
Additional information
I think, at least one comes from this function in systhreads/st_stubs.c
The call to st_mutex_create could fail. One should probably raise Out_of_memory if mutex is still NULL.
/* #4351: first try to acquire mutex without releasing the master lock */
if (st_mutex_trylock(mutex) == PREVIOUSLY_UNLOCKED) {
st_tls_set(last_channel_locked_key, (void *) chan);
return;
}
/* If unsuccessful, block on mutex /
enter_blocking_section();
st_mutex_lock(mutex);
/ Problem: if a signal occurs at this point,
and the signal handler raises an exception, we will not
unlock the mutex. The alternative (doing the setspecific
before locking the mutex is also incorrect, since we could
then unlock a mutex that is unlocked or locked by someone else. */
st_tls_set(last_channel_locked_key, (void *) chan);
leave_blocking_section();
}
The text was updated successfully, but these errors were encountered:
Reproduced under Linux x86-64. Indeed, there was a problem in caml_io_mutex_lock that is fixed by commit [trunk 906558a].
Now the testsuite "just" hangs on the thread tests in question, because the Out_of_memory exception kills the current thread, and the main thread deadlocks waiting for a condition variable from the killed thread...
Original bug ID: 7038
Reporter: @mlasson
Status: closed (set by @xavierleroy on 2017-02-16T14:16:32Z)
Resolution: fixed
Priority: normal
Severity: minor
OS: linux 64
Version: 4.02.3
Fixed in version: 4.03.0+dev / +beta1
Category: otherlibs
Monitored by: junsli
Bug description
As I was testing the ocaml runtime under limited memory, I discovered that the thread library is likely to segfault when there is not enough memory to allocate internal data structures.
Steps to reproduce
In trunk run :
$ ulimit -Sv 100000
$ make world.opt tests
The first command will limit the memory of sub-processes of your shell to 100Mb.
On my computer 11 tests segfaults, all of them are related to threads.
Additional information
I think, at least one comes from this function in systhreads/st_stubs.c
The call to st_mutex_create could fail. One should probably raise Out_of_memory if mutex is still NULL.
static void caml_io_mutex_lock(struct channel *chan)
{
st_mutex mutex = chan->mutex;
if (mutex == NULL) {
st_mutex_create(&mutex);
chan->mutex = mutex;
}
/* #4351: first try to acquire mutex without releasing the master lock */
if (st_mutex_trylock(mutex) == PREVIOUSLY_UNLOCKED) {
st_tls_set(last_channel_locked_key, (void *) chan);
return;
}
/* If unsuccessful, block on mutex /
enter_blocking_section();
st_mutex_lock(mutex);
/ Problem: if a signal occurs at this point,
and the signal handler raises an exception, we will not
unlock the mutex. The alternative (doing the setspecific
before locking the mutex is also incorrect, since we could
then unlock a mutex that is unlocked or locked by someone else. */
st_tls_set(last_channel_locked_key, (void *) chan);
leave_blocking_section();
}
The text was updated successfully, but these errors were encountered: