|
Fareed Rizkalla wrote: I thought I read an article, but I'm unable to find it again.
RFC2616[^]
|
|
|
|
|
Fareed Rizkalla wrote: I want to parse the HTTP response sent back from the server.
Ok, so what exactly is the problem?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I am currently analyzing some nasty application crashes. Fortunately I can already reproduce these crashes within a few minutes and I get a dump that is supposed to be useful (note that it is a crash dump from an optimized release version). Let me outline the code where the application crashes (pseudo code):
int myNumberOfElements = myCalculation();
[...].
if(myNumberOfElements < 1 || myNumberOfElements > 100000)
{
return;
}
MyArray* pArray = AllocArray(myNumberOfElements);
AllocArray unfortunately belongs to a 3rd party library, but it basically calls malloc. It then crashes as it does not check accordingly if malloc succeeded. However, the root cause of this problem seems to be the large number of elements (which is definitely not the result of my calculation). Further there is only one assignment to myNumberOfElements and if used as parameter 'call by value' is used.
What do you guys think, is the dump file corrupt? Is there a way that the stack gets corrupted, causing this problem?
|
|
|
|
|
How are you analysing the dump file? Can show me a stack track for a start?
Steve
|
|
|
|
|
As posted in my other reply I use Visual Studio for analyzing the dumps. I would like to avoid posting a call stack as I think that my superiors would not be very happy finding parts of our code on codeproject (even if they are small and not useful to anyone).
|
|
|
|
|
A call stack is unlikely to give away trade secrets.
Steve
|
|
|
|
|
So somewhere between assigning myNumberOfElements a value and calling AllocArray(), myNumberOfElements is changing? Have you stepped through those statements while watching myNumberOfElements?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I cannot step through this particular case, because the code runs perfect many thousand times before it fails a single time 
|
|
|
|
|
How about using a conditional breakpoint?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
So the test for myNumberOfElements being out of range happens right before the call to AllocArray? That's not a lot of time for it to be getting corrupted by your code before the call. It seems definitely possible the value seen in dump file is corrupt as a result of the crash rather than the cause of the crash. But...
- As already asked, how are you looking at the dump file?
- Does the debug version of the program work OK?
- Have you tried turning off or lowering optimization? Try this first if you haven't!
- Are you sure that AllocArray is capable of handling 100000 elements?
Some things to maybe try:
- Can you modify your program to output myNumberOfElements right before the call?
- Create a global variable to hold the result of myCalculation and pass that in to AllocArray. If this is memory/stack corruption happening in your function, it's unlikely it would step on the global var in the same way.
- Hardcode the value being passed in to AllocArray. If you can find out and use the real result of myCalculation, even better. Does this still crash? Either way, this will tell you a lot about what's going on.
|
|
|
|
|
Yes, the test is right before the AllocArray-call.
I use Visual Studio for analyzing the dump. I have done this a thousand times before but in my experience it rather displayed no value instead of a wrong value.
I will try to reproduce the problem on a Debug (or at least less optimized) version. The AllocArray basically can handle any size as long as enough memory is available (100000 should be no problem, 10^9 is definitely a problem).
I will also try your other suggestions, if applicable. The code runs within the rendering of a openGL frame and gets executed many thousand times before a crash may occur...
Thank you.
|
|
|
|
|
Ahh, the fact that it runs thousands of times OK before crashing changes things a bit. I don't suppose it's so convenient as to always crash at the exact same point/iteration?
If you really think the local variable is getting suddenly changed, and that's causing the problem, you should try to prove that or disprove it:
- Definitely try moving it to a global.
- Do the other local variables in the function all look OK when you look at the in the dump? Is myNumberOfElements the last variable declared in the function? It would be odd if only myNumberOfElements was getting corrupted and nothing else around it (unless AllocArray is taking a reference to it and corrupting it there). You could try placing "guard" variables or the same size, with known values, declared right before and after myNumberOfElements and seeing if those get alterred in any way during the crash.
- store the result of myCalculation in two or three separate variables (in different locations - a global, a heap var, and the stack) that you can compare in the dump. No way they can all get corrupted in the same way without everything else in the program also doing so.
- log the value to a file when received from myCalculation and again immediately before the AllocArray call.
One or more of thse things should be sufficient to prove or disprove your theory and give you enough tot go on for the next step
|
|
|
|
|
Thank you for your hints, they helped me to find out that the actual problem seems to be a memory leak. So the actual reason was not the wrong parameter for the malloc (which also caused the memory to be exhausted), but the malloc seems to have corrupted the stack if there was no more memory available, and hence the value of the variable was no longer accurate. I will now try to verify this thesis, the fix itself will be obvious.
|
|
|
|
|
|
Hi,
please allow me to post a specific question here.
We have an application that consists of the exe and a service. This code is running on Win2k currently.
We have the job to migrate this code to Win7. The software is currently running as an adminsitrator (app and service). They should run on the account of a local(restricted) user.
The problem: the software uses mailslots for the communication between the app and the service. This works when both parts are started as administrator on Win7. It will not work when they both are started as a local user and not when the app is started on the account of a local user and the service as administrator.
In the error-case the function CreateFile() returns an INVALID_HANDLE_VALUE and GetLastError() returns a value of 5 (== ERROR_ACCESS_DENIED).
Whats wrong in our code?
Thanks.
August
PS: a link will be sufficient.
here is our code for creating the mailslot:
HANDLE mailSlotHandle =
CreateFile( GetClientMailslotName(),
GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_WRITE_THROUGH ,
NULL);
if( mailSlotHandle == INVALID_HANDLE_VALUE )
{
DWORD errorNumber = GetLastError();
and so on.
modified on Wednesday, April 21, 2010 5:32 AM
|
|
|
|
|
Try setting LP_SECURITY_ATTRIBUTES on your mailslot creation.
|
|
|
|
|
Hello Michel,
thanks for your tip.
Unfortunately we tried this. but we always got a return-code of 1307 (=ERROR_INVALID_OWNER). And we tried different security strings.
August
|
|
|
|
|
Bummer.
It may be me, but do you have a good reason for specifying FILE_SHARE_WRITE? FILE_SHARE_READ should be sufficient.
Also, could we have a look at the code that creates the mailslot? (The CreateMailSlot call)
|
|
|
|
|
Hello Michel,
the problem is solved. After your 1st message we looked at our code again and tried it again. And now it works.
Thanks for your tips. This helped us (indirectly, but it helped).
August
|
|
|
|
|
August,
I'm having the same issue on one of my projects.
Exactly how did you solve it? What code did you use for the CreateMailSlot call?
Thanks,
Brett
|
|
|
|
|
Hello Brett,
sorry for beeing late.
The problem was solved about a year ago. I do not work for this customer any more because the work is done. And I do not have access to the code any more.
What did I do? Hmmmmm
If I remember right then I 'opened up' the rights in the call, which means I allowed everyone everything on this mailslot. Please look at the description of the function call.
With this new string everything worked. And then I added carefully one restriction after the other and finally we had the restrictions as desired.
So the way was: do not experiment with possible restrictions, simnply allow everything (and for everyone). Test this. Then carefully add one restriction and test this. And so on.
Sorry, I could post the exact code that worked.
August
|
|
|
|
|
Hello Brett,
after some playing with Google I found this link:
http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx
If you look at my code-snippet you will find a NULL as the 4th parameter.
If I remember right then I added a value for LPSECURITY_ATTRIBUTES (the 4th parameter).
I filled the mebers of this sctructures (but I do not know the details now). The only thing I remeber is that I allowed everything (as a start).
hope this helps.
August
|
|
|
|
|
Hello Sirs,
I have compile my sample program in mingw with msys , i dont know how to create configure file and make file
in my system i have installed ms visual studio but i need to work with under mingw with msys
for Example,
#include <stdio.h>
int main()
{
printf ("Testing \n");
return 0;
}
Thanks
 Failure is Success If we learn from it!!
modified on Tuesday, April 20, 2010 7:59 AM
|
|
|
|
|
Well, for such a simple test program make and configure files are overkill, just issue
gcc -o <output-file-name> <source-file-name>
at shell's prompt
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi,
I am new to MFC programming.
I asked to write a Dialog based application, in which the application should monitor whether the print dialog is opened.
When the print dialog is opened and the 'Print' button is clicked, my application has to make an alert, say a message beep.
I am not able to find any help.
Please help me.
Thanks
Gokul
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
Now with 26% more Twitter