You probably have some kind of nested circular reference in what is being dumped, which essentially will generate an infinite loop.
On Nov 12, 2007 12:45 PM, Brad Wood <[EMAIL PROTECTED]> wrote: > Something a little weird this morning. We use Fusebox and have a > site-wide error handler which takes the cfcatch object, wddx's it and > logs it to our database. This usually only takes a second or two to > process. > > > > This morning SeeFusion E-mailed me about some long running requests. I > looked into it and a user kept refreshing a page which was calling an > erroring stored proc-- "string or binary data would be truncated". No > biggie- we get that error often if some lazy SQL programmer doesn't > check the column sizes of his temp tables. > > > > This was the weird thing though-the pages would run for up to half an > hour processing this line of code: > > > > <cfwddx action="cfml2wddx" input="#cfcatch#" output="cfcatchXML"> > > > > And when I tried to E-mail myself the cfcatch object by dropping a > cfdump into a cfmail, I would immediately get a "500 NULL" reply. > > I've only gotten those when trying to serialize incredibly huge > structures. My guess is, the cfcatch object is hideously huge-but how? > Why?" Since when? > > > > Since I can't look at it, I don't know what's in it. I can cfloop over > it as a collection and output the key names, but I think I have some > sort of endless nesting which would take a recursive function to get at > and would probably error just like the cfdump did. Funny thing > is-memory usage isn't high at all. Not even remotely. > > > > A quick look at my server.log file showed this error: > > > > java.lang.StackOverflowError > > > > Ok, go figure. A glance at the SeeFusion stack trace showed this: > > > > The top of the trace said this: > > > > "jrpp-94" runnable > > - locked <283> (a sun.misc.Launcher$ExtClassLoader) > > - locked <284> (a sun.misc.Launcher$AppClassLoader) > > - locked <272> (a java.lang.Class) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:286) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:282) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:235) > > at java.beans.Introspector.instantiate(Introspector.java:1466) > > at > java.beans.Introspector.findExplicitBeanInfo(Introspector.java:406) > > at java.beans.Introspector.<init>(Introspector.java:355) > > at java.beans.Introspector.getBeanInfo(Introspector.java:220) > > at java.beans.Introspector.getBeanInfo(Introspector.java:206) > > at > coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:48) > > at > coldfusion.wddx.WddxOutputStream.writeObject(WddxOutputStream.java:310) > > at > coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:40) > > > > and was followed by *800* lines this: > > > > at > coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:120) > > at > coldfusion.wddx.WddxOutputStream.writeObject(WddxOutputStream.java:310) > > > > Any ideas on how I can determine what is causing an error detail > structure so large it can't be serialized, or dumped without a stack > overflow? Is that a bug in CF? > > How come this has never happened before that I have ever seen until > today? I can reproduce it on more than one server. > > > > ~Brad > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Enterprise web applications, build robust, secure scalable apps today - Try it now ColdFusion Today ColdFusion 8 beta - Build next generation apps Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293137 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
