This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
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 (show other bugs)
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)

See Also:
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
Details | Diff

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.

Note You need to log in before you can comment on or make changes to this bug.