Re: "this" pointer get corrupted after function call
On Wednesday, 27 June 2012 14:16:38 UTC+5:30, Ian Collins wrote:
On 06/27/12 08:35 PM, Krishs P. wrote:
On Wednesday, 27 June 2012 13:42:33 UTC+5:30, Ian Collins wrote:
On 06/27/12 07:39 PM, Krishs P. wrote:
On Wednesday, 27 June 2012 12:44:53 UTC+5:30, Alf P. Steinbach wrote=
:
On 27.06.2012 08:36, Krishs wrote:
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 share=
d2..
after shared2 extern function returns, the "this" pointer get 0=
x00 in
A::Run(),
any guess what would have been happened, I have using gcc versi=
on 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, p=
lus
a question of non-reproducable behavior where even the description o=
f
what's allegedly wrong is suspect, this is clearly a troll posting
thx for the reply . but, the code i am working with is pretty much bi=
g 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 ca=
ll 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 fr=
om 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?
No actually, this is on linux with gcc compiler suite. here is short de=
bugging session information
Ah, dll is the wrong term then.
Are you sure everything is built with the same compiler and options?
--
Ian Collins
uhhhh pretty silly bug was that!!! after entire day on that finally i figur=
ed 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.