KomodoIDE pro v10.2.3, on windows host, sometimes skips breakpoints from linux host

[ghost]

Short Summary

The URI Map associates a URI (from the remote "guest" machine) with a file location on the local host machine. The "Maps to" value of each typically includes a drive letter (on Windows) such as "c:".

If the "File" set in a breakpoint by the IDE uses a different case ("C:"), then the breakpoint as reported to the guest (using xdebug) will contain the local file value rather than the "URI".

The result is that the remote (guest) machine will not stop at the breakpoint.

Steps to Reproduce

I don't know how to cause it to happen, it seems random/arbitrary. The behavior can be simulated by editing "breakpoint properties" within the IDE to change the case of the drive letter for a working breakpoint. After that change, the breakpoint will be ignored.

Expected results

I expect the drive letter in a URI mapping to be case-insensitive, and it is is not.

I expect that when I set a breakpoint from the IDE on a file that is in a mapped directory tree, then execution of that file on the remote "guest" will stop at the breakpoint.

Actual results

Here is an excerpt from the xdebug log on the remote guest. The first response shows the case with a mismatch, the second with a match. The mismatch was unintentional ... the IDE for some reason capitalized the drive letter.

<- feature_get -n urimap -i 18 -> <![CDATA[0]]>

<- breakpoint_set -t line -f file:///C:/projects/csiws.trunk /gateway/EncryptionManager/EncryptionManager.php -n 577 -s enabled -r 0 -h 0 -i 19 ->

<- breakpoint_set -t line -f file:///media/csiws.trunk/test/phpunit/gateway/EncryptionManager/CrossPlatformIntegrationScenariosTest.php -n 88 -s enabled -r 0 -h 0 -i 20 ->

Platform Information

Komodo Edit or IDE? Komodo IDE Komodo Version? 10.2.3 Operating System (and version)? Windows 7 Professional, Service Pack 1, all relevant windows updates applied. Remove OS and version CentOS 6.7, running on VirtualBox. I'm using the Komodo-specific xdebug.so (from the downloads page).

Additional Information

My workaround is to manually edit the drive letter in the "breakpoint properties" when I notice that it is being ignored. Sadly, once it is in "upper-case mode" (see screenshot), then when I manually lower-case the drive letter as above, subsequent attempts to remove the breakpoint in the main code window by clicking on the red dot cause a second bogus breakpoint to appear.

Once edited in this way, the breakpoint can only be removed by opening the "Breakpoints" tab and removing it from there.

Here is a screenshot, showing the bug as it just now appeared...

[Naatan]

So essentially this boils down to breakpoints being case sensitive when they shouldnt be?

This might be a bit challenging to fix seeing as some filesystems are in fact case sensitive. But reading through your report it sounds like it's always the drive letter at fault, is that correct?

[ghost]

Yes, it's only the drive letter that I see changing.

It's the unpredictability of what the IDE will do that's troubling. I always add breakpoints by clicking in the code view. Sometimes the resulting breakpoint goes in with a lower-case drive letter and all is fine. Other times it's recorded as upper case, and gets skipped.

If the IDE is one way or the other, than I can change the entry in the URI map to match and all is well.

[Naatan]

Does the different drive letter relate to different files or can one file have upper as well as lower case driver letters in its breakpoints?

[ghost]

The files are all on in the same directory tree on the same disk ("c:"/"C:").

I haven't noticed any patterns yet, though I'm watching for that.

[ghost]

Perhaps the IDE keeps a log file somewhere locally where it records the breakpoints it's set?

I don't like to keep xdebug logging turned on on the guest because it gets so long. Though I guess there all on the same SSD so it doesn't make a different.

I'll turn xdebug logging back on and see if I can find a pattern to the case changes.

[Naatan]

You can turn on breakpoint logging with:

require("ko/logging").getLogger("breakpoints").setLevel(10);

Run this in the Console widget (bottom panel).

[ghost]

Got it, thanks!

[ghost]

Hmm. I'm running 10.2.3. I may be misunderstanding you. When I click on the "console" tab, I see an empty gray pane that doesn't let me enter anything.

Perhaps I need to enable it someplace (preferences?).

Here's a screenshot:

[Naatan]

That shouldn't happen, it looks like your Komodo install is broken.

Please try the reset options under Help > Troubleshooting.

[ghost]

Interesting. It's apparently an un-related UI bug. When I move the split-bar between the top and bottom panes towards the bottom (making the bottome pane smaller and the top pane larger), the darker-gray input region of the console appears.

[ghost]

It seems to have accepted the above command.

Just a nit ... FWIW, the prevailing UI pattern is to use a white box to indicate a widget that accepts text input, and to use gray to indicate a disabled widget. The input bar at the very bottom of the console (where console text is typed a line at a time) seems to do the reverse.

Anyway, I'm good now. I'll let it log for awhile, and when I see another weirdness with the drive letter case, I'll look at the log and see if I recognize a pattern.

[ghost]

Two more quick questions about this, please:

1. Is this log setting (from the console) persistent, meaning does it survive Komodo restarts?
2. Where is the resulting log file stored?

[ghost]

Ok, here's a screenshot of the "Breakpoints" pane showing that one is upper-case, the other lower-case.

For obvious reasons, I can't post a screenshot of the two source files.

No matter how I configure my URI map, one of these won't work.

[ghost]

When I attempt to manually set the "Maps to" value of the "Mapped URIs" pane to have an upper-case driver letter, the resulting file:// URL is forced to lower-case upon Komodo restart.

So the MappedURIs can only work with a lower-case drive letter for a breakpoint.

The first breakpoint in the above screenshot is wrong.

I think I found the logs -- they seem to be in "~username/AppData/Local/Temp/ko-temp/10.2". I see nothing there about breakpoints though, even though I entered the requested command in the console.

[Naatan]

Is this log setting (from the console) persistent, meaning does it survive Komodo restarts?

It does not survive restarts.

Where is the resulting log file stored?

Help > Troubleshooting > View Log File

Is there any difference in how you opened the two files with different path case sensitivity, or the way they are configured?

[ghost]

I've replied to you directly, with relevant logfiles and screenshots.

[ghost]

Any progress on this?

The work-around is getting less and less practical. It appears that most of my breakpoints are now being created with an upper-case drive letter. When I manually edit one (the only way to make it work), the IDE gets very confused about whether and where to show a breakpoint in the file pane. When lines are inserted in the file, the breakpoint location doesn't track them. The only way to remove one of these modified breakpoints is from the "breakpoint" pane, and the breakpoint marker is often left behind in the file pane.

I'm now having to spend enough time babying the IDE that it's a serious distraction from the deadlines I face.

[Naatan]

I'm sorry, I do not have a short-term solution for you. I will target this for 11.1 so it's at the top of our priorities list to investigate. Unfortunately it's too late to include this for 11.0, which is due soon.

That doesn't mean you need Komodo 11 necessarily, once we find the issue we may be able to instruct you how to resolve the issue in 10. But at this stage it's going to take some deeper investigating to find out exactly what is causing this.

[ghost]

My company encourages us to use PHPStorm and other Jetbrains products, we have an enterprise license for those tools.

I've been resisting the change because I've been an ActiveState customer and user for so long. This is a show-stopper, though.

I appreciate your attention. I think I'm on to another IDE.

Thanks, Tom

On 8/15/2017 3:34 PM, Nathan Rijksen wrote:

I'm sorry, I do not have a short-term solution for you. I will target this for 11.1 so it's at the top of our priorities list to investigate. Unfortunately it's too late to include this for 11.0, which is due soon.

That doesn't mean you need Komodo 11 necessarily, once we find the issue we may be able to instruct you how to resolve the issue in 10. But at this stage it's going to take some deeper investigating to find out exactly what is causing this.

-- Tom Stambaugh 66 Boston Ave Somerville, MA 02144 617-776-8934 (land) 617-721-0446 (cell)

[Naatan]

I'm sorry to hear that. Much as I'd like to fix bugs on the spot we do have priorities, timelines and QA to deal with.