Bug #17334: Marshal cannot dump instance of Monitor

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: 2.7.2
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN

[Littlejd1997 (Jon David Schober)]

I'm not really sure why, but I hope someone else know whats going on.

I was digging into an error I had with Rails caching. Long story short, I was caching a HTTP::CookieJar object which has an instance variable of type Monitor.

The rails cache uses Marshaling, which fails on Monitor instances

2.7.2 :005 > Marshal.dump(Monitor.new)
Traceback (most recent call last):
        6: from /Users/jondavid.schober/.rvm/rubies/ruby-2.7.2/bin/irb:23:in `<main>'
        5: from /Users/jondavid.schober/.rvm/rubies/ruby-2.7.2/bin/irb:23:in `load'
        4: from /Users/jondavid.schober/.rvm/rubies/ruby-2.7.2/lib/ruby/gems/2.7.0/gems/irb-1.2.6/exe/irb:11:in `<top (required)>'
        3: from (irb):4
        2: from (irb):5:in `rescue in irb_binding'
        1: from (irb):5:in `dump'
TypeError (no _dump_data is defined for class Monitor)
2.7.2 :006 > 

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Rejected

This is expected and not a bug, as you can't dump the state of the Monitor. Instances of many core classes, such as Proc, Mutex, Thread, and Queue are likewise not dumpable.

[chrisseaton (Chris Seaton)]

I'm not sure what a dumped instance of Monitor would look like though? Its state implicitly includes the current stack trace of threads using it. What do you imagine an undumped Monitor with blocked threads would look like?

[Littlejd1997 (Jon David Schober)]

Alright. Sounds like the bug then lives in the http-cookie (HTTP::CookieJar) gem. It should have some way of representing the state when its being dumped or ignore the Monitor.