"this" pointer get corrupted after function call

[Krishs]

Hi all,
well this is pretty much confusion to me as well, but here is
scenario. I have two shared objects file and one loader executable.
loader calls extern function in shared1 , which has one class ,
initialize it and run its method , which would call extern in shared2.
after shared2 extern function returns, the "this" pointer get 0x00 in
A::Run(),
any guess what would have been happened, I have using gcc version 4+
to build the project.

** loader.cpp
- calls run_test(); in shared1.cpp

** shared1.cpp
class A {
public:
Run() { mum_tum(); doWell(); }
doWell() { }
};

extern void run_test() {
A *a = new A();
a->Run();
}

** shared2.cpp
extern void mum_tum() { }

thank you.

 

[Alf P. Steinbach]

Hi all,
well this is pretty much confusion to me as well, but here is
scenario. I have two shared objects file and one loader executable.
loader calls extern function in shared1 , which has one class ,
initialize it and run its method , which would call extern in shared2.
after shared2 extern function returns, the "this" pointer get 0x00 in
A::Run(),
any guess what would have been happened, I have using gcc version 4+
to build the project.

** loader.cpp
- calls run_test(); in shared1.cpp

** shared1.cpp
class A {
public:
Run() { mum_tum(); doWell(); }
doWell() { }
};

extern void run_test() {
A *a = new A();
a->Run();
}

** shared2.cpp
extern void mum_tum() { }

thank you.

with three different method naming conventions in so short a code, plus
a question of non-reproducable behavior where even the description of
what's allegedly wrong is suspect, this is clearly a troll posting

- alf

 

[wenxing zheng]

i have made a simulate program based on your description above, find no issue on windows platform.

How about your codes?

 

[Krishs P.]

with three different method naming conventions in so short a code, plus
a question of non-reproducable behavior where even the description of
what's allegedly wrong is suspect, this is clearly a troll posting

- alf

thx for the reply . but, the code i am working with is pretty much big and complex, so I described the scenario with short pseudo code. The main problem relies when actual this pointer of "class A" get vanished after call to extern function in second shared dll. What I am concerned here is if it is case of stack corruption or something. I have checked similar case from gdbforum but no clue.

 

[Krishs P.]

Here is short debugging session information

(gdb) l
tResult = RunClient(&tParams, &tResults, &m_bStopped, m_szName, m_szInstHdl,
gethostbyname);


(gdb) p this
$1 = (CFtpActiveTest * const) 0x80da4a0
(gdb) n
(gdb)
CActiveTest::Run (this=0x0) at ActiveTest.cpp:47
47 if (tResult != TESTERR_OK)
(gdb)
(gdb) p this
$2 = (CActiveTest* const) 0x0
(gdb)

 

[Ian Collins]

thx for the reply . but, the code i am working with is pretty much big and complex, so I described the scenario with short pseudo code. The main problem relies when actual this pointer of "class A" get vanished after call to extern function in second shared dll. What I am concerned here is if it is case of stack corruption or something. I have checked similar case from gdb forum but no clue.

Please wrap your lines!

It looks like you problem may be windows rather than C++ related, have
you tried a windows group?

 

[Guest]

thx for the reply . but, the code i am working with is pretty much big and complex, so I described the scenario with short pseudo code. The main problem relies when actual this pointer of "class A" get vanished after call to extern function in second shared dll. What I am concerned here is if it is case of stack corruption or something. I have checked similar case from gdb forum but no clue.

can you get a short, complete program to exhibit the problem?

 

[Krishs P.]

Please wrap your lines!

It looks like you problem may be windows rather than C++ related, have
you tried a windows group?

No actually, this is on linux with gcc compiler suite. here is short debugging session information

(gdb) l
tResult = RunClient(&tParams, &tResults, &m_bStopped, m_szName, m_szInstHdl,
gethostbyname);


(gdb) p this
$1 = (CActiveTest * const) 0x80da4a0
(gdb) n
(gdb)
CActiveTest::Run (this=0x0) at ActiveTest.cpp:47
47 if (tResult != TESTERR_OK)
(gdb)
(gdb) p this
$2 = (CActiveTest* const) 0x0
(gdb)

 

[Ian Collins]

No actually, this is on linux with gcc compiler suite. here is short debugging session information

Ah, dll is the wrong term then.

Are you sure everything is built with the same compiler and options?

 

[Krishs P.]

Ah, dll is the wrong term then.

Are you sure everything is built with the same compiler and options?

uhhhh pretty silly bug was that!!! after entire day on that finally i figured out what was going wrong

in mum_tum() function , mistakenly I had this line
memset(resolved_host_, 0 , sizeof(struct addrinfo));

and resolved_host_ was declared as struct addrinfo* type in header ...

and memset was doing what it has asked to do .. setting up 32 bytes to 0
causing this pointer memory corrupt ..

btw thanks you guys for your time.

 

[Werner]

in mum_tum() function , mistakenly I had this line
memset(resolved_host_, 0 , sizeof(struct addrinfo));

Ahhh. Memset has this uncanny knack of corrupting this pointers...

Regards,

Werner