<< Back to previous view

[CLJ-435] stackoverflow exception in printing meta with :type Created: 14/Sep/10  Updated: 29/Apr/11  Resolved: 29/Apr/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Release 1.3

Type: Defect Priority: Minor
Reporter: Assembla Importer Assignee: Stuart Halloway
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0435-printing-badly-typed-objects.patch    
Approval: Ok


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!

Comment by Assembla Importer [ 08/Oct/10 10:36 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/435

Comment by Assembla Importer [ 08/Oct/10 10:36 AM ]

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?

Comment by Meikel Brandmeyer [ 21/Mar/11 1:53 PM ]

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?

Comment by Stuart Halloway [ 22/Apr/11 9:13 AM ]

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?

Generated at Sun Apr 30 02:23:09 CDT 2017 using JIRA 4.4#649-r158309.