|
Before I start building my logger class, I wouldn't mind a having a few ideas on how to create it. This is a basic outline of what I need: The file needs to be divided into sections ( OS details, Error's and program flow ). The latter two sections would need to be resizable, but the file must have a max size limit. ( I don't want end users e-mailing me 10 mb log files ). The file doesn't need to be readable, I can create a seperate utility for this.
Now I'm not very sure how to procede. I'm thinking a memory mapped file with a linked list. But a linked list is basically a pointer to a pointer which isn't very practical in a mapped file. Another way I could do it is use some sort of hash table. Divide the whole file into chunks and each entered record has it's offset stored in a known place.
I'm open to ideas on this one.
|
|
|
|
|
How about two linked lists of file offsets - one for error entries, one for program flow entries.
Store a offset-first and offset-current for each list in a header struct at the beginning of (or
a known place) in the file.
To add a new entry:
1) get the offset-current
2) append the entry to the end of the file (noting it's offset)
3) move to the offset-current entry and update it's next-offset to the new entry offset
4) set the offset-current to the new entry's offset
4a) if it's the first entry then set offset-first as well
5) flush the file buffers to ensure the disk image is current in case of crashes.
Mark
|
|
|
|
|
It's probably the best way to approach the problem. The only trouble is dealing with the items when the file reaches it's max size. Obviously the oldest entries should be removed, but going from the begininning to the end is where the problem lies. Each entry would have to be a fixed size. So lets make them 256 bytes each, but what happens when a critical error occurs and it needs 600 bytes to log the error?
So I'm thinking of a structure similar to a FAT table. IE have allocation slots within the file, but the problem here is how to index them.
|
|
|
|
|
WalderMort wrote: The only trouble is dealing with the items when the file reaches it's max size. Obviously the oldest entries should be removed,
 Yeah. A linked list allows for variable size entries no problem (each entry just needs
a little header of some kind (with at least a next_offset field and a length field).
Whether you use a table (like FAT) or a linked list you still end up with fragmented file image
(little holes of free space) when removing oldest etries since there's two types of entries.
You'll have to periodically defrag anyway so a table would be much more efficient then walking
a chain of offsets every time.
I guess each entry in a FAT_style table could represent a 256-byte area of the log file.
Each entry only needs to be a WORD, with perhaps 0 indicating free, 0xFFFF indicating the last
entry in a chain of entries, and any other value indicates the index of the next entry in the
chain.
Reserve entries at index 0 and 1 for "directories" (one for each of the two types of log
entries). In the directories keep structs for each log entry - each struct has a timestamp and
an index into the "FAT" table of the first 256-byte "sector" of the entry. The directories can
grow as necessary since they are just linked chains in the "FAT" table. Of course, directory
entries need a way to be marked as free as well.
That's pretty similar to the FAT system if I remember right 
Thank goodness for random access files!
|
|
|
|
|
I had a thought about this last night. I will use a linked list of fixed size structures, let's say 128 bytes. Each entry may use one or more of these structures to span the data. The first would contain the time stamps, source details etc.. the next would act as an overflow from the first.
Continue like this until the end of the file is found, then, link the last to the first and overwrite the data within the first group of items, if more space is required, overwrite the next group also.
Depending on the size chosen for each structure, the wasted space would be limited to a few bytes for each entered record. In the header, I would only need to store the offset to the first and last. Each record would then store an offset to it's overflow and a count of it's overflows ( if required ) and the offset of the next list item.
On with the coding...
|
|
|
|
|
Could you consider to make a CP article on the subject? I find it really interesting, and so does others, I suspect.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Possibly, it really depends on how much closely it ties in with my project. Ultimatly I would like to make it re-usable, in which case I may create an article, if I have time.
|
|
|
|
|
I, for one, would (will) really look forward to such an article.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Hi All,
Here's an interesting one... Debug is Broken, Release is OK. I've got test cases down to failures on LARGE files in Debug Builds. The reason the large file does not exist in Release: Debug information is stripped (I'm literally probing my own EXE).
The original FileMapping code was shamelessly ripped from Matt Pietrek's An In-Depth Look into the Win32 Portable Executable File Format[^]. I can't seem to find what is wrong with the original useage.
I suspect this has to do with the Memory Manager's ability to keep up... Any ideas? Below is how I am using CreateFileMapping/MapViewOfFile.
Jeff
if( 0 == GetModuleFileName( NULL, szFilename, PATH_SIZE ) )
{
std::cout << _T("Error Retrieving Process Filename") << std::endl;
__leave;
}
hFile = CreateFile( szFilename, GENERIC_READ, FILE_SHARE_READ,
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if ( hFile == INVALID_HANDLE_VALUE )
{
std::cout << _T("Error - CreateFile()") << std::endl;
__leave;
}
hFileMapping = CreateFileMapping(hFile, NULL,
PAGE_READONLY, 0, 0, NULL);
if ( NULL == hFileMapping )
{
std::cout << _T("Error - CreateFileMapping()") << std::endl;
__leave;
}
PVOID pMappedFile = NULL;
pMappedFile = MapViewOfFile(hFileMapping, FILE_MAP_READ, 0, 0, 0);
if ( NULL == pMappedFile )
{
std::cout << _T("Error - MapViewOfFile()") << std::endl;
__leave;
}
|
|
|
|
|
Where exactly are you picking up the error and did you make sure you SetLastError before the whole process?
|
|
|
|
|
Hi Waldermort,
WalderMort wrote: Where exactly are you picking up the error...
From the Output Window in Visual Studio .NET on Windows 2000.
I also confirmed it was a bug Windows XP, and Windows Server 2003. And confirmed the behavior using Visual Studio 2005. The bad thing was, it was my bug...
Basically, when inspecting ones own .CODE section, one of two methods is used:
1) if the image is a disk image, use (.TEXT Section)pSectionHeader-> PointerToRawData to locate the first .CODE page on DISK.
2) if the image is a memory image, use (.TEXT Section)pSectionHeader-> VirtualAddress to locate the first .CODE page in MEMORY.
PointerToRawData is usually 0x1000. VirtualAddress is larger - for example 0x3D00. The previous is added to a image Base Address - 0x400000 (hModule), PVOID from MapViewOfFile(), etc. Under certain circumstances (Debug Builds with large LIB files that cause a cross of Granulation Boundary), an ACCEESS_DENIED occurs - more correctly Access Violation.
With Debug builds, VirtualAddress != PointerToRawData. In Release builds, VirtualAddress == PointerToRawData. Hence the reason why Debug failed, and Release was successful.
My error crept in with the fact that VirtualAddress >>> PointerToRawData, and I was using VirtualAddress when probing the disk image in Debug.
What was especially frustrating was the fact that I wasted time in WinDbg on my spare Server (it only has 700 MHz CPU and 768MB of RAM) - painful. My development machine has dual 1GHz with 2GB of RAM. This is my personal Test lab at the house - complete with a pair of Cisco 1700s for segment testing
Jeff
|
|
|
|
|
BTW, I think this will make for an interesting article... Others could extend it as a Dynamic Disassembler, etc. I'll have to put a Cryptographic spin on it.
Jeff
|
|
|
|
|
Jeffrey Walton wrote: I'll have to put a Cryptographic spin on it.
LMAO.
If you do make an article from it. Please, please, please make it 64-bit compatible. 
Glad you found the error.
|
|
|
|
|
Jeffrey Walton wrote: I suspect this has to do with [something other than my code or logic]...
Famous last words.
Jeff
|
|
|
|
|
Usually my last words are "Doh! It was me" 
|
|
|
|
|
hello
i am calling a web service written in C# , from MFC application , and i need to know how to change the time out of the web service from the MFC application
thanks alot
|
|
|
|
|
What do you want to do ? What time do you want to change ? Do you mean the web service returns a DateTime and you don't know how to read it ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
How I can send XML packet from client to server
|
|
|
|
|
|
Hello,
I am looking for examples of UML drawings. Drawings of class diagrams for a general dialog based GUI application. The GUI could be some general buttons for the user to press that leads to child dialogs getting opened for more user interactions.
Does anyone know of any case studies, examples, tutorials that explains what I am after? Or may be web sites of interest?
Thanks for any information you could provide.
|
|
|
|
|
Hi All,
Please clarfy this point.
I have two classes COne and CTwo.And in the class declaration of COne i have the following declarations.
Class COne Class CTwo
{ {
Public: Public:
CTwo* p; int i,j;
CTwo p1;
CTwo *p2=new CTwo;
}; };
I want to know when i should do a "CTwo *p" and When "CTwo p1" and when i should do "CTwo * p2=new CTwo" because after all the declarations we can access the member functions and data members of the class CTwo.
Thanking you,
Ashwath Hegde.
|
|
|
|
|
You dont need to ask repeated
|
|
|
|
|
He has posted slightly different code in each thread. Perhaps he should locate the 'edit' button instead?
|
|
|
|
|
It seems odd for COne to have both "has a" and "is a" constructs. Is that intentional?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hello,
Does anyone know whic *.dll files I need to include with my VS2005 C++(MFC) Application
in order to run it on other machine, which does not have VS2005 installed ?
thanks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
