I recently posted about a bug in MonoMac in which the window would abruptly disappear after clicking on a button 20 times or so. That bug, it turned out, doesn't seem to affect Xamarin.Mac, so I switched my project to that.
But now I'm seeing virtually the same bug in a different context: after typing a few lines of text into an NSTextField, the window disappears in exactly the same manner. No error, no exception; it just vanishes. Poof, gone!
I've reproduced this in a trivial project: you can see it yourself by creating a new empty Xamarin.Mac project, adding this code in a new file, and running. Then mash the keyboard a little while. After 5 or 6 lines, the window disappears.
(Note that the app menus continue to work, writing log messages and executing my code when I select the menu commands. So it doesn't appear as though the app itself has crashed.)
Curiously, this seems to only occur when the field is inside an NSView subclass where IsFlipped has been overridden. But it doesn't matter whether IsFlipped returns true or false -- if the method is there at all, the bug occurs; if commented out, the bug does not seem to occur.
So: Has anyone else run into this sort of bug in Xamarin.Mac? Perhaps in other contexts that will give us more clues as to a root cause? Any debugging tips for a Xamarin newbie?
(I know I could work around it in some projects by avoiding IsFlipped, but I worry that it would just pop up to bite me in some other way.)
OK, it turns out that this isn't a bug in Xamarin.Mac at all, but in my code. Because I wasn't retaining a reference to the NSWindow object, it went out of scope, and as soon as the garbage collector gets around to noticing it, it's disposed and the GUI window is torn down.
All we have to do is retain a reference to the window (for example, in the AppDelegate class), and the problem goes away.
Hats off to Chris Hamons at Xamarin, who jumped right on this and quickly found the problem for me.
Related
I'm having a really strange problem that I just can't figure out. Things I compile in Visual Studio 2015 (C# projects in WinForms and WPF) will not launch outside of Visual Studio. This includes a project that is completely new and untouched. As in, create a new WPF Application, build in debug and release. Go to containing folders click on EXEs and...nothing.
When I run them I get 3 processes appearing in Task Manager (named the same as my application) than cannot be killed (through task manager or command prompt) and nothing else occurs. Nothing in event viewer that seems to correspond to the app. I've attached an instance of VS 2015 to the process and I get the following message: WpfApplication.exe has triggered a break point. Pressing Break takes me to a screen that tells me no debug information is available and pressing continue has no visible effects (I can occasionally see slight movement in the cpu % but not a lot else). Any attempt to stop debugging will cause visual studio to hang and when I end its process VS closes but its memory is not freed up according to Task Manager. All of these same things occur when building in VS2013 and attempting to run outside of VS. Everything runs just fine when run in debug mode inside Visual Studio but outside of it...not a chance.
I literally have no idea where to proceed from here. I can find no error messages or clues to point me in a direction to look. Is there something I'm missing/doing wrong? What steps can I take from here to find the source of the problem?
I've considered it may be something wrong with my computer but I want to explore the possibilities before I do something drastic like a clean install. If the prevailing opinion lies that way then I'll seek help elsewhere!
tl;dr: launching the exe of a compiled application results in no running application and no obvious error messages, how can I proceed from here?
I'm going to post an answer to this because I found out what was wrong but it probably isn't useful to have it hanging around so I'll just delete the question at some point soon.
The main lesson to remember is that the main purpose of anti virus software is to frustrate you as much as possible and if something weird is happening try turning it off briefly and see what happens. You'll probably find that things are now working correctly.
EDIT: I should restate this in a more serious fashion.
Anti virus can sometimes affect things in unexpected ways and turning it off temporarily can save you a lot of time. Keep it up to date too, mine was a version or so old and was not functioning correctly. I updated it and the deep scan now functions as expected rather than silently failing.
The "Build" menu appears as it would if the solution were building, but the Cancel Build (Ctrl+Break) menu item has no effect.
Trying to close the application prompted as:
The build must be stopped before the solution can be closed.
Can anyone help me to resolve this problem?
Do this, look for msbuild process(es) and kill them before devenv. And make sure vbc really has gone too....
For any further crashes that occur frequently submit them to microsoft so that they can fix the bug...
Hoping it helped....
I was having this problem and I think I discovered why.
I was drawing way outside the boundaries of a bitmap and it was overwriting some memory location that affected Visual Studio.
I added a line of code as a safety while testing that looked for when writing bitmap.Top < 0 or writing > bitmap.Width or > bitmap.Height.
This is supposed to be trapped by Visual Studio but I think it's getting by.
In straight C it's called a wild pointer.
Working with Monodevelop has been a nightmare overall. But among all the crashes, I have been able to recreate one of them reliably.
It seems like when I type "o" (the letter) when Monodevelop expects me to type an integer it will always crash.
Examples:
if (spriteRenderers.Length == o <----*CRASH*
for (int i=o <----*CRASH*
Now, of course, this typically only happens when I've made a mistake, but it does seem to be causing the crash.
And by "crash" I mean that Monodevelop stops working, and I get an error message from Windows asking if I would like to force quit the application. Upon re-opening Monodevelop it shows a blank white screen (every time).
The only fix I've found for the white screen is to delete the "Assembly-CSharp..." files in the project folder and then resync the Monodevelop project in Unity3D. I sometimes have to repeat this up to 10 times before Monodevelop will work again, and about half the time I lose a significant amount of work as a result.
Has anyone else experienced something similar? Any ideas on how to prevent this type of crash?
PS: It also tends to crash a lot when I'm typing "default" within a switch statement, but not every time like the "o" instance above.
If typing a specific letter crashes monodevelop there's certainly something going totally wrong here. First, confirm whether typing 'o' crashes monodevelop anywhere in any situation. Because I find it hard to believe that it crashes only when you type o where 0 is expected - because how would monodevelop know what is "expected" in a given situation? So unless that is confirmed, I assume this is not what is actually going on but rather something that you've came to conclude due to confirmation bias (ie it happend two or three times by chance in a situation where you intended to type 0 rather than o).
That said, check if any keyboard shortcut has been assigned to the letter o. You may want to reset keyboard shortcuts to their default. In general you may want to reset all preferences just to ensure monodevelop is using safe defaults for everything. Also check any plugin you may have installed, and disable them if only for testing.
You should also try shutting down Unity, and only run monodevelop. Then create a standalone project in monodevelop (ie C# windows app) to see if the problem also appears in "regular app development mode".
Lastly, upgrade Unity. If you are already on 4.6, get the latest "patch release" from the download page. This might also give you an updated monodevelop.
If all of that does not help, you may want to try Xamarin - the latest version of monodevelop. You can integrate that with unity by installing its Unity plugins, but currently it will not allow you to debug with Unity. In any case it installs itself side-by-side, so you should at least try that to see whether that has a similar problem.
If all of that fails, consider that the problem may be with your system. For instance a tool might have set a global keyboard shortcut on the letter o. A virus scanner or system driver may somehow interfere. Or the whole system is just whacky, perhaps a trojan, a hardware failure, and so on. That is all rather speculative, so at this point it's a matter of trial and error.
We have a WPF app which runs fine, but a user reported that it locks up when the screen is rotated. (Tablets will do that!)
The app actually renders fully after the rotate but stops responding to the mouse/keyboard. It doesn't show as 'non-responding' in a Windows sense.
We can simulate the "lock up" here, but debugging this is odd:
Lock up does not occur while in VS debugger
If you try and attach to the locked up process, VS says the process was built without debug information
Before the lockup VS can attach/deattach to the same EXE process
We have put trace outputs in global unhandled exceptions but nothing is fired.
I can only think of one next step to debug which is start to hack out chunks of code and find the breaking area.
Anyone seen this before or got any suggestions?
Thanks!
The issue was with an update library we were using called Sparkle.
It was creating a hidden WinForms form in it's constructor. There must be some kind of WPF/WinForms interop bug during screen rotations. Removing that form or removing the library fixed the issue.
I might have a hard time explaining this because I am at a total loss for what is happening so I am just looking for some guidance. I might be a bit wordy because I don't know exactly what is the relevant information.
I am developing a GUI for a project that I am working on in using .Net (C#)
Part of the interface mimics, exactly, what we do in another product. For consistency reasons, my boss wants me to make it look the same way. So I got the other software and basically copied and pasted the components into my new GUI.
This required me to introduce a component library (the now defunct Graphics Server GSNet, so I can't go to them for help) so I could implement some simple graphs and temperature/pressure "widgets."
The components show up fine, and when I compile, everything seems to work fine. However, at some point during my programming it just breaks. Sometimes the tab that these components are on starts throwing exceptions when I view the designer page (A missing method exception) so it won't display. Sometimes JUST those components from the GSNet library don't show up. Sometimes, if I try to run it, I get a not-instantiated exception on one of their lines of code in the designer code file. Sometimes I can't view the designer at all.
No matter what I do I can't reverse it. Even if I undo what I just did it won't fix it. If it happens, I have to revert to a backup and start over again.
So I started to backup pretty much every step. I compile it and it works. I comment out a line of code, save it, and then uncomment that same line of code (so I am working with the same exact code) and the components all disappear. It doesn't matter what line of code I actually comment out, as long as it is in the same project that these components are being used.
I pretty much have to use the components. . . so does anyone have any suggestion or where I can look to debug this?
The only thing that comes to mind is a read-only bin directory. I've found that .NET has trouble if the interop libraries in the bin directory are read-only. Read-only interops generally prevent controls using those interops from displaying in the form designer and thus mess up compilation (if you do a full build anyway). A rebuild might let you get the app running and then fail when it reaches the part using the read-only interop.
This may or may not be your problem but it's all that comes to mind.
I know this is very late to the game, but I just ran into this same problem.
I'd pulled down one of our applications from SVN, and when I first tried to open the main form for editing, I was prompted with the custom component not being defined in the software, even though I could plainly see it as a class. I was given a choice to ignore it, which I did, and the custom control promptly disappeared from the form (still showed up in the project).
So at the suggestion of my colleague, I deleted the instance from my hard drive, and re-checked it out from SVN. Before i did anything else, I built the project for both release & debug, and that fixed the problem.
Maybe this'll help someone else who finds this SO question when they run into this.