I have an application developed using visual studio 2010 under C.
When I run my application,everything appears fine until it arrives to :
while ((row = mysql_fetch_row(result))) {
t[k] = atof(row[num_fields - 1]);
k++;
}
The select query doesn't have any problem. An exception message appears:
An unhandled win32 exception has occurred in ...
I read some articles which tell that this is a problem of deallocating the memory.
I have added:
mysql_free_result(result);
free(t);
But nothing changed. Please help.
Thank you.
First of all, better you can do is running with a debugger.
Once that was said, I can see some things which can produce an exception:
What happens if num_fields==0? You'd get an exception in row array
Check that row is correctly set by mysql_fetch_row before executing atof. For example, I would separate the same code in several rows with some checks.
Related
error message: form1.execValidate is not a function. but this has worked fine for years!
Last week the client (large bank) rolled out a new version of Adobe Reader XI 11.0.21. Perhaps registry keys were changed as well - don't know.
So now all livecycle forms are crashing. Below is one error message seen on the console followed by the crash.
The code being used has been executed 10K+ times over ~5 years, over roughly 5 different forms over many versions.
form1.FirstPage.sfBody.sfSectionB.sfEnder.SendReferral::click - (JavaScript, client)
var res = form1.execValidate(); // does form validation, if all good returns true
if (res) {
cLookFeel.fMailTo(event.target);
}
(Code is attached to the click method on a button, cLookFeel is the name of my code block.)
And strangely - Reader then seems to (often) crash. Go figure.
followed by a crash:
Okay, turns out it's a known bug by Adobe on 11.0.21. They've issued a fix.
https://helpx.adobe.com/acrobat/release-note/acrobat-dc-august-11-2017.html
This is Windows Forms application.
As in title, I can't debug Task in Visual Studio 2015. If I will check breakpoint at line var a = costam(); it will be hit, but if then I will press step into, or continue, execution will not be continued. This works fine in Console Application. For now i checked, that error appears when I'am trying to run my own method in Task, or if I'am invoking something.
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
Task.Run(() =>
{
var a = costam();
});
}
string costam()
{
return "s";
}
}
I would suggest changing the settings to break on any exception in the debug menu, not only uncaught ones. This option is called breaking when the exception is "thrown". Unfortunately the 2015 exceptions menu I'm not familiar with so I can't help you out with that.
There are certain exceptions that are caught and suppressed behind the scenes, especially with WinForms--constructors / load events are particularly shielded. It's likely that it doesn't like spawning a new thread in the UI thread which is why it's throwing an exception in your WinForms application but not the console application. This also explains why "stepping in" "doesn't work"--it steps in but the exception means the next breakpoint isn't hit.
Update 1 to VS2015 seems to solve this issue.
Somewhere in my code, I have this line:
return _store.OpenFile(path, fileMode);
With fileMode being sometimes FileMode.Create and sometimes FileMode.Open.
Everything works well, I always get a valid stream and if necessary, the file is correctly created.
But, I've just discovered in my VS output that I have the following message every time I call the method where the above line is:
A first chance exception of type 'System.IO.FileNotFoundException'
occurred in mscorlib.dll
I get this error when the file is created and I also get this error when the file is overwritten (and obviously exists).
I'm just curious about these errors since everything works perfectly.
Thanks,
EDIT: Same thing with new IsolatedStorageFileStream(...). Everything works fine but I still get the "first chance exception" message.
var isf = IsolatedStorageFile.GetUserStoreForApplication();
IsolatedStorageFileStream isfs;
if (!isf.FileExists(_filename))
isfs = new IsolatedStorageFileStream(_filename, System.IO.FileMode.Create, isf);
else
isfs = new IsolatedStorageFileStream(_filename, System.IO.FileMode.Open, isf);
var writer = XmlWriter.Create(isfs);
xml.Save(writer);
writer.Close();
isfs.Close();
isfs.Dispose();
isf.Dispose();
Found the answer.
It's just how VS debugger works: for every exception caught by a {{catch}} block, a "first chance exception" message appears in the VS output.
So here, we can guess that, internally, the {{OpenFile}} method uses a try/catch block to check if the file exists.
I have a SQL Sever 2008 R2/64-bit database server for which I'm writing some fairly basic scripting utilities with the Sql Server Management Objects (SMO). My project is a 32-bit VS2010 executable written in C#.
Most of the effort has been fairly simple and successful. The only problem I'm having is in the firing of my custom event handler that should be called in response to a Scripting Error.
The Scripter object exposes a ScriptingError event, which I have attempted to leverage thusly:
//srv contains a valid server name
Scripter scrp = new Scripter(srv);
//scrp_ScriptingError is my handler
scrp.ScriptingError += new ScriptingErrorEventHandler(scrp_ScriptingError);
My handler is declared thusly:
static void scrp_ScriptingError(object sender, ScriptingErrorEventArgs e)
{
// my handler goes here, just printing e.Current.Urn to the console
// This is merely representative, have had other things here, but
// the handler never fires
Console.WriteLine(e.Current.Value);
}
All this compiles cleanly.
My code is invoked via simple scrp.Script(urns); where urns is just an array of the database objects being scripted out. Nothing fancy:
try
{
sc = scripter.Script(urns);
}
catch (Exception e)
{
WriteLog(String.Format("Failure during scripting: {0}: Inner exception message (if any): {1}",e.Message,((e.InnerException==null)?"[None]":e.InnerException.Message)));
}
using (System.IO.StreamWriter file = new System.IO.StreamWriter(fileName,true))
{
foreach(String currentLine in sc)
{
file.WriteLine(currentLine);
file.WriteLine("GO");
}
}
The problem is that, no matter what I've tried so far, when errors occur during scripting, my ScriptingError handler never fires.
Even in debug mode within VS2010, when I set a breakpoint within the handler, and fire my scripting code, and know an error will occur, only an exception will be thrown, but the breakpoint in my ScriptingError handler never trips.
I'm in trees-for-forest mode now, not sure what I've done wrong. Am I expecting the wrong things for the ScriptingError handler?
I have searched the MSDN docs on the SMO objects and found virtually nothing on ScriptingError handlers other than the basic API calls themselves, and precious few examples on the Internet. It seems incredibly simple and straightforward to me - just assigning an event handler to the event - but there's some battery-not-included notice I've failed to note.
Pointers to my error are greatly appreciated, with a polite request for minimal brickbats if the error is exceptionally stupid on my part :)
I am not at a pc right know, but I think you should try to set the ContinueScriptingOnError option. Otherwise there would be no reason for SMO to invoke the event, but rather through an exception instead.
I'm using a C program with sqlite3.
Some times insert works.But sometime ,its not working.
assert(retval == SQLITE3_OK)
gives error. while debugging I found retval value of sqlite3_step() is error code = 5
which refers to Database file is busy
Even closing with sqlite3_close() return error code 5.
Any thoughts on how to close the database connection ,even when it's busy?
You could be in the middle of a transaction. Try checking http://www.sqlite.org/c3ref/get_autocommit.html for explanations on how sqlite3_get_autocommit() works. It should return a zero if it is not in auto-commit, meaning there is an open transaction.
Or if you suspect your database might still be working on something, you can use sqlite3_busy_timeout() to set a timer. http://www.sqlite.org/c3ref/busy_timeout.html