Bug 5225 - Does not stop execution in breakpoint if solution is inside a symlinked path
Summary: Does not stop execution in breakpoint if solution is inside a symlinked path
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: Trunk
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Jeffrey Stedfast
Depends on:
Reported: 2012-05-21 19:28 UTC by Andres G. Aragoneses
Modified: 2015-03-16 21:52 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

First draft of a patch (4.59 KB, patch)
2012-05-29 13:35 UTC, Andres G. Aragoneses

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Andres G. Aragoneses 2012-05-21 19:28:47 UTC
I've always been able to use the debugger with Banshee, but today using MonoDevelop master, breakpoints are just simply ignored.

I've tested debugging a simple HelloWorld application and it works. So I guess there's a regression somewhere in MonoDevelop that is only exposed by projects like Banshee (maybe because of Makefile integration?).
Comment 1 Andres G. Aragoneses 2012-05-29 13:35:04 UTC
Created attachment 1981 [details]
First draft of a patch

Ok, yesterday night I finally had time to sit down and debug this (thanks to Jeff for telling me where to start looking!), and I tracked it down to this line in SoftDebuggerSession.cs:

1680: if (PathComparer.Compare (PathToFileName (bp.FileName), s) == 0) {

There, if bp.FileName and s point to the same file but one of them is a symlink-based path (in my case /home/myuser/Documents is a symlink to /home/share/Documents to make it easier for me to run in a dual-boot env), then the condition is not met and the breakpoint is not hit.

I guess the solution is to do a comparison against the result of FileService.ResolveFullPath() function, rather than just a comparison of the file path string.

I was going to do the bugfix and a pull request but it's not as easy as it sounds, because that line of code is part of the project "Mono.Debugging.Soft", which is a dependency of "MonoDevelop.Debugger.Soft", and this assembly doesn't link to MonoDevelop.Core assembly. When I do that, I get the following error when compiling:

error CS1577: Referenced assembly `MonoDevelop.Core, Version=, Culture=neutral, PublicKeyToken=null' does not have a strong name
Compilation failed: 1 error(s), 0 warnings
make[5]: *** [../../../../build/AddIns/MonoDevelop.Debugger.Soft/Mono.Debugging.Soft.dll] Error 1

So not sure if this can be solved easily. Any help appreciated (attaching the WIP patch here).
Comment 2 Jeffrey Stedfast 2012-05-29 16:07:11 UTC
Cool, thanks for tracking this down.

I've committed a fix to git master
Comment 3 Andres G. Aragoneses 2012-05-29 16:57:50 UTC

(BTW I was also thinking about doing sort of what you did, but don't you think there's so much duplication going on in that Mono.Debugging.Soft assembly? For example, the Platform detection is copy-pasted from MonoDevelop's platform class as well)

On another note, I have unfortunately found another bug, which I've filed as bug 5400.