[#66126] Creation/Conversion methods/functions table for Ruby types — SASADA Koichi <ko1@...>
Hi,
5 messages
2014/11/07
[#66289] Re: Creation/Conversion methods/functions table for Ruby types
— Eric Wong <normalperson@...>
2014/11/14
SASADA Koichi <[email protected]> wrote:
[#66293] Re: Creation/Conversion methods/functions table for Ruby types
— SASADA Koichi <ko1@...>
2014/11/14
On 2014/11/15 7:44, Eric Wong wrote:
[#66248] [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations — normalperson@...
Issue #10423 has been updated by Eric Wong.
3 messages
2014/11/13
[#66595] [ruby-trunk - Bug #10557] [Open] Block not given when the argument is a string — bartosz@...
Issue #10557 has been reported by Bartosz Kopinski.
3 messages
2014/11/30
[ruby-core:66197] [ruby-trunk - Feature #9725] Do not inspect NameError target object unless verbose
From:
headius@...
Date:
2014-11-11 05:44:19 UTC
List:
ruby-core #66197
Issue #9725 has been updated by Charles Nutter. Josh: great examples, thank you. I've run into similar cases trying to debug applications on JRuby or help users find performance problems. This is a hidden gotcha that's *very* hard to find, especially if you have some library sticking a giant graph of objects in there. I'd like to get approval that this is a good idea before I attempt to patch it. There must be others out there who hate the fact that NameError carries along the whole object with it! ---------------------------------------- Feature #9725: Do not inspect NameError target object unless verbose https://bugs.ruby-lang.org/issues/9725#change-49895 * Author: Charles Nutter * Status: Open * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- =begin At least once every few months, we get an error report of JRuby raising a memory error where MRI does not due to NameError's Message object holding a reference to an object that's too large to inspect. I propose that this inspection of the target object should only be done in verbose mode. Background: NameError is raised when a variable-like method call fails to find a defined method. The resulting exception is created with a hidden NameError::Message that holds the object in which the method could not be found. When name error needs to render its message, such as when it bubbles out or when #message is called, it does to_str on the NameError::Message, which ends up inspecting the target object. If this object's inspect output is large (or infinite) it can end up consuming a large amount of memory. Problems: * If the amount of memory required to render a NameError exceeds available memory, a very confusing and misleading memory error can be raised instead. * If the target object is considered sensitive data, it will end up bubbling out through potentially untrustworthy code. It is an encapsulation flaw, basically. * A NameError that gets held in memory will also prevent GC of the object it references. Solutions: * NameError should not capture the target object. * NameError should build a message based on the target object *at creation time*, and only include information useful to indicate the type of object. * (Optional) If verbose mode is set, NameError can just do what it does now. -- https://bugs.ruby-lang.org/