Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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
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.
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:
Marking NEEDINFO and reassigning to the Text Editor component (already checked that the Debugger always uses TryReuseViewer).
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)
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.
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:
and give us the results ? Maybe that'll help to track me the issue.
Ohhh Noooooooess.. It's due to a symlink. Wow. That's ridiculous.
Anyway, good to know where all these issues from the past came from.
But hold on. The real path is
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?
fixed in 126.96.36.1994
It's a bit more complex - the editor problem should be resolved. The debugger issue remains.
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.
Well my case presumed other circumstances:
The real project path is
There's a symlink from
I've opened a project that is located inside
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 :-/
fixed in git master
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.
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.
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.
XS debugger already fully resolves symlinks. There's nothing more that the debugger code can do...
Well, the debugger does. But what about the debug data gen (if there is any)? Is that one referencing the right paths?
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?
I think that should fix it.
btw. however I assume that this basically reassembles the original fix from 188.8.131.524 which caused some 'side effects'.
But I fear that we can choose here which we want to have.
> 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.