Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation faults of thread library when memory is limited #7038

Closed
vicuna opened this issue Nov 10, 2015 · 2 comments
Closed

Segmentation faults of thread library when memory is limited #7038

vicuna opened this issue Nov 10, 2015 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Nov 10, 2015

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();
}

@vicuna
Copy link
Author

vicuna commented Nov 24, 2015

Comment author: junsli

The segfaults didn't occur on OSX. Might be just on Linux.

@vicuna
Copy link
Author

vicuna commented Nov 27, 2015

Comment author: @xavierleroy

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant