Bug 21617 - XS not enabling breakpoints due to symlinked project paths
Summary: XS not enabling breakpoints due to symlinked project paths
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: Trunk
Hardware: PC Linux
: High normal
Target Milestone: master
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2014-07-26 03:51 UTC by alex
Modified: 2015-03-02 13:36 UTC (History)
4 users (show)

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


Attachments
When force-enabling (via Debugger.Break() ) and then hitting a breakpoint, MD opens a document again with an absolute file path in its Name property (100.17 KB, image/png)
2014-07-26 03:51 UTC, alex
Details


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:
Status:
RESOLVED FIXED

Description alex 2014-07-26 03:51:23 UTC
Created attachment 7494 [details]
When force-enabling (via Debugger.Break() ) and then hitting a breakpoint, MD opens a document again with an absolute file path in its Name property

See screenshot.

When being in the left Program.cs file (entitled Program.cs) and setting a breakpoint, the mono debugger will not trigger at that position at all.

When putting in a Debugger.Break(), MD does break and opens the Program.cs (depicted in the screen shot) again with an absolute file path in its Name (/home/lx/.../Program.cs)

This behaviour is easy to reproduce -- The code is located at https://github.com/aBothe/Xwt.Sdl


I suspect MD is not sending an absolute file path to the soft debugger, or the soft debugger does not know how to interpret relative file paths. Or MD should test to send both relative and absolute file paths to the debugger in order to be sure.
On the other side, MD should definitely be able to 'normalize' an OpenDocument-call's file name parameter so it won't open a file twice at all.
The editor is furthermore not doing anything in terms of code completion/semantic highlighting, as it's magically not recognizing a link between the file and the project.
Comment 1 Jeffrey Stedfast 2014-07-28 16:08:01 UTC
What version are you using? AFAICT, current git master does not seem to have this problem and the code suggests that it shouldn't happen either:

https://github.com/mono/monodevelop/blob/master/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/Workbench.cs#L475

Marking NEEDINFO and reassigning to the Text Editor component (already checked that the Debugger always uses TryReuseViewer).
Comment 2 alex 2014-07-28 16:35:38 UTC
No chance.

I just rebuilt MD 5.3 from git master
with Mono 3.6.1 (master/2fa4d25 Mi 9. Jul 01:09:11 CEST 2014) (64-bit) 
and GTK+ 2.24.24 (Adwaita-Manjaro-dark theme)
on
Linux lx-laptop 3.15.6-1-MANJARO #1 SMP PREEMPT Fri Jul 18 09:43:27 

Still, when running the Xwt.Sdl.Tests project and trying to set a breakpoint even just in the executed project's Program.cs, it won't hit by default and still has this file pathing error.

On other projects, this usually won't happen, indeed. So fortunately, I'm able to easily reproduce this issue again and again on a known bunch of sources.
Comment 3 Mike Krüger 2014-07-29 00:37:39 UTC
It works for me.

I have no idea what may go wrong there (except you use a file system that isn't case sensitive and something is wrong with the caseing).

Can you put a:

Console.WriteLine ((doc.FileName.CanonicalPath == info.FileName) + ":" + doc.FileName.CanonicalPath + "," + info.FileName);

right before this if:

https://github.com/mono/monodevelop/blob/master/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/Workbench.cs#L475

and give us the results ? Maybe that'll help to track me the issue.
Comment 4 alex 2014-07-29 04:03:15 UTC
False:
/home/lx/Arbeitsfläche/Projects/Xwt.Sdl/src/Xwt.Sdl.Tests/Program.cs,
/home/lx/Dokumente/Projects/Xwt.Sdl/src/Xwt.Sdl.Tests/Program.cs

Ohhh Noooooooess.. It's due to a symlink. Wow. That's ridiculous.
Comment 5 alex 2014-07-29 04:09:46 UTC
Anyway, good to know where all these issues from the past came from.
But hold on. The real path is 
/home/lx/Dokumente/Projects/Xwt.Sdl/src/Xwt.Sdl.Tests/Program.cs
and I opened the project via /home/lx/Desktop/Projects 

So how does Mono figure out the actual physical file path or why isn't it taking the symlinked one? 
Shouldn't MD tell or execute e.g. xbuild inside the symlink folder?
Comment 7 Mike Krüger 2014-07-29 04:47:33 UTC
fixed in 5.3.0.354
Comment 8 Mike Krüger 2014-07-29 05:39:22 UTC
It's a bit more complex - the editor problem should be resolved. The debugger issue remains.
Comment 9 Mike Krüger 2014-07-29 05:57:28 UTC
If I've a sym link

a.cs -> b.cs -> c.cs

and I open a.cs the file name is now c.cs. 

It's added to the breakpoints as 'real' c.cs file.
Comment 10 alex 2014-07-29 07:04:37 UTC
Well my case presumed other circumstances:

The real project path is 
/home/lx/Dokumente/Projects/Xwt.Sdl/src/Xwt.Sdl.Tests

There's a symlink from
/home/lx/Arbeitsfläche/Projects to
/home/lx/Dokumente/Projects

I've opened a project that is located inside
/home/lx/Arbeitsfläche/Projects/Xwt.Sdl/src/Xwt.Sdl.Tests

When building, xbuild generates the mdb info using real absolute file paths, not relative ones.

Perhaps it's not needed to resolve the symlinked path in the editor but only when we're immediately handling breakpoints.

So, only when setting a breakpoint, one had to temporarily resolve a document's real path in order to have it set properly.
Furthermore, when hitting a breakpoint, and if the file which is inside a symlinked directory is not open, it'd just open it..but here it had to check whether a directory 
that contains a file equally named to the file to open 
is symlinked to the directory of the breakpoint's location.

Indeed, very complex and tricky :-/
Comment 11 Jeffrey Stedfast 2014-07-29 17:19:00 UTC
fixed in git master
Comment 12 Mike Krüger 2014-10-29 03:23:03 UTC
I needed to revert that fix. We need to handle sym linked files somwhere in the debugger/breakpoint code.

Doing that on document level causes too many issues in the vcs, code completion and so on.
Comment 13 Mike Krüger 2014-10-29 03:43:23 UTC
IMO that may even be needed to be done at compiler level

I don't know if it's needed to resolve sym links there.
Comment 14 Marek Safar 2015-02-11 05:57:04 UTC
Bumping the priority as maccore is now full of symlink and this makes quite hard to use debugger because when stepping through code XS editor opens wrong (not-symlinked) file and touching this file overwrites the symlink is causing all sort of problems in MT.
Comment 15 Jeffrey Stedfast 2015-02-20 11:51:14 UTC
XS debugger already fully resolves symlinks. There's nothing more that the debugger code can do...
Comment 16 alex 2015-02-20 13:05:56 UTC
Well, the debugger does. But what about the debug data gen (if there is any)? Is that one referencing the right paths?
Comment 17 Andres G. Aragoneses 2015-02-23 16:38:28 UTC
It's quite possible that this bug is a duplicate of bug 27098 (or the other way around, since that one is newer than this one), which has just been fixed by this commit: https://github.com/mono/monodevelop/commit/32e25eaa9298cc97d324636f983561c3c2b223c3

So, please, can the reporter of this bug (or other person) re-test this with monodevelop master to see if it has been fixed, please?

Thanks
Comment 18 Mike Krüger 2015-02-23 16:52:53 UTC
I think that should fix it.
Comment 19 Mike Krüger 2015-02-23 17:01:06 UTC
btw. however I assume that this basically reassembles the original fix from 5.3.0.354 which caused some 'side effects'. 

But I fear that we can choose here which we want to have.
Comment 20 Andres G. Aragoneses 2015-03-02 13:36:23 UTC
> which caused some 'side effects'

I think I found one of those side effects, very cosmetic, which I filed as bug 27331. But I already proposed a pull request to fix it.