Skip to content

Commit d9e6507

Browse files
committed
Revert changes introduced in 2f6c694
This doesn't appear to be a correct fix. We should allow raising NoMemoryError even if we're under the VM lock.
1 parent f8887a8 commit d9e6507

1 file changed

Lines changed: 3 additions & 10 deletions

File tree

gc.c

Lines changed: 3 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -5081,19 +5081,12 @@ rb_memerror(void)
50815081
rb_execution_context_t *ec = GET_EC();
50825082
VALUE exc = GET_VM()->special_exceptions[ruby_error_nomemory];
50835083

5084-
if (!exc ||
5085-
rb_ec_raised_p(ec, RAISED_NOMEMORY) ||
5086-
rb_ec_vm_lock_rec(ec) != ec->tag->lock_rec) {
5084+
if (!exc || rb_ec_raised_p(ec, RAISED_NOMEMORY)) {
50875085
fprintf(stderr, "[FATAL] failed to allocate memory\n");
50885086
exit(EXIT_FAILURE);
50895087
}
5090-
if (rb_ec_raised_p(ec, RAISED_NOMEMORY)) {
5091-
rb_ec_raised_clear(ec);
5092-
}
5093-
else {
5094-
rb_ec_raised_set(ec, RAISED_NOMEMORY);
5095-
exc = ruby_vm_special_exception_copy(exc);
5096-
}
5088+
rb_ec_raised_set(ec, RAISED_NOMEMORY);
5089+
exc = ruby_vm_special_exception_copy(exc);
50975090
ec->errinfo = exc;
50985091
EC_JUMP_TAG(ec, TAG_RAISE);
50995092
}

0 commit comments

Comments
 (0)