skhrshin (Shintaro Sakahara)
- Login: skhrshin
- Registered on: 05/12/2024
- Last sign in: 05/12/2024
Issues
| open | closed | Total | |
|---|---|---|---|
| Assigned issues | 0 | 0 | 0 |
| Reported issues | 0 | 1 | 1 |
Activity
05/13/2024
-
09:35 AM Ruby Bug #20485: Simple use of Fiber makes GC leak objects with singleton method
- I tried looping with `100.times` in a more complex case that I created in the middle of the entire investigation of a test suite whose memory usage keeps growing until getting killed due to OOM, and as you said, the "leaked" object remai...
-
- I asked my co-workers to try this script and some of them gave me their results. The following table includes my results.
|Environment|# of people|Reproducibility|
|--|--|--|
|ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linu... -
- Do you mean this is fixed in trunk? Or are you saying this shouldn't happen on Ruby 3.3.1? If latter, that is not correct as I wrote `[1].each` and `Mutex.new.synchronize` versions reproduce the problem on Ruby 3.3.1.
I would like you t...
05/12/2024
-
- I confirmed that all of `1.times`, `[1].each` and `Mutex.new.synchronize` versions reproduce the problem on Ruby 3.2.4.
-
- Changing `1.times` to `[1].each` could reproduce the problem on Ruby 3.3.1 too.
-
- Update: To reproduce this issue with Ruby 3.3.1, Mutex is necessary.
-
- Update: Using Mutex was not necessary.
-
- I found a possible memory leak which occurs only when several conditions are met.
The code to reproduce the problem is below:
```
class Work
def add_method
singleton_class.define_method(:f) {}
end
end
1.times { Fibe...