Segmentation fault on GC
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 49
- Forks
- 31
- PR merge metrics
- No merged PRs in 30d
Description
The below code failed.
Thread.new { GC.start }
# Assertion failed: ((obj)->tt != MRB_TT_FREE), function mrb_gc_mark, mruby/src/gc.c, line 676
I dived into sea of the codes...
But I didn't resolve this issue.
Maybe main thread was calling mrb_close.
But sub thread GC mark anything main thread object. (Maybe from mrb->c->stack?)
It was method object (RProc *) in my env. And already freed.
mrb_thread_context_free have not yet called when failed.
Is this an unavoidable issue?
Of cause below code worked.
Thread.new { GC.start }.join
mruby: 08a1dd2ac89333bd928a3300f712d1a7fb57e8ff
mruby-thread: 0e2e003299789b52d6377debe5b11d46752d986d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the two Thread.new examples, one with GC.start and one with join. Read mruby/src/gc.c around line 676, then trace the mrb_close and mrb_thread_context_free paths mentioned in the report. Done means the unjoined example no longer reaches the assertion or segmentation fault, with the behavior covered by a regression test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, ruby
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100