Encounter Bogus Errors When Debugging XSLT

[Jamil]

I am experiencing an issue with the latest build of the stand-alone editor: 15.1 build 2013110816

Debugging XSLT does work correctly. However, it appears as if the application retains state that is stale when attempting to debug a second time. I have reproduced this issue a few times with this build. I am not sure if it has already been reported.

To reproduce this, debug a valid XSLT that has a transform scenario already configured. The debug session will work as it is supposed to. Next, end the debug sessions and return to the editor. Make a change to the XSLT transformation followed by saving the changed document. Try to debug again using the same configured scenario. In my case, I get bogus errors (something about a return code being 1). These errors go away when I exit the editor followed by relaunching it. I can then debug my XSLT successfully.

If you need more detail on what it was that I changed, I can post details. The symptoms I posted seem to indicate that the code is retaining stale state.

[adrian]

Hi,

We are not aware of such an issue in v15.1.
Is this in the standalone edition or the Eclipse plugin?

Could you please provide a step by step procedure to reproduce this (using the name of the actions or buttons used)?
I'm particularly interested in the transitions between editing and debugging. Are you simply switching between the perspectives by using the top right tolbar icons? Or are you using the Document > Transformation > Debug Scenario action (also in the toolbar) to start the debugging?

While the state of the transformer is reset between sessions, the XSLT debugger configuration is only updated/reset if you use the Debug Scenario action. If you simply switch perspectives between editing and debugging, you will continue where you left off from the previous session configuration.
You should check if you have the Link with editor toggle activated in the toolbar (icon with two arrows pointing left), since that automatically switches the XML and XSL involved in the debugging depending on the currently selected editor in each editor tab group. So, if you have that toggle enabled, you could inadvertently end up running the debugger with files different than the ones configured in the scenario.

Regards,
Adrian

[Jamil]

This is the stand-alone editor. I am running the latest available version. I originally experienced the issue on my home desktop computer. This was where I saw the error in the Messages tab of the debugger. I am in the office now attempting the same on my laptop. I an experiencing different behavior on my laptop that also does not look correct. I am not seeing the error message on my laptop though. I do not have the Link With Editor option turned on (never used it before).

For my laptop, I am using Step Into throughout the XSLT when debugging. What ends up happening for my laptop is that I see no output in the text section. I am unable to tell if the XSLT is working as it should through the debugger (I don't have this issue on my home computer). After trying this a few more times on my laptop, I see what is going on now-- Step Into is skipping over sections of code that I am expecting it to debug. The debugger is running the code and clearing the Text output tab when it is done.

Again, this is different than what I experienced on my home computer. As soon as I get home, I will try it again.

[Jamil]

I am at home now using my desktop. I reproduced the issue here. I do not see an error message, but the Debugger Errors tab shows the following:

E -1

Processing simply stops. The stylesheet works fine outside of the debugger. I only have issues when debugging. Also, the issue appears to not be related to changing files. It sporadically happens. If I remain in the debugger session and click Step Into, sometimes it works. If I keep clicking Step Into, it will sometimes show the debugger error above. This error does not refer to the stylesheet at all.

Also, the text output remaining as blank also happens on my desktop. It appears to be skipping over stylesheet syntax that it should step into. The only way I got to see it on my laptop was set a break point in the stylesheet for the section it is not stepping into.

[adrian]

Hi,

For my laptop, I am using Step Into throughout the XSLT when debugging. What ends up happening for my laptop is that I see no output in the text section. I am unable to tell if the XSLT is working as it should through the debugger (I don't have this issue on my home computer). After trying this a few more times on my laptop, I see what is going on now-- Step Into is skipping over sections of code that I am expecting it to debug. The debugger is running the code and clearing the Text output tab when it is done.

On the laptop, does it work any different (check the output) if you simply press Run in the debugger (instead of stepping into)?
If it's not any different, the problem may be with the stylesheet (e.g. wrong namespace). That would explain why it skips the sections (they may not match the stylesheet template pattern).
This might be unrelated to the original issue you reported.


On your desktop, right click on the error message ("E -1") from the Errors view and from the contextual menu pick Show message. If there is a button named Details or More, press it and you should see the detailed stack trace of the error. Please send that detailed stack trace if one is available.
If that's not available, simply right click on the error from the Errors view and choose Copy. There may still be some hidden details there.


I would need a step by step procedure to reproduce this, and preferably some sample XML and XSL files. If you are willing to help us investigate this, please contact us on our support email address: support AT oxygenxml DOT com

Regards,
Adrian

[Jamil]

The answer to your first question is yes. When I Run within the debugger instead of stepping, I see the output as I expect. My stylesheet does not use additional namespaces other than xmlns:xsl="http://www.w3.org/1999/XSL/Transform" and xmlns:xs="http://www.w3.org/2001/XMLSchema". It should not be a namespace issue.

Unfortunately, the power supply of my desktop decided to die yesterday. I will not be able to test more until the replacement arrives and I have it swapped. So far, my desktop is the only machine that I have experienced the debugger error. I should have it working again within the next four days or so. I will follow up and send a report at that time.

[Jamil]

I just got my desktop back today. I tried a few times with the XSLT from the same project that I experienced the E -1 debugger error days ago. I now cannot reproduce the issue, so I am guessing that the debugger error was a hardware issue of some sort. In addition to the PSU being replaced, the shop also removed all dust from the case.

There are still some issues related to not seeing debugger output and not being able to step into all stylesheet code. I will send examples of debugger issues via email.

[Jamil]

I posted too soon. It just happened again. When I see the E -1 debugger error, there is no details or show more button. It simply shows "Description -1".

[Jamil]

More information that may help shed some light on this problem--

I think the issue is due to a bug of some sort. After getting the E -1 debugger error several more times with the same stylesheet, I closed Oxygen XML Editor. Instead, I opened the same project in Oxygen XML Developer. I stepped into to the same stylesheet many many times without ever seeing the debugger error. It appears that Oxygen Developer is using the same settings I set for Oxygen Editor.

So what is different between the two? For the editor, I edited the oxygen15.1.vmoptions file. I increased the first time to the following:

-Xmx4096m

This reserves 4GB of memory for the JVM, since I sometimes work with very large XML docs. Other than this difference, everything else seems to be the same. This is the 64-bit version of Oxygen, by the way.

[Jamil]

I have confirmed that the debugger error is a result of setting the -Xmx parm of vmoptions to 4096. I changed it to 1500 to match Developer and did not encounter the E -1 debugger error in testing. 1500 works, but 1024 shows the E -1 error still less frequently than 4096.

[adrian]

Hi,

If you are willing to assist us in investigating this, could you please assist us with a log file?
I've sent to your email address the details to enable logging.

Regards,
Adrian