Clojure

stackoverflow exception in printing meta with :type

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: Release 1.3
  • Component/s: None
  • Labels:
    None
  • Approval:
    Ok

Description

Hi, after expose the problem in clojure irc and the help of @chouser, we thought my problem must be a bug.
Here the console session

user> (with-meta {:value 2} {:type Object})

No message. [Thrown class java.lang.StackOverflowError]

0: clojure.lang.PersistentHashMap$BitmapIndexedNode.index(PersistentHashMap.java:485)
1: clojure.lang.PersistentHashMap$BitmapIndexedNode.find(PersistentHashMap.java:571)
2: clojure.lang.PersistentHashMap$ArrayNode.find(PersistentHashMap.java:355)
3: clojure.lang.PersistentHashMap.entryAt(PersistentHashMap.java:129)
4: clojure.lang.Var.getThreadBinding(Var.java:334)
5: clojure.lang.Var.deref(Var.java:137)
6: clojure.lang.Var.get(Var.java:133)
7: clojure.core$pr_on.invoke(core.clj:2810)
8: clojure.lang.Var.invoke(Var.java:369)
9: clojure.lang.RT.print(RT.java:1270)
10: clojure.lang.RT.printString(RT.java:1249)
11: clojure.lang.APersistentMap.toString(APersistentMap.java:20)

Chouser pointed that is a print error, creation and use of map with meta works fine

Thank for your help!

Activity

Hide
Assembla Importer added a comment -
Show
Assembla Importer added a comment - Converted from http://www.assembla.com/spaces/clojure/tickets/435
Hide
Assembla Importer added a comment -

chouser@n01se.net said: The problem is the print-method for Object calls .toString on the object, clearly expecting some nice tame Java default implementation. But in this case, the object is actually APersistentMap, which has a .toString that uses print-method. Oops.

One possible resolution is simply to say: when you lie about an object's type, bad things can happen. :type Object is essentially claiming that the map's concrete type is Object and that's simply not true. Perhaps breakage should be expected.

On the other hand, if we want to fail more gracefully either with a clearer error or "pre-initialized" print defined in RT.print, I'm not sure I see a solution other than explicit recursion detection. In this case it could take the form of a private Var set to the object being printed. If the Var is already equal to the object you're supposed to print, you're recursing on a single object and need to break out somehow.

Can anyone think of a cleaner way to catch this?

Show
Assembla Importer added a comment - chouser@n01se.net said: The problem is the print-method for Object calls .toString on the object, clearly expecting some nice tame Java default implementation. But in this case, the object is actually APersistentMap, which has a .toString that uses print-method. Oops. One possible resolution is simply to say: when you lie about an object's type, bad things can happen. :type Object is essentially claiming that the map's concrete type is Object and that's simply not true. Perhaps breakage should be expected. On the other hand, if we want to fail more gracefully either with a clearer error or "pre-initialized" print defined in RT.print, I'm not sure I see a solution other than explicit recursion detection. In this case it could take the form of a private Var set to the object being printed. If the Var is already equal to the object you're supposed to print, you're recursing on a single object and need to break out somehow. Can anyone think of a cleaner way to catch this?
Aaron Bedra made changes -
Field Original Value New Value
Assignee Stuart Halloway [ stu ]
Reporter Assembla Importer [ importer ]
Priority Minor [ 4 ]
Hide
Meikel Brandmeyer added a comment -

Maybe one could check that (= (type thing) (class thing)) if the result of type is a Class? Types in meta data should normally be Keywords, no?

Show
Meikel Brandmeyer added a comment - Maybe one could check that (= (type thing) (class thing)) if the result of type is a Class? Types in meta data should normally be Keywords, no?
Hide
Stuart Halloway added a comment -

I chose to make the minimal change to print-method, rather than changing the type function, which would have been a breaking change to documented behavior.

Aside: Should type be deprecated?

Show
Stuart Halloway added a comment - I chose to make the minimal change to print-method, rather than changing the type function, which would have been a breaking change to documented behavior. Aside: Should type be deprecated?
Stuart Halloway made changes -
Attachment 0435-printing-badly-typed-objects.patch [ 10193 ]
Approval Vetted Screened
Rich Hickey made changes -
Approval Screened Ok
Stuart Halloway made changes -
Status Open [ 1 ] Closed [ 6 ]
Resolution Completed [ 1 ]

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: