abend modifying value of "public" variable

Question

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:

C#

if(m_pUAS->GetAndSetSpecs(1, text) > 0)
            m_szUAQRHelp = m_pUAS->m_szHelp;

in cdxuattspecs.h I have the follwing code:

C#

public:
	int		GetAndSetSpecs(int, char *);
	CString		m_szHelp;

in cdxuattspecs.cpp I have the following code:

C#

        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;

    if(iopt)
    {
// 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);
        if(CdxUAttSpecs_data)
        {
            rc = 0;
            knt = fread(CdxUAttSpecs_data, len, 1, CdxUAttSpecs_key);
            fclose(CdxUAttSpecs_key);
                .
                .
                .
        }
    }
}

When the code in cdxuattqr.cpp

C#

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

C#

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.

ASM

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)]

Posted 24-Sep-12 9:10am

tom_delorenzo

Updated 24-Sep-12 11:26am

v3

Add a Solution

Comments

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?

pasztorpisti 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.

4 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Chuck O'Toole · Answer 1 · 2012-09-24T12:05:00

If I remember from your previous question, you declared

C#

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 "->".

Mark Ginnane · Answer 2 · 2012-09-24T12:38:00

Solution 2

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!

Posted 24-Sep-12 12:38pm

Mark Ginnane

Updated 24-Sep-12 12:40pm

v2

Comments

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).

Mark Ginnane · Answer 3 · 2012-09-24T13:37:00

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.

pasztorpisti · Answer 4 · 2012-09-24T17:07:00

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: http://en.wikipedia.org/wiki/Magic_number_(programming)[^]
Or Maybe this one is better this time as it explains memory management related magic numbers: http://www.nobugs.org/developer/win32/debug_crt_heap.html[^]
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.

abend modifying value of "public" variable

4 solutions

Solution 1

Solution 2

Solution 3

Solution 4

Add your solution here

Preview 0