I have an issue with the sqlite3_mutex_enter(v->db->mutex) error message on an iOS application.
The case is the following: I developed an application that is performing a sync on the application in the background while starting up. All SQL Statements that invoke writing to the DB are protected using a NSLOCK and are unlocked after the finalize.
Now the problem is, that the Application User can start working with the application while the sync is still ongoing. Sometimes I do get now an sqlite3_mutex_enter(v->db->mutex) when something is done on the DB level, sometimes it simply works. The cases where this error appears is mainly in read statements.
Do you have any ideas when the sqlite3_mutex_enter(v->db->mutex) error can show up? All statements are finalized properly. Something really weird is, that the SQLITE DB tries to close itself even if there is no command that tells the DB connection to close.
The statement sqlite3_mutex_enter(v->db->mutex) occurs only inside sqlite3_reset. An error in this place is likely to be caused by an invalid statement pointer, probably one that is already finalized.
Related
I have a very simple Unity WebGL project that I am trying to connect to a SQL Server database from.
When I run the project in the Editor, it works fine.
When I run the WebGL build, as soon as I try to open the DB connection I get an "Out of memory" pop-up and this error in the console:
PrototypeProject.loader.js:1 Cannot enlarge memory arrays. Either (1)
compile with -s TOTAL_MEMORY=X with X higher than the current value
2144141312, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which allows
increasing the size at runtime, or (3) if you want malloc to return
NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0
My understanding is that the advice included in the error is out of date because allow memory growth defaults to enabled and there is no total memory setting in recent versions of Unity. I can't see why (3) would be a sensible thing to do
I know the problem is triggered (every time) by connection.Open because the first of these debug lines is output but the second is not
SqlConnection connection = new SqlConnection(connectionString);
Debug.Log("Calling connection.open");
connection.Open();
Console.WriteLine("Connection open");
One option would be to stop trying to connect to the database directly and call a web service which does the database work instead. Yes, I know that having a three-tiered architecture is a better design in any case - this was approach was used in a (failed, clearly) effort to prototype something quickly
However I really want to understand what's going on here in case I might have similar issues in future. I know that SOMETHING has to be the tipping point that runs you out of memory, but just opening a connection doesn't intuitively (but maybe I'm wrong...) seem like it should be a massive memory hog and I can't see any noticeable difference when using the Profiler in the editor
Does anyone have any experience in troubleshooting SQL Server connections in particular, or memory issues in general, in WebGL that might be relevant to understanding and avoiding this behaviour?
The answer was much more rudimentary than I expected - it's just not possible to use SqlConnection in a WebGL build because SqlConnection in turn is trying to use Sockets that WebGL builds do not have access to
Exactly why this manifests as an "out of memory" error, or why the Unity Editor couldn't be a little bit more helpful and warn you that you are using classes that are not going to work when you start a WebGL build, I do not yet understand...
Let me state upfront that I truly appreciate any assistance on this issue.
I have a C# (2.0) application. This is relatively simple application that executes stored procedures based on an XML file that is passed as a command line parameter.
We use it as a tool to call different stored procedures. This application does some logging and for the most part works very well.
The application reads the stored procedure name and parameters from an XML file. It sets up a connection string and SQL Command object (System.Data.SqlClient.SqlCommand).
Then it runs the stored procedure with the ExecuteReader method.
Unfortunately on a handful of occasions this application has generated the following error:
“Application popup: StoredProcLauncher.exe - Application Error : The instruction
at "0x7c82c912" referenced memory at "0x00000000". The memory could not be "read”
This error has appeared on multiple servers so it must be a code issue.
It seems that when our production server rolls a certain number it belches out this memory error.
The problem is I don’t see this issue on development. I can’t replicate it so I’m stuck.
Is there any way to simulate this error. Can I fill up the memory on my local PC somehow to attempt to replicate this error?
Does anyone know some common coding issues that might result in an error like this?
Does anyone have some rope I can borrow?
One way to do this is to wrap the offending code in a try catch block and writing the stack trace and error message to the windows application event log, text file, email, etc.
This will give you some line numbers and additional information.
Also note, you may need to deploy this in debug mode or at least copy the .pdb file with the application exe/dll so it can get the debug symbols. Can't remember off the top of my head how that works, but I think when you deploy in release mode you may loose some valuable debug information.
The instruction at "0x7c82c912" referenced memory at "0x00000000"
This is an access violation:
An access violation occurs in unmanaged or unsafe code when the code attempts to read or write to memory that has not been allocated, or to which it does not have access. This usually occurs because a pointer has a bad value.
Why does your program have unmanaged/unsafe code? For doing what you described it needs no native code.
Alas, the code crashes and now is not the time to wonder how is ending up calling native code. To solve the issue you're going to have to catch a dump and analyze the dump. See Capturing Application Crash Dumps. There are tools that specialize in this, like breakpad. there are also services that can help you collect and track crashes generated from your app, like crittercism.com or AirBrake. I even created one for myself and made it public bugcollect.com.
(see update below)
While running within the VisualStudio 2010 environment, I can easily tell if my Winform application causes an exception. I just have to go to Debug | Exceptions and make sure that both columns of checkboxes are checked. I then run the application and if any exceptions then I get dropped straight into the offending piece of code.
How do I determine exceptions during testing, when I give test build to a tester. I do not want the tester to run within Visual Studio, just as a regular user. I still want to know if there are exceptions and the pertinent details.
Obviosualy, I should be able to control the process, so that when the code gets released normal execution happens.
Yes, I know about and use try/catch blocks, but I am talking about a method similar to Visual Studio exception catcher and reporter, just possibly compiled into the product and used for deployment to beta testers.
Maybe Visual Studio has such a feature, in which case where and how to set up, or possibly a third party component.
[Update:
I added two sub-questions, which you can find at Unhandled Exception next line or exit.
The solution mentioned below sounds great and with a tweak probably works, just not at the moment.
Inside the Visual Studio both 2010 and now 2012 works great. The exception handler gets called, okay after VS breaks at the line and I say to continue. I decided to test outside the VS2012 IDE, good thing for that. The OS traps the bug, shows the standard an "An Unhandled Exception Occurred" dialog giving the details along with a continue and quit buttons. Selecting continue, just continues the application with no trapping into my uber exception handler. Selecting quite, whites-out the application and displays the standard close window dialog. The quit button also does not call my uber handler.
The purpose is so that my exception handler gets called. I do not need an uber exception handler if I am working inside the VS2012 IDE. The purpose of the handler is for end users and beta testers, namely anyone other than myself and who will not have my development station.
So unless I am missing something, the question is still open.
There are code samples in the other question, enough to copy and paste and create a test application in a couple minutes time.
]
Thanks in advance,
Sarah
I don't know of any automagical ways to reports error in Visual Studio but here is what I do.
Hook into the UnhandledException event for the application.
Use a logging framework like nLog or Log4Net to log the exception and other data you get from that event. Or just write to a text file.
Upload that data either from within your application or have the beta-tester send it to you.
Okay, the Google Uberlord took pitty upon me and I found this wonderful article solving the problem. Praise to the almighty Google.
Here is the link:
http://www.switchonthecode.com/tutorials/csharp-tutorial-dealing-with-unhandled-exceptions
Basically, JRadness had the right idea, just slightly in error. He should have used
Application.ThreadException +=
new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
rather than
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
The author on Switch on the Code talked of three methods, the first of which is what JRadness proposed and does not work for Windows forms.
The autor even solved my other question of Continue and Abort. The OS got bypassed.
Yeah!!
While "deploying" the solution from this question on a number of machines, I noticed some single core machines have terrible results (for example, the solution fails spectacularly on an intel atom).
What is happening here is the following. I call SetWinEventHook(...) to get callbacks for console changes. Due to the out-of-contex notification there is no synchronisation between the processing of the events and further changes on the console, so while multi core machines do well (not perfect btw), single core machines make a mess of this.
So I proceeded to turn on the In-Context notification since this should be synchronous according to the msdn. In c#, this is like asking for the Infinite Improbability Drive, so I created a simple dll in C that can do the dirty work, and talk to the dll from c#. So far so good.
As it turns out the callbacks happen in conhost.exe as opposed to the process owning the console. Now this presents a problem since in the callback I can't find a way to access the console output buffer in the context of conhost.exe. Or more precisely, I can't seem to find a way to obtain a handle to it. Here is what is avaliable: Handle to the console window, process id's of both the console application and conhost.exe and a pipe to the console application.
And here is what I tried sofar:
using GetStdHandle(...), results in invalid handles (makes sense in the context of conhost.exe)
using CreateFile("CONOUT$"...), dito
using the pipe to have the console application read from the output buffer, results in deadlock. I suspect a locking mechanism for preventing reads while writing, that would make sense.
duplicating the output buffer handle and passing it via the pipe. No joy because console handles cannot be duplicated to an external process.
attaching the conhost.exe process to the console of the console process it is serving and then do the CreateFile thing. Ok this was my favorite one, but it also doesn't work since AttachConsole(...) blocks, similar to 3.
Someone have any ideas on what to try next? My c/c++/winapi skills are intermediate at best, so it is very possible I overlooked something. Ok an obvious one would be to throw the whole thing overboard and just poll the output buffer for changes, but I would consider that a last resort option. I'm assuming that MS was smart enough to make sure either In Context or Out of Context events would actually be usable and as such I must be missing something.
A WPF application. Debugging. Stop on break point.
After few seconds Visual Studio (2008) spontaneously aborts the application execution.
It is never mind what I do after stop on break point: even if I do nothing.
With very simple test WPF application everything is OK with debugging.
Any ideas?
When an application aborts that quickly without warning it's usually the result of a stack overflow in the process. This makes it difficult (if even possible) to do tear downs operations like bringing up Dr Watson.
One thing I didn't quite understand is if the application or VS is suddenly stopping.
If it's the application there is likely a StackOverflow occurring in such a way that VS can't trap the exception. Try disabling Just My Code debugging, turn off implicit function evaluation and break on first chance exceptions. That should hopefully help reveal the problem.
The problem was solved.
To solve the problem the debug settings must be changed:debug->exceptions: and check on exceptions boxes (I checked on C++ and CLR).
(source: ggpht.com)
Result: I can see exception that I didn't see before and I can normally debug my application.
The reason was incorrect vcshost.config file name (my fault).