Click here to Skip to main content
14,732,982 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
As if my last question didn't demonstrate my lack of C++ expertise, I will now try to outdo myself.

in cdxuattqr.cpp I have the following code:
if(m_pUAS->GetAndSetSpecs(1, text) > 0)
            m_szUAQRHelp = m_pUAS->m_szHelp;

in cdxuattspecs.h I have the follwing code:
	int		GetAndSetSpecs(int, char *);
	CString		m_szHelp;

in cdxuattspecs.cpp I have the following code:
        char			CdxUAttSpecs_path[24]="C:\\tempDBspecfile.txt";	
	FILE			*CdxUAttSpecs_key;
	char			*CdxUAttSpecs_data=0;

int CCdxUAttSpecs::GetAndSetSpecs(int iopt, char *string)
    int     knt=0, len=0, ichk=0, m, rc;
    char    *ptr, *ptr2, *ptr3;

    rc = -1;

// init to default
        m_szHelp = "No help message";

    if((CdxUAttSpecs_key=fopen(CdxUAttSpecs_path, "r")))
        len = filelength(fileno(CdxUAttSpecs_key));
        ichk = len + 4;
        CdxUAttSpecs_data = (char *) setalloc(&zero, CdxUAttSpecs_data, &ichk);
            rc = 0;
            knt = fread(CdxUAttSpecs_data, len, 1, CdxUAttSpecs_key);

When the code in cdxuattqr.cpp
if(m_pUAS->GetAndSetSpecs(1, text) > 0)
            m_szUAQRHelp = m_pUAS->m_szHelp;

gets executed, I abend as soon as I try to initialize the public variable m_szHelp in GetAndSetSpecs.

If I comment out the line
m_szHelp = "No help message";

everything works fine. Why the problems with the "public" variable and not any of the others?

This is the text of the abend:
First-chance exception at 0x6129a1a3 (mfc90d.dll) in cdx.exe: 0xC0000005: Access violation reading location 0xf8245b20.
First-chance exception at 0x772a47db in cdx.exe: 0xC015000F: The activation context being deactivated is not the most recently activated one.
First-chance exception at 0x77259dc1 in cdx.exe: 0xC0000005: Access violation reading location 0xfeeefefe.
Unhandled exception at 0x77259dc1 in cdx.exe: 0xC0000005: Access violation reading location 0xfeeefefe.
The program '[1156] cdx.exe: Native' has exited with code -1073741819 (0xc0000005).

This is the disassembly of the failing code. The variable "this" is zero. That seems wrong to me.

m_szHelp = "No help message";
100384B0  push        offset __real@40c3880000000000+0CCh (10C17F84h)
100384B5  mov         ecx,dword ptr [this]
100384B8  add         ecx,0ECh
100384BE  call        dword ptr [__imp_ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::operator= (10C0224Ch)]
Updated 24-Sep-12 12:26pm
CPallini 24-Sep-12 15:32pm
I don't see the bug in your code. How is m_szUAQRHelp declared? Could you post more code?
xenotron 24-Sep-12 15:46pm
Have you debugged your code? How many times does m_szHelp = "No help message"; gets executed before the crash, maybe its not the first execution when you abend. The reason of crash can be something completely different for example a heap corruption that caused the overwrite of some parts of the string... Post some more code if its not top secret, noone can solve this otherwise.
tom_delorenzo 24-Sep-12 15:55pm
m_szUAQRHelp is a CString defined in the header file of cdxuattqr. Plus, I don't actually get that far in the code since I abend prior to that point in GetAndSetSpecs. I don't know what other code to post. I'm only executing GetAndSetSpecs. Would m_szHelp not actually exist yet? I always get suspicious when I see 'feeefeee' (or anything close to it) in the abend message. I find that usually means something isn't initialized. In this case, the address of m_szHelp? . . . . but why?
tom_delorenzo 24-Sep-12 15:56pm
re pasztorpisti - it's the first time through. I have a break point there in debug.

If I remember from your previous question, you declared
extern  CCdxUAttSpecs   *m_pUAS;    // <--- why unresolved???
extern  CCdxUAtts       *m_pUA;

and so they are pointers to objects (clearly your references indicate that). OK, so that gets them declared and defined (once you fixed the problems in your other post). OK, how are they "initialized"? How do you create an instance of the object that you are pointing to? The crash indicats that you are using a NULL pointer to access the object so if you took CPallini's suggestion and used
CCdxUAttSpecs   *m_pUAS = NULL;
then you have not instantiated the object, just set the pointer to zero.

If you intend on using pointers to these, you will have to do a "new" at some point.
CCdxUAttSpecs   *m_pUAS = new CCdxUAttSpecs;

Of course, you could statically allocate them (i.e., not use pointers) but then you'd have to change all the code to use "." instead of "->".
Chuck O'Toole 24-Sep-12 18:08pm
Oh, and do people still say "Abend"? I thought that as an IBMism from the 60's. When I was writing IBM/360 code back then, my favorite abend code was User 240. It printed in hex so it came out "Abend UF0"
barneyman 24-Sep-12 20:24pm
it was a Novell Netware term too
Chuck O'Toole 24-Sep-12 21:00pm
Thanks, never did that one
Why don't you initialise the m_szHelp member variable in the constructor of the CCdxUAttSpecs class, rather than in one of its methods?
In addition,
abend? Whay not say what really happend --- crash!
Chuck O'Toole 24-Sep-12 19:18pm
Initializing it in the constructor is a good suggestion, assuming he ever get to the constructor. With "this" set to NULL, a constructor wouldn't help :)
Mark Ginnane 24-Sep-12 19:35pm
A 'this' pointer would be internal to the class.
A simple test on m_pUAS to see if it was null and then some error handling code would stop the crashes. Then he could focus on the code that is supposed to instantiate the thing (not inluded here from what I can see).
I think the question may be one of timing.
The pointer CCdxUAttSpecs *m_pUAS is declared extern, meaning that it has to be assigned from some external piece of code.
Maybe this code is being executed BEFORE that pointer is actually assigned a value.
So, a good hard desk-check of the way the code is designed to run may be in order.
I was absent-minded, didn't see the 0xfeeefeee. If you don't know what these values mean then please follow this link for a comprehensive list of magic numbers:[^]
Or Maybe this one is better this time as it explains memory management related magic numbers:[^]
0xfeeefeee is a HeapFree() related stuff. I guess your bug is something like this:
You have a pointer to an object that was created with new on the heap and then deleted its. For this reason HeapFree() filled up the content of your object with feeefeee but you still have a pointer to the memory area originally occupied by that object. After this you call one of the methods of the object that tries to use one of its own data members but this time it finds just feeefeee inside itself - and tries to use one of its member pointers whose value is actually a feeefeee.
Even if the problem is something else, do this in your debugger: We need a callstack. If your program crashes so badly that you dont have a usable callstack then try to break the program with a breakpoint right before the crashy part. Check Every level of the callstack from bottom to top and on each level check out the value of the this pointer. If you find zero or nearly zero value in it or other suspicious values like magic numbers then you found the location of the first invalid call or at least a spot nearly after you called the method on a pointer that is either null or deleted or whatever. Still you have to find out the reason for the uninitialized (NULL) or invalid/deleted objects, it can be a consequence of some logic/design mistakes you committed somewhere else.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900