Mono command line program dies with "trace trap" message and nothing else - c#

I have a command line Mono application running on the Mac (OSX Lion) and it dies misteriously with the following message:
[1] 53342 trace trap "/Library/Frameworks/Mono.framework/Versions/2.10.9/bin/mono" --debug
read: -p: no coprocess
This is running the app from MonoDevelop.
Anyone has any idea what is happening and how I can fix this? (or how I can try to figure out what it is)

Neither how to fix it, nor how to figure out what it is, but to isolate the problem:
Run it outside MonoDevelop. If it works, report a bug to MonoDevelop.
Run it outside MonoDevelop with the latest version of Mono (2.11.3). If it still fails, file a bug to Mono.
(If you have access to a Linux box, try there too because it may be a bug in Mono that only affects Mac platform.)
Bugs are filed in http://bugzilla.xamarin.com/

In the end the issue was that there was code like this in the app:
#if DEBUG
Debugger.Break();
#endif
The application was being compiled in Debug and I was running the app like this:
mono Cli.exe
And when the interpreter found this piece of code, there was no debugger available when the trap signal was sent. While on Windows a dialog is opened asking you if you want to debug the app, on MacOS the application just commits suicide. The fix was to not execute this code if running on a Mac (or running the app inside of GDB).

Related

App getting crash when app start on Testflight

In versions, 1.1 and 1.2 app runs fine. I have created a new build-1.1 on Version-1.3. The app works fine in debug mode without any crash when I distributed the app to testflight my app getting crashed.
Note: I haven't Enable Device Specific Build.
I configured the provisioning profile and bundle Id correctly.
Don't know what is the issue. If anyone facing the same issue please answer the question?
It could be a lot of reasons! One way to get to the reason:
When the app crashes, it generates a crash report on the device. Connect the device after the crash to Xcode, open "Devices" window and check the devices crash reports and the console to find out what is happening.
Possible things to try:
It seems like it's a compiler issue. To verify first change the configuration to Release mode and then install the build locally to your phone. You will get to know where exactly its crashing.
Are you using the same Build Configuration (Debug/Release) while debugging on a device and the testflight app?
If not, it could be because of Optimizations being enabled, or unsupported Linker behavior in the iOS Project options.
If yes, try to upload a Debug version of the app into Testflight and retest it

Exposing an Elusive Program Crash - Crash Dump Issue

On Windows 10 and using Visual Studio 2015, I'm trying to debug a WPF C# application that incorporates C++ PInvokes. After the app starts, a particular execution path causes the app to crash, which then shows this message:
vshost32.exe has stopped working
A problem caused the program to stop working correctly. Windows will close the program and notify you if the solution is available.
I take the "Debug" option provided on that dialogue, and then it says:
A debugger is attached to MyWpfApp.exe but not configured to debug this unhandled exception. To debug this exception, detach the current debugger.
This is frustrating. When the crash occurs, it is being debugged by Visual Studio 2015. Why is it "not configured to debug" this problem? Can the configuration be modified to catch this?
At this point I'm stuck. I tried issuing a "detach all" command to VS 2015, so that the OS can start a new debugger, but VS 2015 refuses to detach. If I instead simply stop VS2015, then the OS says that the crash can no longer be debugged, because the process was terminated.
In short, I can't debug the problem - even though I have best-in-the-industry tools pointed directly at it.
Any suggestions of how to debug this mysterious crash?
I do have additional information about this problem, because I also tried to debug it on a Windows 7 machine within Visual Studio 2013. It has the same crash. In this case, the crash simply causes the debug session in VS 2013 to suddenly end without warning - as if the program had terminated gracefully. In an effort to capture the crash, I activated crash dump capture via Windows Error Reporting (WER).
It worked! First, I got this info:
Unhandled exception at 0x77BC46A9 (msvcr120.dll) in MyWpfApp.exe: An invalid parameter was passed to a function that considers invalid parameters fatal.
The stack trace then showed me the exact line of managed code that transitions into unmanaged, and eventually reaches msvcr120 which crashes.
Unfortunately, after this initial success, my debugging success ended here because suddenly the WER configuration on the Windows 7 development machine simply stopped capturing any further crashes. I thought it was code changes I had made which jinxed WER, but when I reverted my changes WER continued to be unaware that the application was crashing.
So in the end, this crash is doing its best to be untrappable - preventing me from capturing a crash dump. I also tried running the app from the command prompt, and attaching sysinternals procdump to it:
c:\>procdump -ma -e -accepteula -x . MyWpfApp.exe
Surprisingly, this also didn't work. The OS caught the crash and reported it, while procdump was entirely unaware the crash had occurred.
Is there a "bigger hammer" I can use that will ensure I can capture crash dumps?

SHIM_NOVERSION_FOUND error while trying to run screensaver from preview

I have an not trivial task to do. I need to run website as a screensaver in windows 8. So I used next approach to achieve it:
http://www.codeproject.com/Articles/31376/Making-a-C-screensaver
The solution is working well when I run from the Visual studio or run a compiled .exe or .scr directly. But when I try to set the resulting .scr as a screensaver and try to push preview button in windows 8(on the same machine where the same .scr is running well) I get the error - "SHIM_NOVERSION_FOUND".
I found that this error can appear when required version of .NET framework is not installed, but it's not my case cause when I run directly that '.scr' it's working.
Thanks for any advance!
Problem has been solved, I've just put screensaver.scr to c:/temp folder and all started working, probably I didn't have some kind of rights to access screensaver from c:/windows/system32

Connect Xamarin to Virtual Box

I want to port my C#-Code to linux, so i have to debug under Mono.
Therefore i would use a VM Box with Linux OS and conect the Xamarin Studio, that runs under Windows, to the Box to debug on it with Mono.
Is it possible to connect my Xamarin Studio to the Oracle VM Virtual Box?
I tried it several times but the debugger didn't Start in 10 minutes. If i closed Xamarin during this starting process there was a this Message: Couldn't connect to Debugger.
If you have an other(easier) way to debug with Windows under Mono i am openminded for everything.
Does remote debugging still work?
https://ebsteblog.wordpress.com/2013/12/04/remote-debugging-with-monodevelop/
For those who are interested: Seems that it is possible. You have to connect the Xamarin to your VM Device and there you star the debugger agent. I couldn't start it yet but theoreticaly it should work. There's the problem:
patrick#patrick-VirtualBox:~$ mono --debug --debugger-agent=transport=dt_socket,adress=X.X.X.X:12345,server=y OSTest.exe
Cannot open assembly 'OSTest.exe': No such file or directory.
* Assertion at threads.c:391, condition `shutting_down' not met
Stacktrace:
Native stacktrace:
Don't know yet what this means.

Fatal Execution Engine Error

All,
I have a console application which is written in .NET 3.5 which retrieves data from a database, does some calculations and post messages in a message queue.
I run the .exe on my PC which runs without any problems. Deploying the .exe in a 64 bit server the application suddenly stops without any errors and when I use the DebugView utility I can see the below error.
[6276] Fatal Execution Engine Error (7A09C12F) (80131506)
I tried compiling with x64, x86 and Any CPU but still the same problem. I tried deploying to another server and still same situation. Anyone has an idea how I should proceed to determine the root cause?
Many Thanks,
MK
Capture a crash dump and analyze it for the root cause.
Link
If you like, open a support case via http://support.microsoft.com

Categories

Resources