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.

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

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

How about your codes?

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 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 =3D new A();
> >                 a->Run();
> >         }
> >
> > ** shared2.cpp
> >        extern void mum_tum()  { }
> >
> > thank you.
> >
>=20
> with three different method naming conventions in so short a code, plus=
=20
> a question of non-reproducable behavior where even the description of=20
> what's allegedly wrong is suspect, this is clearly a troll posting
>=20
> - 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 probl=
em 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.=20

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)

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 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
>
> 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?

-- 
Ian Collins

On Wednesday, June 27, 2012 8:39:45 AM UTC+1, 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 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 =3D new A();
> > >                 a->Run();
> > >         }
> > >
> > > ** shared2.cpp
> > >        extern void mum_tum()  { }
> > >
> > > thank you.
> > >
> >=20
> > with three different method naming conventions in so short a code, plus=
=20
> > a question of non-reproducable behavior where even the description of=
=20
> > what's allegedly wrong is suspect, this is clearly a troll posting
> >=20
> > - alf
>=20
> thx for the reply . but, the code i am working with is pretty much big an=
d complex, so I described the scenario with short pseudo code. The main pro=
blem relies when actual this pointer of "class A" get vanished after call t=
o extern function in second shared dll. What I am concerned here is if it i=
s case of stack corruption or something. I have checked similar case from g=
db forum but no clue.

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

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 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 =3D new A();
> >>>                  a->Run();
> >>>          }
> >>>
> >>> ** shared2.cpp
> >>>         extern void mum_tum()  { }
> >>>
> >>> thank you.
> >>>
> >>
> >> with three different method naming conventions in so short a code, plu=
s
> >> a question of non-reproducable behavior where even the description of
> >> 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 big =
and complex, so I described the scenario with short pseudo code. The main p=
roblem 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.
>=20
> Please wrap your lines!
>=20
> It looks like you problem may be windows rather than C++ related, have=20
> you tried a windows group?
>=20
> --=20
> Ian Collins

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

(gdb) l=20
tResult =3D RunClient(&tParams, &tResults, &m_bStopped, m_szName, m_szInstH=
dl,=20
                                gethostbyname);=20


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

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 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
>>>
>>> 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?

>
> 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?

-- 
Ian Collins

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 =3D 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?
>=20
> >
> > No actually, this is on linux with gcc compiler suite. here is short de=
bugging session information
>=20
> Ah, dll is the wrong term then.
>=20
> Are you sure everything is built with the same compiler and options?
>=20
> --=20
> 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 ...=20

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

btw thanks you guys for your time.=20

On Wednesday, June 27, 2012 3:24:43 PM UTC+2, Krishs P. wrote:
> 
> 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

On Jun 27, 6:36=A0pm, Krishs <krishs.pa...@gmail.com> wrote:
> ** shared1.cpp
> =A0 =A0 =A0 =A0class A {
> =A0 =A0 =A0 =A0 =A0 =A0public:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Run() { =A0mum_tum(); doWell(); }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 doWell() { }
> =A0 =A0 =A0 =A0};
>
> =A0 =A0 =A0 =A0extern void run_test() {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A *a =3D new A();
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a->Run();
> =A0 =A0 =A0 =A0}
>
> ** shared2.cpp
> =A0 =A0 =A0 extern void mum_tum() =A0{ }

mum_tum() probably has bad code in it that
is causing memory corruption. You could debug
it by commenting out various bits of mum_tum
and finding which piece of code is introducing the problem.