|
Serendipitous - was just perusing DiLascia's latest, where he mentions FindExecutable.
|
|
|
|
|
Hi any 1 out there
I have a problem and it is so interesting to me...
Ok here it comes
IDE: VC++ 5.0
Project: A simple console application that compresses files using LZW algorithm...(It has to be Win32)
Problem(s)
Project Setting: Win32 Debug >> Everyhing is OK.App. is slow but fine.
Project Setting: Win32 Reelase Optimization : Default >> Hmm...Memory Access Violation error!!! And app. is down...
Project Setting: Win32 Reelase Optimization :Maximize Speed >> No memory access error but the compressed file is ooo 22 bytes.It doesn't matter whether src file is 2M or 2K it is still 22 bytes ??
Thanx....
|
|
|
|
|
Hi any 1 out there
I have a problem and it is so interesting to me...
Ok here it comes
IDE: VC++ 5.0
Project: A simple console application that compresses files using LZW algorithm...(It has to be Win32)
Problem(s)
Project Setting: Win32 Debug >> Everyhing is OK.App. is slow but fine.
Project Setting: Win32 Reelase Optimization : Default >> Hmm...Memory Access Violation error!!! And app. is down...
Project Setting: Win32 Reelase Optimization :Maximize Speed >> No memory access error but the compressed file is ooo 22 bytes.It doesn't matter whether src file is 2M or 2K it is still 22 bytes ??
Thanx....
|
|
|
|
|
Well, there are many assumptions an optimizer must make. And while there are indeed bugs in the optimizer, chances are you are depending on some side effect in your code that gets optimized away.
What you need to do is isolate your code down to the smallest possible reproduceable case and then post it, perhaps we can help.
|
|
|
|
|
Hello everybody,
I am writing an circular queue buffer utility .when u are using createFileMapping Apis we specify the size of memory .. I have specified it to 30MB and I am writing and reading from the file and deleting it from it . these operations are done in FIFO .Now after couple of deletes and Number of write operations assume that it reaches the end of the file .. I need to go to top of the file and fill in the gaps . Now my question how will i know whether I have reached the end of the file ...
thanks in advance
|
|
|
|
|
are u writing sequentially to the file (ie, like playing a sound file from a circular buffer) or are u writing randomly?
sequentially is easier as you can just check how many bytes u have written and when you hit 30Mb zero the index or reset the pointers
random writing requires that you keep an upper and lower bound pointer and check for when u are about the exceed the upper limit ... then switch it to the lower limit
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
I've come across an oddity recently where an app that links MFC dynamically, along with some third party DLL's, happens to load both the debug version and the release version of MSVCRT. According to Dependacy Walker, MSVCRTD.DLL is loaded on behalf of my app and MSVCRT.DLL is also loaded on behalf of a third party DLL. I'm asking the question because I'm trying to track down a bug that only happens with the debug version of the app, but the release version does not exhibit the bug at all. So far this is the only difference between the two releases that I can dig up.
Anyone with some experience in mxing debug with release?
Thanks.
Chris Meech
|
|
|
|
|
its wierd to see how an app can load a debug version of the dll without either being a debug build or explicitly loading the debug dll ... are the 3rd party dll's not causing the debug dll to load?
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Sorry if I was unclear, but it is Dependancy Walker that is showing me that for the DEBUG version of my app that both the DEBUG and RELEASE versions of the MSVCRT DLL will be loaded. I'm not sure whether that actually happens in practice, nor if it is even a problem! But I was just wondering because at the moment it is the only difference between the debug and release version of my app that I can figure out.
Thanks for the reply and I like your sig 
Chris Meech
|
|
|
|
|
Yes, don't do it.
Mixing the two, you end up with two different heap managers. MFC uses all kinds of tricks to get around the module heap limitations, and you've now created two different kinds of memory. What happens when your debug code tries to delete memory allocated by the release manager? You might as well try to guess how Buddy Hacket will look in a singularity with better success 
Contact your library vendor and request a debug version of their DLL, or else enable debugging information in the release mode and debug that way. You will be chasing your tail for no reason otherwise.
|
|
|
|
|
Thanks Eric. I read into your words that I am likely creating an environment where all kinds of odd and unpredictable behaviour will occur. I get enough of that at home with my teenage kids, so I don't need anymore here at work 
Chris
|
|
|
|
|
Hi Chris,
If you look under the hood, you'll see that for Release MFC/MSVCRT that
new calls malloc() and delete calls free().
For Debug MFC and MSVCRT all calls to malloc() and free() actually go to malloc_dbg()
and free_dbg(). Since malloc and malloc_dbg() are exported functions they are only accessible via the jump table in the IAT of your DLL that is linked to MFC42uD.DLL (or MFC42D.DLL if you are MBCS). The import library will indicate that it wants MFC42uD.DLL or MFC42.DLL and will not resolve to the incorrect DLL (ie if it wants the release on it won't link against the debug one).
So that being the case it is pretty hard to call the release malloc() if you know you linked against the debug malloc(). If you want to try, put a breakpoint on a call to
new/malloc or free/delete and drop into assembly level and walk the calls, you can
tell very quickly if you ended up in the release or debug dll (for a start the source code only comes up in the debug dll as there is no debug info in the release dll to main to the release CRT source code that MFC ship.).
You should also note that many big name tools, such as Purify, will report that your program is using both MSVCRTD.DLL and MSVCRT.DLL at the same time. Why do they do this?
Your program is debug, so that explains MSVCRTD.DLL. Their program (the one that has
been injected into your program to inspect it) is almost certainly release code(*),
which explains MSVCRT.DLL. So why would they do that? The reason is that:-
a) Microsoft forbids the redistribution of DEBUG dlls.
b) The performance gains of using the release DLLs and the knowledge that an ASSERT
(that may just be a warning, not a genuine problem) can't come up.
As long as their program never mixes its calls up and always calls its MSVCRT.DLL
then it will be OK. So there are occasions when it is OK, but as other posters here
have noted, usually it is NOT ok.
It sounds like the 3rd party dll may be incorrectly assuming any memory that is passed to it to manage is always 'release mode' (for want of a better term) memory. In that case you are out of luck.
The memory management for DEBUG is pretty straightforward. The source code is in the MFC directory and implements its own linked list manager with a lot of overhead to
allow you to track it. It grabs larger chunks using HeapAlloc on a private heap.
The Release memory management consists of a small block heap, implemented in a way
that will not map in any way to the DEBUG memory management. For larger blocks
(greater than the value returned by sbh_get_threshold(), typically 0x03f8) the release
manager goes to HeapAlloc() in a private heap. Consult sbheap.c and winheap.c for
more details.
Hope this is some use. Any chance of naming the vendor/dll?
Stephen Kellett
|
|
|
|
|
I disagree. It's quite easy to call the wrong malloc or free. For instance, if you are in debug, and you link to a release DLL. If that DLL allocates memory and returns it to your debug application, and your debug application frees that memory itself, you get major problems.
Another problem, especially with MFC, is that the size of objects can change between debug and release, thus if you allocate an object in release, but use it debug, it's going to assume a different memory layout. You might be using something like Stingray's ObjectiveToolkit, that implements it's own MFC derived classes in a DLL, for instance. In debug, the objects include dump information and additional functions. This can cause page faults or other nasty problems.
|
|
|
|
|
Well we are both agreed on the fact that you shouldn't mix and
match the memory. The extra functions and data members you
refer to will also cause data offsets and possibly the virtual
function table to be at a different location than expected.
Defintely bad news.
If you intentionally link a release DLL to a debug DLL of course
the user will get problems if they mix and match the objects and
code.
The reason for my post was to point out that if you link against the DEBUG DLL you won't accidentally be calling the functions in
the release DLL, even if that release DLL is in the process. You have to go out of your way to link the wrong DLL, and in that case, well, you need to change your link options.
I have a project at present which intentionally loads the Release MSVCRT.DLL into a running program, be that program debug or release. It doesn't crash the running program because the only
code calling the release MSVCRT DLL is the code I injected into
the program. In the case that the running program is Release then
we both share the MSVCRT.DLL heap, which is allowed for in the design of MSVCRT.DLL as long as you are using the DLL and not linking statically.
Stephen Kellett
|
|
|
|
|
I have a large custom database that I'd like to search for keywords. Anyone know of anything I could use that is ultra-fast?
|
|
|
|
|
you need to scan the files and build an index(s) of the keywords ... like a web search engine ... then finding keywords is a snap
suggest you build a file of the keywords you want to define or a file of non-keywords you want to ignore and then use that to build the index of the stuff in the db
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
what is the difference betweeen delete
and delete []
|
|
|
|
|
If you allocate an array with new, you use delete [] when you free the memory.
--Mike--
http://home.inreach.com/mdunn/
This must be Thursday. I never could get the hang of Thursdays...
|
|
|
|
|
But delete and delete[] both seem to generate the same assembly output, so is there really a difference ? 
|
|
|
|
|
They may look the same, but they're not.
For instance, take this simple application:
#include "stdafx.h"
#include <iostream>
using namespace std;
class a
{
public:
a(){};
~a(){cout << "a::~a()\n";};
};
int main(int argc, char* argv[])
{
a *pa = new a[10];
delete [] pa;
cout << "------" << endl;
pa = new a[10];
delete pa;
return 0;
}
If your theory were correct, it would output 10 a::~a()'s followed by dashes and 10 more. Instead, this is the output:
a::~a()
a::~a()
a::~a()
a::~a()
a::~a()
a::~a()
a::~a()
a::~a()
a::~a()
a::~a()
------
a::~a()
As you can see, the destructor gets called 10 times when using delete [] and only once when using delete.
|
|
|
|
|
Delete[] is necessary for deletion of objects. I mean instances of classes.
Objects in array should be garanteed to destruct itself and free resource.
Delete[] calls all of destructor of objects in array and call of destructor
calls destructor of base class's destructor.
So delete[] gaurantees destruction of all object in array .
For primitive types like int, long, char etc..
You don't have use delete[] for freeing resource.
Delete is enough. But this is only the theory..
In practice,I recommend to use delete[] whenever you're freeing resource in array.
Cause it makes code more clear and readable.
It looks to clear to other developers who are seeing your code or youself in future.
Regards,
Ryan
|
|
|
|
|
Okay, this is kinda weird ...
I'm going to simplify it (but still show problem)
=================================================
char *ModuleList[10];
char *strInput;
char buffer[80] = {80};
bool bDone = false;
int iLoop = 0;
while (!bDone)
{
strInput = _cgets(buffer);
if (strcmp(strInput, "exit") == 0) { bDone = true; }
else
{
ModuleList[iLoop] = strInput;
iLoop++;
}
}
Now yeah iLoop will go higher than 9 that will cause an error .. but the problem is that the ModuleList array does this:
Input: test
ModuleList[0] == test;
ModuleList[1] == "";
..
Input: again
ModuleList[0] == "again";
ModuleList[1] == "again";
ModuleList[2] == ""
..
See what I mean? why does it change the previous values in the array instead of leaving them alone? The array seems to get screwed up when the strInput = _cgets(buffer); line gets called.
Any help here is much appreciated .. probably some stupid mistake, but I'm a little lost here
Thanks, Travis
|
|
|
|
|
strInput is always has the same value (buffer+2). so, you are setting the same pointer value into each ModuleList element.
-c
|
|
|
|
|
also the line char buffer[80] = {80}; should read char buffer[82] = {80};
just a small point
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Where you have:
char *ModuleList[10];
it is NOT an array of strings!!
It is actuall an array of string pointers.
So where you go:
ModuleList[iLoop] = strInput;
what you actually doing is setting all of the string pointers in the array to
point to the same string. The same string that you change every time around
the loop.
So if you really want to store the strings try:
char ModuleList[10][80];
and
(void)strncpy(ModuleList[iLoop], strInput, 80-1);
ModuleList[iLoop][80] = NULL; // to guarentee NULL termination.
// in stead of ModuleList[iLoop] = strInput;
Hope that helps.
Jules
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
