2 Replies Latest reply on Jul 17, 2012 1:20 AM by Sorin87bv

    Unable to debug with CQ5.4

    snemarch Level 1

      After upgrading from CQ5.3 to CQ5.4, we are no longer able to use CRXDE to debug our codebase.


      Setting breakpoints and stepping through JSP code works just fine, but if we put breakpoints on Java code in our code bundle, or try stepping into it, it doesn't work. Sometimes CRXDE will hang, other times we seem to be stepping through the code (the current call stack and variables window reflects stepping through the java code), but don't get anything in the source code window.


      After having single-stepped through JSP code, CPU usage will spike for a while after resuming code execution, but will quickly return to normal (i.e., this is normal behaviour during page rendering). If I try single-stepping into a Java method, however, CPU usage will spike to ~35% for about thirty seconds, then ~55% (with ~85% of that spent in kernel mode) for about 90 seconds. This is on a 2.67GHz core i7 CPU, so that's quite a lot of CPU consumption.


      After this long period of CPU burning, the source code view will change from the JSP file I was stepping from, and to the Java file I tried stepping into, but with "source not found" and an "Edit Source Lookup Path" button.


      If I try adding a source path, CPU usage will spike up again in the same way as during the initial single-step attempt.


      After resuming execution, if I reload my page to hit the JSP breakpoint, I get the same kind of CPU spike, before the source code view finally changes from the "source not found" Java window to the JSP file the breakpoint was set in. After resuming and then realoding the page again (not having single-stepped into any Java code), I seem to get into a repeated cycle of the 35%-then-55% CPU usage, with several cycles taking place before the IDE indicates that it's ready to single-step (i.e., highlights the line with the breakpoint). The IDE doesn't frozen during this period, I could scroll the source view around and activate menus etc.


      If I detach and reattach the debugger and reload my page, the breakpoint is hit as expected, and the IDE immediately reflects that it's ready to single-step. If I only step through JSP code and then resume execution, the next time I hit the breakpoint it's still instantaneous - so it would seem that it's the attempt to step into Java code that messes up some debugger state(?).



      The CPU consumption happens within the javaw.exe process spawned by CRXDE, the java.exe process running the CQ5.4 instance is at almost idle CPU consumption.



      The first time I start debugging after having started the CQ5.4 instance, I get the following on the console output:

      ASSERT FAILED: ../../../src/share/back/SDE.c : 274 - bad SourceDebugExtension syntax - position 25 - expected '*'

      ASSERT FAILED: ../../../src/share/back/SDE.c : 274 - bad SourceDebugExtension syntax - position 39 - expected '*'


      I've also tried setting up a clean CQ5.4 instance with a barebones test project (using "New Project" in CRXDE, then using CRXDE-Lite following the steps in http://dev.day.com/docs/en/cq/5-4/howto/website.html to create design, template and component). Even with this clean setup, I still can't trace into Java code - I don't get the long periods of high CPU usage before the "source not found" window pops up, but there's obviously a lot less code and content in the clean 5.4 instance than our normal development instance :-)



      I've tried wiping the %HOME%\.crxde folder, just in case. It reduces the length of the CPU-spike period, but otherwise makes no difference.



      There's no problems debugging our old CQ5.3 instance with the same CRXDE and JDK versions  that we use for CQ5.4 (there's obviously been quite some changes to our codebase since we upgraded to 5.4, though).


      When building bundles for our dev, test and prod environments we build with Maven, but on our development machines we build from inside CRXDE - so the source code definitely should be available.


      The problems happen happen on a variety of setups, spanning both Windows and OS X machines. Specifics for my setup is:

      Intel Core i7 M620, 2.67GHz

      4GB ram


      Windows 7 SP1, 64-bit

      CRXDE 1.0.1, 64-bit


      Tested with our development CQ5.4 instance ("some hotfixes, large codebase and some gigabytes of content") as well as a clean CQ5.4 without any hotfixes. The CQ5.4 instance has been tested with both JDK 1.6.0_26 (64bit) and JDK 1.6.0_30 (32bit).


      Memory settings have been increased from the defaults, here's a dump from server startup:

      C:\dev\Day\author54\crx-quickstart\server>server -debug socket


      Starting Quickstart


      java version "1.6.0_30"

      Java(TM) SE Runtime Environment (build 1.6.0_30-b12)

      Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)


      debugging: Socket (30303)


      "C:\dev\jdk\1.6.0_30-x86\bin\java.exe"  -Xms128m -Xmx512m -XX:MaxPermSize=256M -Djava.security.auth.login.config=crx-quickstart/server/etc/jaas.config -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=30303 -jar C:\dev\Day\author54\crx-quickstart\server\..\..\quickstart-author-4502.jar  -verbose -nobrowser -nofork


      Listening for transport dt_socket at address: 30303

      Loading instance properties:/quickstart/quickstart-cq5.properties

      Running on a console, won't fork the JVM (use -fork to force forking)

      Using 32bit VM settings

      The JVM reports a heap size of 494 MB, meets our expectation of 256 MB +/- 20

      The JVM MBean:Perm Gen reports a maximum size of 256 MB, meets our expectation of 64 MB +/- 20

      Setting system properties from filename 'file:/C:/dev/Day/author54/quickstart-author-4502.jar'

      System property '-crx.quickstart.server.port' set to '4502' from filename quickstart-author-4502.jar

      System property 'sling.jcrinstall.folder.name.regexp' set to '.*/(install|config)(.author)?$' from filename quickstart-author-4502.jar

      System property 'sling.run.modes' set to 'author' from filename quickstart-author-4502.jar

      Verbose mode - stdout/err not redirected to files, and stdin not closedcrx.quickstart.build.number=

      DiskSpaceUtil.getMaxOpenFiles() reports a maximum of 2147483647 open files, meets our requirement (8192)

      PortSelector: Selecting server port from supplied list: 4502

      PortSelector: Trying port 4502

      PortSelector: Successfully bound to port 4502, will use it

      PortSelector: Selected port 4502

      Build number not changed, software update not needed

        • 1. Re: Unable to debug with CQ5.4

          i have the same problem ... any help will be appreciated!

          • 2. Re: Unable to debug with CQ5.4

            Same issue here. When trying to debug on a jsp in CQ5.4 everything works fine, but when I try to step into a java class, I got thrown a "source not found" instead of my java code, although the call stack reflects the line we hit well and the variables update ok. I would be able to work even if the debugger doesn't take me line by line through the code, only by looking at the line the call stack hit, but I get the annoying "source not found" windows which I continously need to close to see my code. Any help would be appreciated.