Re: Pointer errors?
On Thu, 31 Mar 2011 16:51:20 -0400 Stuart Halloway stuart.hallo...@gmail.com wrote: This is just *strange*. I'm working on converting a servlet that has hardwired vectors of values to read those values from a database. Given that this is simple, I'm using clojure.contrib.sql and an sqlite plugin. Those vectors get walked in the init code to create the hashmap that drives page rendering and any actions the servlet takes. The code change plan is: 1a) Convert vector of vector of strings to vector of hashmaps from keyword to strings. 1b) Tweak processing function in walk call to use :keys to destructure instead of vector destructuring. 2) Test and commit these changes. 3) Replace reference to hardwired vectors with call to with-query-results to read in essentially the same data. 4) Test and commit these changes. Ok, I started with a working servlet. I started seeing oddball tracebacks after after doing steps 1a 1b - no new libraries involved. I can reproducibly but get tracebacks, but some parts of the servlet work fine. The tracebacks look like: java.lang.RuntimeException: java.lang.NullPointerException at clojure.lang.LazySeq.sval(LazySeq.java:47) at clojure.lang.LazySeq.seq(LazySeq.java:56) at clojure.lang.RT.seq(RT.java:450) at clojure.core$seq.invoke(core.clj:122) at clojure.core$r.invoke(core.clj:793) at clojure.core$reverse.invoke(core.clj:806) at clj_stacktrace.core$trim_redundant.invoke(core.clj:86) at clj_stacktrace.core$parse_cause_exception.invoke(core.clj:104) at clj_stacktrace.core$parse_exception.invoke(core.clj:122) at ring.middleware.stacktrace$html_ex_view.invoke(stacktrace.clj:25) at ring.middleware.stacktrace$html_ex_response.invoke(stacktrace.clj:40) at ring.middleware.stacktrace$ex_response.invoke(stacktrace.clj:51) at ring.middleware.stacktrace$wrap_stacktrace$fn__1571.invoke(stacktrace.clj:61) at ring.util.servlet$make_service_method$fn__1842.invoke(servlet.clj:117) at x10.war$_service.invoke(war.clj:19) at x10.war.service(Unknown Source) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) [Speculation elided...] Ok, maybe it's a threading/agent issue. That would explain the once but never again behavior, if the agent got into the FAILED state. Could that corrupt something that might make jetty and/or ring fail as above? Except then why do the pages that just render HTML and not send work to the agent still work? Grrr. Anyone got any clue bits (any at all) I can borrow? Hi Mike, It appears that you aren't seeing the actual error (whatever it may be) because of a bug in clj_stacktrace. That was enough of a hint to chase the problem down: the agent was failing, for two reasons. One was a code bug. The other (which caused it to be erratic) was that it is serializing access to a reusable resource, and if I left the resource opened in the REPL, the agent would fail. That's what caused the erratic behavior that was driving me nuts. Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are
Pointer errors?
This is just *strange*. I'm working on converting a servlet that has hardwired vectors of values to read those values from a database. Given that this is simple, I'm using clojure.contrib.sql and an sqlite plugin. Those vectors get walked in the init code to create the hashmap that drives page rendering and any actions the servlet takes. The code change plan is: 1a) Convert vector of vector of strings to vector of hashmaps from keyword to strings. 1b) Tweak processing function in walk call to use :keys to destructure instead of vector destructuring. 2) Test and commit these changes. 3) Replace reference to hardwired vectors with call to with-query-results to read in essentially the same data. 4) Test and commit these changes. Ok, I started with a working servlet. I started seeing oddball tracebacks after after doing steps 1a 1b - no new libraries involved. I can reproducibly but get tracebacks, but some parts of the servlet work fine. The tracebacks look like: java.lang.RuntimeException: java.lang.NullPointerException at clojure.lang.LazySeq.sval(LazySeq.java:47) at clojure.lang.LazySeq.seq(LazySeq.java:56) at clojure.lang.RT.seq(RT.java:450) at clojure.core$seq.invoke(core.clj:122) at clojure.core$r.invoke(core.clj:793) at clojure.core$reverse.invoke(core.clj:806) at clj_stacktrace.core$trim_redundant.invoke(core.clj:86) at clj_stacktrace.core$parse_cause_exception.invoke(core.clj:104) at clj_stacktrace.core$parse_exception.invoke(core.clj:122) at ring.middleware.stacktrace$html_ex_view.invoke(stacktrace.clj:25) at ring.middleware.stacktrace$html_ex_response.invoke(stacktrace.clj:40) at ring.middleware.stacktrace$ex_response.invoke(stacktrace.clj:51) at ring.middleware.stacktrace$wrap_stacktrace$fn__1571.invoke(stacktrace.clj:61) at ring.util.servlet$make_service_method$fn__1842.invoke(servlet.clj:117) at x10.war$_service.invoke(war.clj:19) at x10.war.service(Unknown Source) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) The only place it runs through my code (as opposed to the libraries) are the two at x10.war lines. But that's just setup cod to get ring to invoke my handler. If I'm reading this right, the actual handler code isn't even being run. What's odd is that nothing outside the initialization code has changed. Worse yet, this doesn't happen on the first - or even second - access to the servlet. So long as I do nothing but render HTML, it all works fine. The first time I actually try and use the servlet to do something, the result page renders fine (but nothing happens). Try and do something again, and I get the above traceback. Invoke the same servlet with no actions (just render the HTML), and it still works fine. Try and do something again - the above traceback. I haven't presented any code because - well, it seems to be irrelevant. A two-line change (turn a literal vector into a hashmap, destructuring to match) can cause this. I finally get a version with the step 1 changes to work, and try the step two changes - and I start seeing the same problem. This kind of thing - seemingly trivial changes causing apparently unrelated code to blow up - would obviously be a pointer issue or similar - in C (or similar). Except - well, I thought Java was designed to prevent that kind of thing. And they just don't happen in LISP-like languages. Only it is. If I were only seeing it with the sql libraries, maybe it's an issue in those - except I saw pretty much the same behavior before I was using the
Re: Pointer errors?
This is just *strange*. I'm working on converting a servlet that has hardwired vectors of values to read those values from a database. Given that this is simple, I'm using clojure.contrib.sql and an sqlite plugin. Those vectors get walked in the init code to create the hashmap that drives page rendering and any actions the servlet takes. The code change plan is: 1a) Convert vector of vector of strings to vector of hashmaps from keyword to strings. 1b) Tweak processing function in walk call to use :keys to destructure instead of vector destructuring. 2) Test and commit these changes. 3) Replace reference to hardwired vectors with call to with-query-results to read in essentially the same data. 4) Test and commit these changes. Ok, I started with a working servlet. I started seeing oddball tracebacks after after doing steps 1a 1b - no new libraries involved. I can reproducibly but get tracebacks, but some parts of the servlet work fine. The tracebacks look like: java.lang.RuntimeException: java.lang.NullPointerException at clojure.lang.LazySeq.sval(LazySeq.java:47) at clojure.lang.LazySeq.seq(LazySeq.java:56) at clojure.lang.RT.seq(RT.java:450) at clojure.core$seq.invoke(core.clj:122) at clojure.core$r.invoke(core.clj:793) at clojure.core$reverse.invoke(core.clj:806) at clj_stacktrace.core$trim_redundant.invoke(core.clj:86) at clj_stacktrace.core$parse_cause_exception.invoke(core.clj:104) at clj_stacktrace.core$parse_exception.invoke(core.clj:122) at ring.middleware.stacktrace$html_ex_view.invoke(stacktrace.clj:25) at ring.middleware.stacktrace$html_ex_response.invoke(stacktrace.clj:40) at ring.middleware.stacktrace$ex_response.invoke(stacktrace.clj:51) at ring.middleware.stacktrace$wrap_stacktrace$fn__1571.invoke(stacktrace.clj:61) at ring.util.servlet$make_service_method$fn__1842.invoke(servlet.clj:117) at x10.war$_service.invoke(war.clj:19) at x10.war.service(Unknown Source) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) The only place it runs through my code (as opposed to the libraries) are the two at x10.war lines. But that's just setup cod to get ring to invoke my handler. If I'm reading this right, the actual handler code isn't even being run. What's odd is that nothing outside the initialization code has changed. Worse yet, this doesn't happen on the first - or even second - access to the servlet. So long as I do nothing but render HTML, it all works fine. The first time I actually try and use the servlet to do something, the result page renders fine (but nothing happens). Try and do something again, and I get the above traceback. Invoke the same servlet with no actions (just render the HTML), and it still works fine. Try and do something again - the above traceback. I haven't presented any code because - well, it seems to be irrelevant. A two-line change (turn a literal vector into a hashmap, destructuring to match) can cause this. I finally get a version with the step 1 changes to work, and try the step two changes - and I start seeing the same problem. This kind of thing - seemingly trivial changes causing apparently unrelated code to blow up - would obviously be a pointer issue or similar - in C (or similar). Except - well, I thought Java was designed to prevent that kind of thing. And they just don't happen in LISP-like languages. Only it is. If I were only seeing it with the sql libraries, maybe it's an issue in those -
