I am trying to make a socket on windows to connect to a server.
I am using the code from msdn's website, the winsock client code.
(Link: msdn.microsoft.com/en-us/library/windows/desktop/ms737591(v=vs.100).aspx )
In any case, when I try debugging said code I get the error message:
Unhandled exception at 0x58a714cf (msvcr100d.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000032.
It asks me if I want to break or continue, if I continue the same error message simply keeps popping up. If I press break it takes me to line 1643 in the file output.c .
Simply put, I have no idea about what to do to make it work, and I'd appreciate any help given.
EDIT:
A reply to all comments given thus far:
The surrounding relevant code in output.c is:
if (flags & (FL_LONG|FL_WIDECHAR)) {
if (text.wz == NULL) /* NULL passed, use special string */
text.wz = __wnullstring;
bufferiswide = 1;
pwch = text.wz;
while ( i-- && *pwch )
++pwch;
textlen = (int)(pwch - text.wz);
/* textlen now contains length in wide chars */
} else {
if (text.sz == NULL) /* NULL passed, use special string */
text.sz = __nullstring;
p = text.sz;
while (i-- && *p) //THIS IS WHERE IT BREAKS
++p;
textlen = (int)(p - text.sz); /* length of the string */
}
This is not code that I have written but innate code that already exists.
EDIT NR 2:
This is a printscreen displaying my call stack.
I do not have 10 reputation so I cannot show the image, so here is a link to the image:
http://tinypic.com/r/5n6ww9/5
On it you can see my call stack
The file output.c has the code that handles the printf family of functions.
The fact that you have an error here is probably due to a malformed printf function call in your code. Maybe you have specified an invalid print format or have not provided enough arguments.
When your program crashes, click Break and look at the call stack in the debugging windows to see where - in your code - the function is called, and with what arguments.
I suspect you are trying to print a NULL string or something. When you have found the printf call (if that's what it is), edit your question to show that section of source code and/or use the debugger to examine the variables used a arguments to the function and make sure they are all correct.
Without seeing the code that you've written, at the location of the crash, it's not possible to give a more precise answer.
Or you may insert a null string to CString.format like below:
CString str;
str.format("%s"); //A null string
where it should be
str.format("%s",mes);
where mes is char mes[20] for example
or any other variable
So the point is there may be some mistake in CString.format or Printf
Good Luck.
Related
I am fairly new to using gdb debugger and so coming across the code being displayed when I ran gdb left me having no use for the debugger. I am unfamiliar with the code being displayed but a did a little research and I assume I accidentally opened up a "thread"? It's hard to explain something I do not understand but I will link a picture explaining what I am talking about. Basically I want to revert back to the "basic" display of my actual code and not this: displayed by the debugger
Your program called one of scanf family of functions, with a NULL stream.
Usually this happens when you don't check for errors. For example:
FILE *fp = fopen("/file/which/does/not/exist", "r");
char ch;
fscanf(fp, "%c", &ch); /* BUG: should check fp!=NULL first. */
You should always check return value from any function that may fail.
You can see which code called into the fscanf with GDB where command.
I'm debugging a very old application (Visual C++ 6) due to a crash. I have isolated the crash into a while loop. This app reads a bunch of strings from a database and outputs them into a file for processing.
This while loop appears to be looping through all strings retrieved from the DB and wrapping them in a delimiter/end character. However, the while loop will randomly crash.
I have a particular set of data containing around 2000 strings, and at some point, during processing, the loop will crash (or give a debug assertion error in debug mode).
What's strange is that this loop does not stop in the same location each time (bad string was my first thought), nor is this a common occurrence. This app has processed hundreds of thousands of rows over the years, and yet it chokes on this particular data set somewhat randomly.
I added some logging code initially (which I've stripped out, and it appears that the crash is occurring on the actual execution/evaluation of the WHILE line.
Is there anything, in particular, I should look for? I was thinking perhaps this is an index out of bounds error, but I would think it would happen consistently in the same spot with the same data set if that were the case. Does anyone see anything with this code I should double-check, or can offer any advice on how to better troubleshoot this?
//Definitions
CStringList m_stlMessageList;
CStringList m_stlMessageIDList;
//Populating list
rec.Open(CRecordset::forwardOnly, strSQL);
while (!rec.IsEOF())
{
rec.GetFieldValue("string_id", strMessageID);
strMessageID.TrimRight();
rec.GetFieldValue("string_text", strMessage);
strMessage.TrimRight();
rec.GetFieldValue("string_destination", strDestination);
strDestination.TrimRight();
rec.GetFieldValue("string_ip", strIP);
strIP.TrimRight();
//Add to the Lists...
m_stlMessageIDList.AddTail(strMessageID);
m_stlMessageList.AddTail(strMessage);
rec.MoveNext();
}
//Code thats crashing.
CString strSegment, strTemp, strTmp;
BOOL bFirst = TRUE;
POSITION POS = m_stlMessageList.GetHeadPosition();
while (POS)
{
strSegment = m_stlMessageList.GetNext(POS);
strTemp = strSegment.Left(4);
strSegment.Format(strSegment + "%c", 13);
if (POS)
{
strTmp = m_stlMessageList.GetPrev(POS);
m_stlMessageList.SetAt(POS, strSegment);
strTmp = m_stlMessageList.GetNext(POS);
}
else
{
m_stlMessageList.RemoveTail();
m_stlMessageList.AddTail(strSegment);
}
}
So far my program is working pretty well. Unfortunately when I press ctrl + alt + del it throws an error. Now I have read this question:
E_ACCESSDENED when using ctrl alt del
In which it is mentioned that the computer switches to a different screen (in which you don't have any writing permissions). It's just that I have no idea how to trace if I have writing permission in the current screen.
My code looks like:
void D3D::StartFrame() {
HRESULT result;
result = pDevice->Clear( 0,NULL,D3DCLEAR_TARGET,D3DCOLOR_XRGB(FRAME_BG_R,FRAME_BG_G,FRAME_BG_B),0.0f,0 );
assert( !FAILED( result ) );
result = pBackBuffer->LockRect( &backRect,NULL,NULL );
assert( !FAILED( result ) );
}
void D3D::EndFrame() {
HRESULT result;
result = pBackBuffer->UnlockRect();
assert( !FAILED( result ) );
result = pDevice->Present( NULL,NULL,NULL,NULL );
assert( !FAILED( result ) );
}
Currently I am running the "StartFrame()" function each frame followed by some actions that should be done during the frame. At the end it will call the "EndFrame()" function that will unlock the drawing rectangle.
Now the error that occurs comes from the last assert (the StartFrame() assert doesn't fail?). Should I change these functions to return booleans telling the program if it should continue or not? Should I make it stop the entire program (which feels a bit odd)? Perhaps I am handling the rectangle locking the wrong way (should it work with asserts)?
Error: Assertion failed! - !FAILED(result)
Any help/advice would be appriciated !
First of all, whenever you get an error, before doing somethig, and before even thinking about what happened, you must check what exactly error message said.
In case of DirectX 9, you must not only check if HRESULT variable FAILED but get detailed info from it. You can get details from it using DXGetErrorString() and/or DXGetErrorDescription() functions (dxerr.h + dxerr.lib). For example, you can handle you errors by writing a small helper function, that accepts HRESULT and shows MessageBox() with details if it FAILED. Also, there is a good DXTrace() macro as a quick solution. Or, as a quickest lazy solution, you can just set a breakpoint right after function fail, and inspect value of HRESULT variable in debug watcher.
In your case, because we don't have error description in your post, we can only guess what happened (that's what guys from SO doesn't like the most). And I suspect here Device Lost state. That state sometimes happens when your app looses focus (Alt+tab, Ctrl+Alt+Del, etc.). To prevent crashes you must handle such exceptional states as described on MSDN or this short tutorial.
Of course, my guess can be wrong here, because I dont't know, what exactly happened. Please add proper error handling and provide additional information to get concrete help.
Happy coding!
I'm trying to read the install path for an application, and I'm baffled at the behaviour I'm getting. First, here's the code that didn't work (formatted it a little so it doesn't take up a huge line):
LONG status = RegQueryValueEx(
hkRegistry,
"InstallPath",
0,
®Type, (LPBYTE)installPath,
®Size );
if (status == ERROR_SUCCESS) {
// Handle success.
}
I realized that it was failing on the call to RegQueryValueEx, so I decided to probe the return value by throwing it within an exception by adding:
else {
throw Exception( status );
}
But then... the code started to work and the call to RegQueryValueEx succeeded. I've been able to repeat this behaviour as long as I throw something within the else. If I comment out the body of the else, the error returns.
Edit: Okay, I tried calling MessageBox instead of an exception and I get the same behaviour. If I comment it out, it stops working again.
Is there a rational explanation for this?
It's possible that the buffer for installPath is too small compared to the value contained in regSize (which must be initialized to the size of the buffer).
If installPath is a stack-allocated value I suspect that it is overflown, causing the value of status to get overwritten.
I am now trying to use this Application Verifier debugging tool, but i am stuck, first of all: it breaks the program at a line that is simple variable set line (s = 1; for example)
Secondly, now when i run this program under debugger, my program seems to have changed its behaviour: i am drawing image, and now one of the colors has changed o_O, all those parts of the image that i dont draw on, has changed the color to #CDCDCD when it should be #000000, and i already set the default color to zero, still it becomes to #CDCDCD.
How do i make any sense to this?
Here is the output AV gave me:
VERIFIER STOP 00000002: pid 0x8C0: Access violation exception.
14873000 : Invalid address causing the exception
004E422C : Code address executing the invalid access
0012EB08 : Exception record
0012EB24 : Context record
AVRF: Noncontinuable verifier stop 00000002 encountered. Terminating process ...
The program '[2240] test.exe: Native' has exited with code -1073741823 (0xc0000001).
Typically when breakpoints are hit like this (via AV or an unhandled exception, etc.) inside a debugger, there is a green arrow pointing to a line of code. That arrow is pointing to the next statement to execute when the thread returns from the current function. Perhaps this green arrow is pointing to the line where you wrote "s = 1", but really the offending code is the line above it. Now I can't see your code so I can't exactly know for sure and I don't have enough rep to post a comment - but this is something that is easy to check the next time the breakpoint is hit.
I am willing to bet that s is NOT a "simple" variable. I'm much more likely to believe it's something like this:
class Foo;
int s;
void Bar() {
s = 1;
}
};
Sure, it looks like a simple s=1 statement, but in reality it is a this->s=1 statement. And if this is an invalid pointer, this->s isn't a proper variable either.