Compiling cint7

[A Navaei]

Hi,

I have tried building the latest version of cint in the repository
configured with --coreversion=new, assuming that this would build the
cint7. However, when I run the binary, I get this:

cint : C/C++ interpreter  (mailing list 'cint@...')
   Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
   revision     : 5.16.29, Jan 08, 2008 by M.Goto

Am I missing something or simply it shows the wrong version?


-Ali

[Severin Ecker-2]

Hi Ali,

I'm currently trying to switch to cint7 and using --coreversion=new
works for me (win32, msvc8), so there's probably an issue with the
makefile you get for your platform?

i get
cint : C/C++ interpreter  (mailing list 'cint@...')
   Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
   revision     : 7.3.00, December 21, 2008 by M.Goto

that is, after I've removed the #ifdef for G__ROOT around the
G__new_interpreted_object() function in Api.h and Api.cxx, because
Apiif.cxx uses it in any case. (I wonder how this compiles for anyone
who builds cint alone aka without the whole root environment)

cheers,
severin


A Navaei wrote:

> Hi,
>
> I have tried building the latest version of cint in the repository
> configured with --coreversion=new, assuming that this would build the
> cint7. However, when I run the binary, I get this:
>
> cint : C/C++ interpreter  (mailing list 'cint@...')
>    Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
>    revision     : 5.16.29, Jan 08, 2008 by M.Goto
>
> Am I missing something or simply it shows the wrong version?
>
>
> -Ali
>
>  

[Philippe Canal]

Hi,

I can not reproduce this problem .. your path might be pointing to an
older version of Cint?

Cheers,
Philippe.

A Navaei wrote:

> Hi,
>
> I have tried building the latest version of cint in the repository
> configured with --coreversion=new, assuming that this would build the
> cint7. However, when I run the binary, I get this:
>
> cint : C/C++ interpreter  (mailing list 'cint@...')
>    Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
>    revision     : 5.16.29, Jan 08, 2008 by M.Goto
>
> Am I missing something or simply it shows the wrong version?
>
>
> -Ali
>
>  

[Philippe Canal]

Hi Severing,

 > that is, after I've removed the #ifdef for G__ROOT

Alternatively you can force the regeneration of Apiif.cxx:

   rm cint7/src/dict/Apii*

Cheers,
Philippe.


Severin Ecker wrote:

> Hi Ali,
>
> I'm currently trying to switch to cint7 and using --coreversion=new
> works for me (win32, msvc8), so there's probably an issue with the
> makefile you get for your platform?
>
> i get
> cint : C/C++ interpreter  (mailing list 'cint@...')
>   Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
>   revision     : 7.3.00, December 21, 2008 by M.Goto
>
> that is, after I've removed the #ifdef for G__ROOT around the
> G__new_interpreted_object() function in Api.h and Api.cxx, because
> Apiif.cxx uses it in any case. (I wonder how this compiles for anyone
> who builds cint alone aka without the whole root environment)
>
> cheers,
> severin
>
>
> A Navaei wrote:
>> Hi,
>>
>> I have tried building the latest version of cint in the repository
>> configured with --coreversion=new, assuming that this would build the
>> cint7. However, when I run the binary, I get this:
>>
>> cint : C/C++ interpreter  (mailing list 'cint@...')
>>    Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
>>    revision     : 5.16.29, Jan 08, 2008 by M.Goto
>>
>> Am I missing something or simply it shows the wrong version?
>>
>>
>> -Ali
>>
>>  
>

[A Navaei]

Hi All,

I have tried a fresh svn check out together with rm
cint7/src/dict/Apii*, still getting the old version number. the
compilation does happen with cint7 source path, is there any other
ways of confirming the version (any new commands, etc)?

Here is my makefile.config:

----------------------
# Makefile.conf for Cint
# generated by configure with options
# --prefix=/home/dev/cint/inst/ --coreversion=new
G__CFG_CINTVERSION := 7.3.00
G__CFG_ARCH := linux
G__CFG_COREVERSION := cint7
G__CFG_CC := gcc
G__CFG_CFLAGS := -O2
G__CFG_CMACROS :=  -DG__SHAREDLIB -DG__OSFDLL -DG__ANSI
-DG__ERRORCALLBACK -DG__SIGNEDCHAR -DG__NEWSTDHEADER -DG__CINT_VER6
-DG__NATIVELONGLONG -DG__P2FCAST -DG__STD_EXCEPTION -DG__HAVE_CONFIG
-DG__NOMAKEINFO
G__CFG_COMP := -c
G__CFG_CPP := gcc -E -C
G__CFG_COUT := -o
G__CFG_COUTEXE := -o
G__CFG_INCP := -I
G__CFG_CXX := g++
G__CFG_CXXFLAGS := -O2  -DG__GNUREADLINE
G__CFG_CXXMACROS :=   -DG__SHAREDLIB -DG__OSFDLL -DG__ANSI
-DG__ERRORCALLBACK -DG__SIGNEDCHAR -DG__NEWSTDHEADER -DG__CINT_VER6
-DG__NATIVELONGLONG -DG__P2FCAST -DG__STD_EXCEPTION -DG__HAVE_CONFIG
-DG__NOMAKEINFO
G__CFG_LD := g++
G__CFG_LDFLAGS := -O2
G__CFG_LDOUT := -o
G__CFG_LIBP := -L
G__CFG_LIBL := -l@imp@
G__CFG_SOFLAGS :=  -shared
G__CFG_SOOUT := -o
G__CFG_OBJEXT := .o
G__CFG_SOEXT := .so
G__CFG_LIBEXT := .a
G__CFG_IMPLIBEXT := .a
G__CFG_DEFAULTLIBS := -lm -ldl
G__CFG_MANGLEPATHS := echo
G__CFG_MANGLEPATHSU := echo
G__CFG_STREAMDIR := gcc4strm
G__CFG_READLINELIB := /usr/lib/libreadline.a
G__CFG_CURSESLIB := /usr/lib/libncurses.a
G__CFG_LINK_READLINELIB := -L/usr/lib -lreadline
G__CFG_LINK_CURSESLIB := -L/usr/lib -lncurses
G__CFG_RM := rm -rf
G__CFG_MV := mv -f
G__CFG_WITHPREFIX := 1
G__CFG_INPUTMODE := cint
G__CFG_INPUTMODELOCK := off
G__CFG_AR := ar qcs
G__CFG_HAVE_CONFIG := 1
G__CFG_PREFIX := /home/dev/cint/inst/
G__CFG_EPREFIX := /home/dev/cint/inst/
G__CFG_BINDIR := /home/dev/cint/inst//bin
G__CFG_LIBDIR := /home/dev/cint/inst//lib
G__CFG_INCLUDEDIR := /home/dev/cint/inst//include
G__CFG_INCLUDEDIRCINT := /home/dev/cint/inst//include/cint
G__CFG_DATADIR := /home/dev/cint/inst//share
G__CFG_DATADIRCINT := /home/dev/cint/inst//share/cint
G__CFG_MANDIR := /home/dev/cint/inst//share/man

--------------------

2009/1/7 Philippe Canal <pcanal@...>:

> Hi Severing,
>
>> that is, after I've removed the #ifdef for G__ROOT
>
> Alternatively you can force the regeneration of Apiif.cxx:
>
>  rm cint7/src/dict/Apii*
>
> Cheers,
> Philippe.
>
>
> Severin Ecker wrote:
>>
>> Hi Ali,
>>
>> I'm currently trying to switch to cint7 and using --coreversion=new works
>> for me (win32, msvc8), so there's probably an issue with the makefile you
>> get for your platform?
>>
>> i get
>> cint : C/C++ interpreter  (mailing list 'cint@...')
>>  Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
>>  revision     : 7.3.00, December 21, 2008 by M.Goto
>>
>> that is, after I've removed the #ifdef for G__ROOT around the
>> G__new_interpreted_object() function in Api.h and Api.cxx, because Apiif.cxx
>> uses it in any case. (I wonder how this compiles for anyone who builds cint
>> alone aka without the whole root environment)
>>
>> cheers,
>> severin
>>
>>
>> A Navaei wrote:
>>>
>>> Hi,
>>>
>>> I have tried building the latest version of cint in the repository
>>> configured with --coreversion=new, assuming that this would build the
>>> cint7. However, when I run the binary, I get this:
>>>
>>> cint : C/C++ interpreter  (mailing list 'cint@...')
>>>   Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
>>>   revision     : 5.16.29, Jan 08, 2008 by M.Goto
>>>
>>> Am I missing something or simply it shows the wrong version?
>>>
>>>
>>> -Ali
>>>
>>>
>>
>
>

[Philippe Canal]

Hi,

I tried the following:
    ./configure --prefix=/home/pcanal/cint_working/cint_inst
    gmake
    gmake install
    cd ../cint_inst/
    export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${PWD}/lib
    bin/cint
and got (as expected):

cint : C/C++ interpreter  (mailing list 'cint@...')
   Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
   revision     : 7.3.00, December 21, 2008 by M.Goto

So either you did not issue the gmake install and/or an older libCint is
placed in one of the directories listed in your LD_LIBRARY_PATH before
/home/dev/cint/inst/lib (which must be on your LD_LIBRARY_PATH).

Cheers,
Philippe.

A Navaei wrote:

> Hi All,
>
> I have tried a fresh svn check out together with rm
> cint7/src/dict/Apii*, still getting the old version number. the
> compilation does happen with cint7 source path, is there any other
> ways of confirming the version (any new commands, etc)?
>
> Here is my makefile.config:
>
> ----------------------
> # Makefile.conf for Cint
> # generated by configure with options
> # --prefix=/home/dev/cint/inst/ --coreversion=new
> G__CFG_CINTVERSION := 7.3.00
> G__CFG_ARCH := linux
> G__CFG_COREVERSION := cint7
> G__CFG_CC := gcc
> G__CFG_CFLAGS := -O2
> G__CFG_CMACROS :=  -DG__SHAREDLIB -DG__OSFDLL -DG__ANSI
> -DG__ERRORCALLBACK -DG__SIGNEDCHAR -DG__NEWSTDHEADER -DG__CINT_VER6
> -DG__NATIVELONGLONG -DG__P2FCAST -DG__STD_EXCEPTION -DG__HAVE_CONFIG
> -DG__NOMAKEINFO
> G__CFG_COMP := -c
> G__CFG_CPP := gcc -E -C
> G__CFG_COUT := -o
> G__CFG_COUTEXE := -o
> G__CFG_INCP := -I
> G__CFG_CXX := g++
> G__CFG_CXXFLAGS := -O2  -DG__GNUREADLINE
> G__CFG_CXXMACROS :=   -DG__SHAREDLIB -DG__OSFDLL -DG__ANSI
> -DG__ERRORCALLBACK -DG__SIGNEDCHAR -DG__NEWSTDHEADER -DG__CINT_VER6
> -DG__NATIVELONGLONG -DG__P2FCAST -DG__STD_EXCEPTION -DG__HAVE_CONFIG
> -DG__NOMAKEINFO
> G__CFG_LD := g++
> G__CFG_LDFLAGS := -O2
> G__CFG_LDOUT := -o
> G__CFG_LIBP := -L
> G__CFG_LIBL := -l@imp@
> G__CFG_SOFLAGS :=  -shared
> G__CFG_SOOUT := -o
> G__CFG_OBJEXT := .o
> G__CFG_SOEXT := .so
> G__CFG_LIBEXT := .a
> G__CFG_IMPLIBEXT := .a
> G__CFG_DEFAULTLIBS := -lm -ldl
> G__CFG_MANGLEPATHS := echo
> G__CFG_MANGLEPATHSU := echo
> G__CFG_STREAMDIR := gcc4strm
> G__CFG_READLINELIB := /usr/lib/libreadline.a
> G__CFG_CURSESLIB := /usr/lib/libncurses.a
> G__CFG_LINK_READLINELIB := -L/usr/lib -lreadline
> G__CFG_LINK_CURSESLIB := -L/usr/lib -lncurses
> G__CFG_RM := rm -rf
> G__CFG_MV := mv -f
> G__CFG_WITHPREFIX := 1
> G__CFG_INPUTMODE := cint
> G__CFG_INPUTMODELOCK := off
> G__CFG_AR := ar qcs
> G__CFG_HAVE_CONFIG := 1
> G__CFG_PREFIX := /home/dev/cint/inst/
> G__CFG_EPREFIX := /home/dev/cint/inst/
> G__CFG_BINDIR := /home/dev/cint/inst//bin
> G__CFG_LIBDIR := /home/dev/cint/inst//lib
> G__CFG_INCLUDEDIR := /home/dev/cint/inst//include
> G__CFG_INCLUDEDIRCINT := /home/dev/cint/inst//include/cint
> G__CFG_DATADIR := /home/dev/cint/inst//share
> G__CFG_DATADIRCINT := /home/dev/cint/inst//share/cint
> G__CFG_MANDIR := /home/dev/cint/inst//share/man
>
> --------------------
>
> 2009/1/7 Philippe Canal <pcanal@...>:
>  
>> Hi Severing,
>>
>>    
>>> that is, after I've removed the #ifdef for G__ROOT
>>>      
>> Alternatively you can force the regeneration of Apiif.cxx:
>>
>>  rm cint7/src/dict/Apii*
>>
>> Cheers,
>> Philippe.
>>
>>
>> Severin Ecker wrote:
>>    
>>> Hi Ali,
>>>
>>> I'm currently trying to switch to cint7 and using --coreversion=new works
>>> for me (win32, msvc8), so there's probably an issue with the makefile you
>>> get for your platform?
>>>
>>> i get
>>> cint : C/C++ interpreter  (mailing list 'cint@...')
>>>  Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
>>>  revision     : 7.3.00, December 21, 2008 by M.Goto
>>>
>>> that is, after I've removed the #ifdef for G__ROOT around the
>>> G__new_interpreted_object() function in Api.h and Api.cxx, because Apiif.cxx
>>> uses it in any case. (I wonder how this compiles for anyone who builds cint
>>> alone aka without the whole root environment)
>>>
>>> cheers,
>>> severin
>>>
>>>
>>> A Navaei wrote:
>>>      
>>>> Hi,
>>>>
>>>> I have tried building the latest version of cint in the repository
>>>> configured with --coreversion=new, assuming that this would build the
>>>> cint7. However, when I run the binary, I get this:
>>>>
>>>> cint : C/C++ interpreter  (mailing list 'cint@...')
>>>>   Copyright(c) : 1995~2005 Masaharu Goto (gotom@...)
>>>>   revision     : 5.16.29, Jan 08, 2008 by M.Goto
>>>>
>>>> Am I missing something or simply it shows the wrong version?
>>>>
>>>>
>>>> -Ali
>>>>
>>>>
>>>>        
>>    

[Severin Ecker-2]

Hi again,

I'm facing a pretty nasty problem right now so i was wondering if you
could point me to the correct code location and save me some debugging time.

I have a user defined type (MyString) compiled into my cint-interpreter
(it's a class containing an int and a std::string). within my script i
have 2 functions fA() and fB().
fA() calls fB() and fB() does nothing else than creating a MyString
object on the stack and destroying it again. But here's the problem.
My type has sizeof(MyString) == 28, so there must be at least 28 bytes
of 'stack space' for fB();
The G__getgvp() function though (called in the generated function for my
MyString class the one using the placement new) returns a pointer which
is only 14 bytes, before a memory location which is actually used
elsewhere and doesn't belong to the stack location of fB().. therefore
overwriting memory which (depending on what's overwritten) results in a
crash.

So, my question ultimately is: can you tell me where the
G__globalvarpointer (returned from G__getgvp()) is calculated for an
interpreted function? I suppose there's something bogus since it all
works perfectly well within correct bounds when i replace the MyString
object with a simple stack allocated char array.

Oh and the G__tagtable_setup() function called in
G__cpp_setup_tagtableMyCint() (generated source..) does return the
correct number for sizeof(MyString).

My thanks in advance!

cheers,
severin

ps.: I hope this was more or less understandable but don't hesitate to
ask in case you need some more information.

[Axel Naumann]

Hi Severin,

any chance that you could send us a three-liner demonstrating the issue?

Cheers, Axel.

Severin Ecker wrote:

> Hi again,
>
> I'm facing a pretty nasty problem right now so i was wondering if you
> could point me to the correct code location and save me some debugging
> time.
>
> I have a user defined type (MyString) compiled into my cint-interpreter
> (it's a class containing an int and a std::string). within my script i
> have 2 functions fA() and fB().
> fA() calls fB() and fB() does nothing else than creating a MyString
> object on the stack and destroying it again. But here's the problem.
> My type has sizeof(MyString) == 28, so there must be at least 28 bytes
> of 'stack space' for fB();
> The G__getgvp() function though (called in the generated function for my
> MyString class the one using the placement new) returns a pointer which
> is only 14 bytes, before a memory location which is actually used
> elsewhere and doesn't belong to the stack location of fB().. therefore
> overwriting memory which (depending on what's overwritten) results in a
> crash.
>
> So, my question ultimately is: can you tell me where the
> G__globalvarpointer (returned from G__getgvp()) is calculated for an
> interpreted function? I suppose there's something bogus since it all
> works perfectly well within correct bounds when i replace the MyString
> object with a simple stack allocated char array.
>
> Oh and the G__tagtable_setup() function called in
> G__cpp_setup_tagtableMyCint() (generated source..) does return the
> correct number for sizeof(MyString).
>
> My thanks in advance!
>
> cheers,
> severin
>
> ps.: I hope this was more or less understandable but don't hesitate to
> ask in case you need some more information.
>
>

[Severin Ecker-2]

Hi Axel,

Header used to generate my cint interpreter (inclusion guards etc
removed for brevity)

#include <string>

struct Str
{
    Str(const char *);
    ~Str();
   
    int dummyInt;
    std::string stringMember;
};


(accompanying cpp-file added to my interpreter executable
  Str::Str(const char* str) : stringMember(str) {}
  Str::~Str() {}
)


and here's the testscript:

void fB(unsigned int i, float val)
{
    Str msg = "i. Our intermediate value. loop runs to go\n";
}

float fA(float x)
{
    unsigned int i;
    for (i = 0; i < 2; ++i)
    {
        fB(1, 1.0);
    }
    Str hmpf = "sdflskjblsiugslfuslidfusldifu";
}


And here's the oddest thing.
- Remove the for loop and it works (even if you call the function x
times sequentially)
- Change the parameter list of fB() and it behaves differently (on my
machine and system: winxp, vs2005)
      void fB(unsigned int i, float val):   msvc debug error: stack
curruption around 'localbuf'
      void fB(unsigned int i, float val, unsigned int param):   same as
above
      void fB(unsigned int i, float val, unsigned int param, unsigned
int param2): does corrupt the stack but only 'locally' which
                                 the application can bail out without crash

as mentioned before this is (among possible other problems) due to a
wrong G__globalvarpointer which doesn't leave enough room for the object
to be created on the stack.

oh and I'm using cint5. (and STLPORT so i might need a few tweaks to
crash with the native STL)

cheers,
severin


Axel Naumann wrote:

> Hi Severin,
>
> any chance that you could send us a three-liner demonstrating the issue?
>
> Cheers, Axel.
>
> Severin Ecker wrote:
>> Hi again,
>>
>> I'm facing a pretty nasty problem right now so i was wondering if you
>> could point me to the correct code location and save me some
>> debugging time.
>>
>> I have a user defined type (MyString) compiled into my
>> cint-interpreter (it's a class containing an int and a std::string).
>> within my script i have 2 functions fA() and fB().
>> fA() calls fB() and fB() does nothing else than creating a MyString
>> object on the stack and destroying it again. But here's the problem.
>> My type has sizeof(MyString) == 28, so there must be at least 28
>> bytes of 'stack space' for fB();
>> The G__getgvp() function though (called in the generated function for
>> my MyString class the one using the placement new) returns a pointer
>> which is only 14 bytes, before a memory location which is actually
>> used elsewhere and doesn't belong to the stack location of fB()..
>> therefore overwriting memory which (depending on what's overwritten)
>> results in a crash.
>>
>> So, my question ultimately is: can you tell me where the
>> G__globalvarpointer (returned from G__getgvp()) is calculated for an
>> interpreted function? I suppose there's something bogus since it all
>> works perfectly well within correct bounds when i replace the
>> MyString object with a simple stack allocated char array.
>>
>> Oh and the G__tagtable_setup() function called in
>> G__cpp_setup_tagtableMyCint() (generated source..) does return the
>> correct number for sizeof(MyString).
>>
>> My thanks in advance!
>>
>> cheers,
>> severin
>>
>> ps.: I hope this was more or less understandable but don't hesitate
>> to ask in case you need some more information.
>>
>>

[Axel Naumann]

Hi Severin,

does .O0 (dot-oh-zero) help?

Cheers, Axel.

Severin Ecker wrote:

> Hi Axel,
>
> Header used to generate my cint interpreter (inclusion guards etc
> removed for brevity)
>
> #include <string>
>
> struct Str
> {
>    Str(const char *);
>    ~Str();
>      int dummyInt;
>    std::string stringMember;
> };
>
>
> (accompanying cpp-file added to my interpreter executable
>  Str::Str(const char* str) : stringMember(str) {}
>  Str::~Str() {}
> )
>
>
> and here's the testscript:
>
> void fB(unsigned int i, float val)
> {
>    Str msg = "i. Our intermediate value. loop runs to go\n";
> }
>
> float fA(float x)
> {
>    unsigned int i;
>    for (i = 0; i < 2; ++i)
>    {
>        fB(1, 1.0);
>    }
>    Str hmpf = "sdflskjblsiugslfuslidfusldifu";
> }
>
>
> And here's the oddest thing.
> - Remove the for loop and it works (even if you call the function x
> times sequentially)
> - Change the parameter list of fB() and it behaves differently (on my
> machine and system: winxp, vs2005)
>      void fB(unsigned int i, float val):   msvc debug error: stack
> curruption around 'localbuf'
>      void fB(unsigned int i, float val, unsigned int param):   same as
> above
>      void fB(unsigned int i, float val, unsigned int param, unsigned int
> param2): does corrupt the stack but only 'locally' which
>                                 the application can bail out without crash
>
> as mentioned before this is (among possible other problems) due to a
> wrong G__globalvarpointer which doesn't leave enough room for the object
> to be created on the stack.
>
> oh and I'm using cint5. (and STLPORT so i might need a few tweaks to
> crash with the native STL)
>
> cheers,
> severin
>
>
> Axel Naumann wrote:
>> Hi Severin,
>>
>> any chance that you could send us a three-liner demonstrating the issue?
>>
>> Cheers, Axel.
>>
>> Severin Ecker wrote:
>>> Hi again,
>>>
>>> I'm facing a pretty nasty problem right now so i was wondering if you
>>> could point me to the correct code location and save me some
>>> debugging time.
>>>
>>> I have a user defined type (MyString) compiled into my
>>> cint-interpreter (it's a class containing an int and a std::string).
>>> within my script i have 2 functions fA() and fB().
>>> fA() calls fB() and fB() does nothing else than creating a MyString
>>> object on the stack and destroying it again. But here's the problem.
>>> My type has sizeof(MyString) == 28, so there must be at least 28
>>> bytes of 'stack space' for fB();
>>> The G__getgvp() function though (called in the generated function for
>>> my MyString class the one using the placement new) returns a pointer
>>> which is only 14 bytes, before a memory location which is actually
>>> used elsewhere and doesn't belong to the stack location of fB()..
>>> therefore overwriting memory which (depending on what's overwritten)
>>> results in a crash.
>>>
>>> So, my question ultimately is: can you tell me where the
>>> G__globalvarpointer (returned from G__getgvp()) is calculated for an
>>> interpreted function? I suppose there's something bogus since it all
>>> works perfectly well within correct bounds when i replace the
>>> MyString object with a simple stack allocated char array.
>>>
>>> Oh and the G__tagtable_setup() function called in
>>> G__cpp_setup_tagtableMyCint() (generated source..) does return the
>>> correct number for sizeof(MyString).
>>>
>>> My thanks in advance!
>>>
>>> cheers,
>>> severin
>>>
>>> ps.: I hope this was more or less understandable but don't hesitate
>>> to ask in case you need some more information.
>>>
>>>
>
>

[Severin Ecker-2]

Hi Axel,

 > does .O0 (dot-oh-zero) help?

erm, I'm sorry you lost me there. do you mean if disabling the
optimizations help or something else?

cheers,
severin

> Cheers, Axel.
>
> Severin Ecker wrote:
>> Hi Axel,
>>
>> Header used to generate my cint interpreter (inclusion guards etc
>> removed for brevity)
>>
>> #include <string>
>>
>> struct Str
>> {
>>    Str(const char *);
>>    ~Str();
>>      int dummyInt;
>>    std::string stringMember;
>> };
>>
>>
>> (accompanying cpp-file added to my interpreter executable
>>  Str::Str(const char* str) : stringMember(str) {}
>>  Str::~Str() {}
>> )
>>
>>
>> and here's the testscript:
>>
>> void fB(unsigned int i, float val)
>> {
>>    Str msg = "i. Our intermediate value. loop runs to go\n";
>> }
>>
>> float fA(float x)
>> {
>>    unsigned int i;
>>    for (i = 0; i < 2; ++i)
>>    {
>>        fB(1, 1.0);
>>    }
>>    Str hmpf = "sdflskjblsiugslfuslidfusldifu";
>> }
>>
>>
>> And here's the oddest thing.
>> - Remove the for loop and it works (even if you call the function x
>> times sequentially)
>> - Change the parameter list of fB() and it behaves differently (on my
>> machine and system: winxp, vs2005)
>>      void fB(unsigned int i, float val):   msvc debug error: stack
>> curruption around 'localbuf'
>>      void fB(unsigned int i, float val, unsigned int param):   same
>> as above
>>      void fB(unsigned int i, float val, unsigned int param, unsigned
>> int param2): does corrupt the stack but only 'locally' which
>>                                 the application can bail out without
>> crash
>>
>> as mentioned before this is (among possible other problems) due to a
>> wrong G__globalvarpointer which doesn't leave enough room for the
>> object to be created on the stack.
>>
>> oh and I'm using cint5. (and STLPORT so i might need a few tweaks to
>> crash with the native STL)
>>
>> cheers,
>> severin
>>
>>
>> Axel Naumann wrote:
>>> Hi Severin,
>>>
>>> any chance that you could send us a three-liner demonstrating the
>>> issue?
>>>
>>> Cheers, Axel.
>>>
>>> Severin Ecker wrote:
>>>> Hi again,
>>>>
>>>> I'm facing a pretty nasty problem right now so i was wondering if
>>>> you could point me to the correct code location and save me some
>>>> debugging time.
>>>>
>>>> I have a user defined type (MyString) compiled into my
>>>> cint-interpreter (it's a class containing an int and a
>>>> std::string). within my script i have 2 functions fA() and fB().
>>>> fA() calls fB() and fB() does nothing else than creating a MyString
>>>> object on the stack and destroying it again. But here's the problem.
>>>> My type has sizeof(MyString) == 28, so there must be at least 28
>>>> bytes of 'stack space' for fB();
>>>> The G__getgvp() function though (called in the generated function
>>>> for my MyString class the one using the placement new) returns a
>>>> pointer which is only 14 bytes, before a memory location which is
>>>> actually used elsewhere and doesn't belong to the stack location of
>>>> fB().. therefore overwriting memory which (depending on what's
>>>> overwritten) results in a crash.
>>>>
>>>> So, my question ultimately is: can you tell me where the
>>>> G__globalvarpointer (returned from G__getgvp()) is calculated for
>>>> an interpreted function? I suppose there's something bogus since it
>>>> all works perfectly well within correct bounds when i replace the
>>>> MyString object with a simple stack allocated char array.
>>>>
>>>> Oh and the G__tagtable_setup() function called in
>>>> G__cpp_setup_tagtableMyCint() (generated source..) does return the
>>>> correct number for sizeof(MyString).
>>>>
>>>> My thanks in advance!
>>>>
>>>> cheers,
>>>> severin
>>>>
>>>> ps.: I hope this was more or less understandable but don't hesitate
>>>> to ask in case you need some more information.

[Axel Naumann]

Hi Severin,

Severin Ecker wrote:
> Hi Axel,
>
>  > does .O0 (dot-oh-zero) help?
>
> erm, I'm sorry you lost me there. do you mean if disabling the
> optimizations help or something else?

yes :-) That's set interactively with ".O0".

Cheers, Axel.

>
>
>> Cheers, Axel.
>>
>> Severin Ecker wrote:
>>> Hi Axel,
>>>
>>> Header used to generate my cint interpreter (inclusion guards etc
>>> removed for brevity)
>>>
>>> #include <string>
>>>
>>> struct Str
>>> {
>>>    Str(const char *);
>>>    ~Str();
>>>      int dummyInt;
>>>    std::string stringMember;
>>> };
>>>
>>>
>>> (accompanying cpp-file added to my interpreter executable
>>>  Str::Str(const char* str) : stringMember(str) {}
>>>  Str::~Str() {}
>>> )
>>>
>>>
>>> and here's the testscript:
>>>
>>> void fB(unsigned int i, float val)
>>> {
>>>    Str msg = "i. Our intermediate value. loop runs to go\n";
>>> }
>>>
>>> float fA(float x)
>>> {
>>>    unsigned int i;
>>>    for (i = 0; i < 2; ++i)
>>>    {
>>>        fB(1, 1.0);
>>>    }
>>>    Str hmpf = "sdflskjblsiugslfuslidfusldifu";
>>> }
>>>
>>>
>>> And here's the oddest thing.
>>> - Remove the for loop and it works (even if you call the function x
>>> times sequentially)
>>> - Change the parameter list of fB() and it behaves differently (on my
>>> machine and system: winxp, vs2005)
>>>      void fB(unsigned int i, float val):   msvc debug error: stack
>>> curruption around 'localbuf'
>>>      void fB(unsigned int i, float val, unsigned int param):   same
>>> as above
>>>      void fB(unsigned int i, float val, unsigned int param, unsigned
>>> int param2): does corrupt the stack but only 'locally' which
>>>                                 the application can bail out without
>>> crash
>>>
>>> as mentioned before this is (among possible other problems) due to a
>>> wrong G__globalvarpointer which doesn't leave enough room for the
>>> object to be created on the stack.
>>>
>>> oh and I'm using cint5. (and STLPORT so i might need a few tweaks to
>>> crash with the native STL)
>>>
>>> cheers,
>>> severin
>>>
>>>
>>> Axel Naumann wrote:
>>>> Hi Severin,
>>>>
>>>> any chance that you could send us a three-liner demonstrating the
>>>> issue?
>>>>
>>>> Cheers, Axel.
>>>>
>>>> Severin Ecker wrote:
>>>>> Hi again,
>>>>>
>>>>> I'm facing a pretty nasty problem right now so i was wondering if
>>>>> you could point me to the correct code location and save me some
>>>>> debugging time.
>>>>>
>>>>> I have a user defined type (MyString) compiled into my
>>>>> cint-interpreter (it's a class containing an int and a
>>>>> std::string). within my script i have 2 functions fA() and fB().
>>>>> fA() calls fB() and fB() does nothing else than creating a MyString
>>>>> object on the stack and destroying it again. But here's the problem.
>>>>> My type has sizeof(MyString) == 28, so there must be at least 28
>>>>> bytes of 'stack space' for fB();
>>>>> The G__getgvp() function though (called in the generated function
>>>>> for my MyString class the one using the placement new) returns a
>>>>> pointer which is only 14 bytes, before a memory location which is
>>>>> actually used elsewhere and doesn't belong to the stack location of
>>>>> fB().. therefore overwriting memory which (depending on what's
>>>>> overwritten) results in a crash.
>>>>>
>>>>> So, my question ultimately is: can you tell me where the
>>>>> G__globalvarpointer (returned from G__getgvp()) is calculated for
>>>>> an interpreted function? I suppose there's something bogus since it
>>>>> all works perfectly well within correct bounds when i replace the
>>>>> MyString object with a simple stack allocated char array.
>>>>>
>>>>> Oh and the G__tagtable_setup() function called in
>>>>> G__cpp_setup_tagtableMyCint() (generated source..) does return the
>>>>> correct number for sizeof(MyString).
>>>>>
>>>>> My thanks in advance!
>>>>>
>>>>> cheers,
>>>>> severin
>>>>>
>>>>> ps.: I hope this was more or less understandable but don't hesitate
>>>>> to ask in case you need some more information.
>

[Severin Ecker-2]

Hi Axel,

oh, well in that case nope. I'm already running debug builds with all
optimizations disabled.

cheers,
severin


Axel Naumann wrote:

> Hi Severin,
>
> Severin Ecker wrote:
>> Hi Axel,
>>
>>  > does .O0 (dot-oh-zero) help?
>>
>> erm, I'm sorry you lost me there. do you mean if disabling the
>> optimizations help or something else?
>
> yes :-) That's set interactively with ".O0".
>
> Cheers, Axel.
>
>
>>
>>
>>> Cheers, Axel.
>>>
>>> Severin Ecker wrote:
>>>> Hi Axel,
>>>>
>>>> Header used to generate my cint interpreter (inclusion guards etc
>>>> removed for brevity)
>>>>
>>>> #include <string>
>>>>
>>>> struct Str
>>>> {
>>>>    Str(const char *);
>>>>    ~Str();
>>>>      int dummyInt;
>>>>    std::string stringMember;
>>>> };
>>>>
>>>>
>>>> (accompanying cpp-file added to my interpreter executable
>>>>  Str::Str(const char* str) : stringMember(str) {}
>>>>  Str::~Str() {}
>>>> )
>>>>
>>>>
>>>> and here's the testscript:
>>>>
>>>> void fB(unsigned int i, float val)
>>>> {
>>>>    Str msg = "i. Our intermediate value. loop runs to go\n";
>>>> }
>>>>
>>>> float fA(float x)
>>>> {
>>>>    unsigned int i;
>>>>    for (i = 0; i < 2; ++i)
>>>>    {
>>>>        fB(1, 1.0);
>>>>    }
>>>>    Str hmpf = "sdflskjblsiugslfuslidfusldifu";
>>>> }
>>>>
>>>>
>>>> And here's the oddest thing.
>>>> - Remove the for loop and it works (even if you call the function x
>>>> times sequentially)
>>>> - Change the parameter list of fB() and it behaves differently (on
>>>> my machine and system: winxp, vs2005)
>>>>      void fB(unsigned int i, float val):   msvc debug error: stack
>>>> curruption around 'localbuf'
>>>>      void fB(unsigned int i, float val, unsigned int param):   same
>>>> as above
>>>>      void fB(unsigned int i, float val, unsigned int param,
>>>> unsigned int param2): does corrupt the stack but only 'locally' which
>>>>                                 the application can bail out
>>>> without crash
>>>>
>>>> as mentioned before this is (among possible other problems) due to
>>>> a wrong G__globalvarpointer which doesn't leave enough room for the
>>>> object to be created on the stack.
>>>>
>>>> oh and I'm using cint5. (and STLPORT so i might need a few tweaks
>>>> to crash with the native STL)
>>>>
>>>> cheers,
>>>> severin
>>>>
>>>>
>>>> Axel Naumann wrote:
>>>>> Hi Severin,
>>>>>
>>>>> any chance that you could send us a three-liner demonstrating the
>>>>> issue?
>>>>>
>>>>> Cheers, Axel.
>>>>>
>>>>> Severin Ecker wrote:
>>>>>> Hi again,
>>>>>>
>>>>>> I'm facing a pretty nasty problem right now so i was wondering if
>>>>>> you could point me to the correct code location and save me some
>>>>>> debugging time.
>>>>>>
>>>>>> I have a user defined type (MyString) compiled into my
>>>>>> cint-interpreter (it's a class containing an int and a
>>>>>> std::string). within my script i have 2 functions fA() and fB().
>>>>>> fA() calls fB() and fB() does nothing else than creating a
>>>>>> MyString object on the stack and destroying it again. But here's
>>>>>> the problem.
>>>>>> My type has sizeof(MyString) == 28, so there must be at least 28
>>>>>> bytes of 'stack space' for fB();
>>>>>> The G__getgvp() function though (called in the generated function
>>>>>> for my MyString class the one using the placement new) returns a
>>>>>> pointer which is only 14 bytes, before a memory location which is
>>>>>> actually used elsewhere and doesn't belong to the stack location
>>>>>> of fB().. therefore overwriting memory which (depending on what's
>>>>>> overwritten) results in a crash.
>>>>>>
>>>>>> So, my question ultimately is: can you tell me where the
>>>>>> G__globalvarpointer (returned from G__getgvp()) is calculated for
>>>>>> an interpreted function? I suppose there's something bogus since
>>>>>> it all works perfectly well within correct bounds when i replace
>>>>>> the MyString object with a simple stack allocated char array.
>>>>>>
>>>>>> Oh and the G__tagtable_setup() function called in
>>>>>> G__cpp_setup_tagtableMyCint() (generated source..) does return
>>>>>> the correct number for sizeof(MyString).
>>>>>>
>>>>>> My thanks in advance!
>>>>>>
>>>>>> cheers,
>>>>>> severin
>>>>>>
>>>>>> ps.: I hope this was more or less understandable but don't
>>>>>> hesitate to ask in case you need some more information.

[Axel Naumann]

Hi Severin,

 > oh, well in that case nope. I'm already running debug builds with all
 > optimizations disabled.

let me be a bit more precise: it's the bytecode optimizer that you can
turn off by calling .O0 on the CINT prompt, or programatically by
calling G__calc(".O") or
    G__asm_loopcompile = 0;
    G__asm_loopcompile_mode = 0;

Cheers, Axel.

Severin Ecker wrote:

>
>
> Axel Naumann wrote:
>> Hi Severin,
>>
>> Severin Ecker wrote:
>>> Hi Axel,
>>>
>>>  > does .O0 (dot-oh-zero) help?
>>>
>>> erm, I'm sorry you lost me there. do you mean if disabling the
>>> optimizations help or something else?
>>
>> yes :-) That's set interactively with ".O0".
>>
>> Cheers, Axel.
>>
>>
>>>
>>>
>>>> Cheers, Axel.
>>>>
>>>> Severin Ecker wrote:
>>>>> Hi Axel,
>>>>>
>>>>> Header used to generate my cint interpreter (inclusion guards etc
>>>>> removed for brevity)
>>>>>
>>>>> #include <string>
>>>>>
>>>>> struct Str
>>>>> {
>>>>>    Str(const char *);
>>>>>    ~Str();
>>>>>      int dummyInt;
>>>>>    std::string stringMember;
>>>>> };
>>>>>
>>>>>
>>>>> (accompanying cpp-file added to my interpreter executable
>>>>>  Str::Str(const char* str) : stringMember(str) {}
>>>>>  Str::~Str() {}
>>>>> )
>>>>>
>>>>>
>>>>> and here's the testscript:
>>>>>
>>>>> void fB(unsigned int i, float val)
>>>>> {
>>>>>    Str msg = "i. Our intermediate value. loop runs to go\n";
>>>>> }
>>>>>
>>>>> float fA(float x)
>>>>> {
>>>>>    unsigned int i;
>>>>>    for (i = 0; i < 2; ++i)
>>>>>    {
>>>>>        fB(1, 1.0);
>>>>>    }
>>>>>    Str hmpf = "sdflskjblsiugslfuslidfusldifu";
>>>>> }
>>>>>
>>>>>
>>>>> And here's the oddest thing.
>>>>> - Remove the for loop and it works (even if you call the function x
>>>>> times sequentially)
>>>>> - Change the parameter list of fB() and it behaves differently (on
>>>>> my machine and system: winxp, vs2005)
>>>>>      void fB(unsigned int i, float val):   msvc debug error: stack
>>>>> curruption around 'localbuf'
>>>>>      void fB(unsigned int i, float val, unsigned int param):   same
>>>>> as above
>>>>>      void fB(unsigned int i, float val, unsigned int param,
>>>>> unsigned int param2): does corrupt the stack but only 'locally' which
>>>>>                                 the application can bail out
>>>>> without crash
>>>>>
>>>>> as mentioned before this is (among possible other problems) due to
>>>>> a wrong G__globalvarpointer which doesn't leave enough room for the
>>>>> object to be created on the stack.
>>>>>
>>>>> oh and I'm using cint5. (and STLPORT so i might need a few tweaks
>>>>> to crash with the native STL)
>>>>>
>>>>> cheers,
>>>>> severin
>>>>>
>>>>>
>>>>> Axel Naumann wrote:
>>>>>> Hi Severin,
>>>>>>
>>>>>> any chance that you could send us a three-liner demonstrating the
>>>>>> issue?
>>>>>>
>>>>>> Cheers, Axel.
>>>>>>
>>>>>> Severin Ecker wrote:
>>>>>>> Hi again,
>>>>>>>
>>>>>>> I'm facing a pretty nasty problem right now so i was wondering if
>>>>>>> you could point me to the correct code location and save me some
>>>>>>> debugging time.
>>>>>>>
>>>>>>> I have a user defined type (MyString) compiled into my
>>>>>>> cint-interpreter (it's a class containing an int and a
>>>>>>> std::string). within my script i have 2 functions fA() and fB().
>>>>>>> fA() calls fB() and fB() does nothing else than creating a
>>>>>>> MyString object on the stack and destroying it again. But here's
>>>>>>> the problem.
>>>>>>> My type has sizeof(MyString) == 28, so there must be at least 28
>>>>>>> bytes of 'stack space' for fB();
>>>>>>> The G__getgvp() function though (called in the generated function
>>>>>>> for my MyString class the one using the placement new) returns a
>>>>>>> pointer which is only 14 bytes, before a memory location which is
>>>>>>> actually used elsewhere and doesn't belong to the stack location
>>>>>>> of fB().. therefore overwriting memory which (depending on what's
>>>>>>> overwritten) results in a crash.
>>>>>>>
>>>>>>> So, my question ultimately is: can you tell me where the
>>>>>>> G__globalvarpointer (returned from G__getgvp()) is calculated for
>>>>>>> an interpreted function? I suppose there's something bogus since
>>>>>>> it all works perfectly well within correct bounds when i replace
>>>>>>> the MyString object with a simple stack allocated char array.
>>>>>>>
>>>>>>> Oh and the G__tagtable_setup() function called in
>>>>>>> G__cpp_setup_tagtableMyCint() (generated source..) does return
>>>>>>> the correct number for sizeof(MyString).
>>>>>>>
>>>>>>> My thanks in advance!
>>>>>>>
>>>>>>> cheers,
>>>>>>> severin
>>>>>>>
>>>>>>> ps.: I hope this was more or less understandable but don't
>>>>>>> hesitate to ask in case you need some more information.
>

[Severin Ecker-2]

Hi Axel,

ahhh, now i got it.
Alright, well this seems fix the issue (at least i haven't had any
crashes with my tests). What I got out of the discussion a few days ago
I suppose that you will not tackle the issue, but could you perhaps give
me some hints of where (as in file or function(s)) the problem might be,
since performance is no unbearable. My script, which took about 2
seconds before, needs 195 seconds with optimizations off, so I'll have
to fix the issue.
Once again, my thanks in advance!

cheers,
severin


Axel Naumann wrote:

> Hi Severin,
>
> > oh, well in that case nope. I'm already running debug builds with all
> > optimizations disabled.
>
> let me be a bit more precise: it's the bytecode optimizer that you can
> turn off by calling .O0 on the CINT prompt, or programatically by
> calling G__calc(".O") or
>    G__asm_loopcompile = 0;
>    G__asm_loopcompile_mode = 0;
>
> Cheers, Axel.
>
> Severin Ecker wrote:
>>
>>
>> Axel Naumann wrote:
>>> Hi Severin,
>>>
>>> Severin Ecker wrote:
>>>> Hi Axel,
>>>>
>>>>  > does .O0 (dot-oh-zero) help?
>>>>
>>>> erm, I'm sorry you lost me there. do you mean if disabling the
>>>> optimizations help or something else?
>>>
>>> yes :-) That's set interactively with ".O0".
>>>
>>> Cheers, Axel.
>>>
>>>
>>>>
>>>>
>>>>> Cheers, Axel.
>>>>>
>>>>> Severin Ecker wrote:
>>>>>> Hi Axel,
>>>>>>
>>>>>> Header used to generate my cint interpreter (inclusion guards etc
>>>>>> removed for brevity)
>>>>>>
>>>>>> #include <string>
>>>>>>
>>>>>> struct Str
>>>>>> {
>>>>>>    Str(const char *);
>>>>>>    ~Str();
>>>>>>      int dummyInt;
>>>>>>    std::string stringMember;
>>>>>> };
>>>>>>
>>>>>>
>>>>>> (accompanying cpp-file added to my interpreter executable
>>>>>>  Str::Str(const char* str) : stringMember(str) {}
>>>>>>  Str::~Str() {}
>>>>>> )
>>>>>>
>>>>>>
>>>>>> and here's the testscript:
>>>>>>
>>>>>> void fB(unsigned int i, float val)
>>>>>> {
>>>>>>    Str msg = "i. Our intermediate value. loop runs to go\n";
>>>>>> }
>>>>>>
>>>>>> float fA(float x)
>>>>>> {
>>>>>>    unsigned int i;
>>>>>>    for (i = 0; i < 2; ++i)
>>>>>>    {
>>>>>>        fB(1, 1.0);
>>>>>>    }
>>>>>>    Str hmpf = "sdflskjblsiugslfuslidfusldifu";
>>>>>> }
>>>>>>
>>>>>>
>>>>>> And here's the oddest thing.
>>>>>> - Remove the for loop and it works (even if you call the function
>>>>>> x times sequentially)
>>>>>> - Change the parameter list of fB() and it behaves differently
>>>>>> (on my machine and system: winxp, vs2005)
>>>>>>      void fB(unsigned int i, float val):   msvc debug error:
>>>>>> stack curruption around 'localbuf'
>>>>>>      void fB(unsigned int i, float val, unsigned int param):  
>>>>>> same as above
>>>>>>      void fB(unsigned int i, float val, unsigned int param,
>>>>>> unsigned int param2): does corrupt the stack but only 'locally'
>>>>>> which
>>>>>>                                 the application can bail out
>>>>>> without crash
>>>>>>
>>>>>> as mentioned before this is (among possible other problems) due
>>>>>> to a wrong G__globalvarpointer which doesn't leave enough room
>>>>>> for the object to be created on the stack.
>>>>>>
>>>>>> oh and I'm using cint5. (and STLPORT so i might need a few tweaks
>>>>>> to crash with the native STL)
>>>>>>
>>>>>> cheers,
>>>>>> severin
>>>>>>
>>>>>>
>>>>>> Axel Naumann wrote:
>>>>>>> Hi Severin,
>>>>>>>
>>>>>>> any chance that you could send us a three-liner demonstrating
>>>>>>> the issue?
>>>>>>>
>>>>>>> Cheers, Axel.
>>>>>>>
>>>>>>> Severin Ecker wrote:
>>>>>>>> Hi again,
>>>>>>>>
>>>>>>>> I'm facing a pretty nasty problem right now so i was wondering
>>>>>>>> if you could point me to the correct code location and save me
>>>>>>>> some debugging time.
>>>>>>>>
>>>>>>>> I have a user defined type (MyString) compiled into my
>>>>>>>> cint-interpreter (it's a class containing an int and a
>>>>>>>> std::string). within my script i have 2 functions fA() and fB().
>>>>>>>> fA() calls fB() and fB() does nothing else than creating a
>>>>>>>> MyString object on the stack and destroying it again. But
>>>>>>>> here's the problem.
>>>>>>>> My type has sizeof(MyString) == 28, so there must be at least
>>>>>>>> 28 bytes of 'stack space' for fB();
>>>>>>>> The G__getgvp() function though (called in the generated
>>>>>>>> function for my MyString class the one using the placement new)
>>>>>>>> returns a pointer which is only 14 bytes, before a memory
>>>>>>>> location which is actually used elsewhere and doesn't belong to
>>>>>>>> the stack location of fB().. therefore overwriting memory which
>>>>>>>> (depending on what's overwritten) results in a crash.
>>>>>>>>
>>>>>>>> So, my question ultimately is: can you tell me where the
>>>>>>>> G__globalvarpointer (returned from G__getgvp()) is calculated
>>>>>>>> for an interpreted function? I suppose there's something bogus
>>>>>>>> since it all works perfectly well within correct bounds when i
>>>>>>>> replace the MyString object with a simple stack allocated char
>>>>>>>> array.
>>>>>>>>
>>>>>>>> Oh and the G__tagtable_setup() function called in
>>>>>>>> G__cpp_setup_tagtableMyCint() (generated source..) does return
>>>>>>>> the correct number for sizeof(MyString).
>>>>>>>>
>>>>>>>> My thanks in advance!
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> severin
>>>>>>>>
>>>>>>>> ps.: I hope this was more or less understandable but don't
>>>>>>>> hesitate to ask in case you need some more information.

[Severin Ecker-2]

Hi again Axel,

I've attached a textfile which contains the cint output (with the
G__asm_dbg flag enabled). Perhaps it helps you track down the error.
Since I'm not familiar with the bytecode and everything it would be a
rather cumbersome experience for me to find the problem. (Has this issue
come up yet and was probably fixed in cint7 so i can match-steal some code?)

cheers,
severin


Axel Naumann wrote:

> Hi Severin,
>
> > oh, well in that case nope. I'm already running debug builds with all
> > optimizations disabled.
>
> let me be a bit more precise: it's the bytecode optimizer that you can
> turn off by calling .O0 on the CINT prompt, or programatically by
> calling G__calc(".O") or
>    G__asm_loopcompile = 0;
>    G__asm_loopcompile_mode = 0;
>
> Cheers, Axel.
>
> Severin Ecker wrote:
>>
>>
>> Axel Naumann wrote:
>>> Hi Severin,
>>>
>>> Severin Ecker wrote:
>>>> Hi Axel,
>>>>
>>>>  > does .O0 (dot-oh-zero) help?
>>>>
>>>> erm, I'm sorry you lost me there. do you mean if disabling the
>>>> optimizations help or something else?
>>>
>>> yes :-) That's set interactively with ".O0".
>>>
>>> Cheers, Axel.
>>>
>>>
>>>>
>>>>
>>>>> Cheers, Axel.
>>>>>
>>>>> Severin Ecker wrote:
>>>>>> Hi Axel,
>>>>>>
>>>>>> Header used to generate my cint interpreter (inclusion guards etc
>>>>>> removed for brevity)
>>>>>>
>>>>>> #include <string>
>>>>>>
>>>>>> struct Str
>>>>>> {
>>>>>>    Str(const char *);
>>>>>>    ~Str();
>>>>>>      int dummyInt;
>>>>>>    std::string stringMember;
>>>>>> };
>>>>>>
>>>>>>
>>>>>> (accompanying cpp-file added to my interpreter executable
>>>>>>  Str::Str(const char* str) : stringMember(str) {}
>>>>>>  Str::~Str() {}
>>>>>> )
>>>>>>
>>>>>>
>>>>>> and here's the testscript:
>>>>>>
>>>>>> void fB(unsigned int i, float val)
>>>>>> {
>>>>>>    Str msg = "i. Our intermediate value. loop runs to go\n";
>>>>>> }
>>>>>>
>>>>>> float fA(float x)
>>>>>> {
>>>>>>    unsigned int i;
>>>>>>    for (i = 0; i < 2; ++i)
>>>>>>    {
>>>>>>        fB(1, 1.0);
>>>>>>    }
>>>>>>    Str hmpf = "sdflskjblsiugslfuslidfusldifu";
>>>>>> }
>>>>>>
>>>>>>
>>>>>> And here's the oddest thing.
>>>>>> - Remove the for loop and it works (even if you call the function
>>>>>> x times sequentially)
>>>>>> - Change the parameter list of fB() and it behaves differently
>>>>>> (on my machine and system: winxp, vs2005)
>>>>>>      void fB(unsigned int i, float val):   msvc debug error:
>>>>>> stack curruption around 'localbuf'
>>>>>>      void fB(unsigned int i, float val, unsigned int param):  
>>>>>> same as above
>>>>>>      void fB(unsigned int i, float val, unsigned int param,
>>>>>> unsigned int param2): does corrupt the stack but only 'locally'
>>>>>> which
>>>>>>                                 the application can bail out
>>>>>> without crash
>>>>>>
>>>>>> as mentioned before this is (among possible other problems) due
>>>>>> to a wrong G__globalvarpointer which doesn't leave enough room
>>>>>> for the object to be created on the stack.
>>>>>>
>>>>>> oh and I'm using cint5. (and STLPORT so i might need a few tweaks
>>>>>> to crash with the native STL)
>>>>>>
>>>>>> cheers,
>>>>>> severin
>>>>>>
>>>>>>
>>>>>> Axel Naumann wrote:
>>>>>>> Hi Severin,
>>>>>>>
>>>>>>> any chance that you could send us a three-liner demonstrating
>>>>>>> the issue?
>>>>>>>
>>>>>>> Cheers, Axel.
>>>>>>>
>>>>>>> Severin Ecker wrote:
>>>>>>>> Hi again,
>>>>>>>>
>>>>>>>> I'm facing a pretty nasty problem right now so i was wondering
>>>>>>>> if you could point me to the correct code location and save me
>>>>>>>> some debugging time.
>>>>>>>>
>>>>>>>> I have a user defined type (MyString) compiled into my
>>>>>>>> cint-interpreter (it's a class containing an int and a
>>>>>>>> std::string). within my script i have 2 functions fA() and fB().
>>>>>>>> fA() calls fB() and fB() does nothing else than creating a
>>>>>>>> MyString object on the stack and destroying it again. But
>>>>>>>> here's the problem.
>>>>>>>> My type has sizeof(MyString) == 28, so there must be at least
>>>>>>>> 28 bytes of 'stack space' for fB();
>>>>>>>> The G__getgvp() function though (called in the generated
>>>>>>>> function for my MyString class the one using the placement new)
>>>>>>>> returns a pointer which is only 14 bytes, before a memory
>>>>>>>> location which is actually used elsewhere and doesn't belong to
>>>>>>>> the stack location of fB().. therefore overwriting memory which
>>>>>>>> (depending on what's overwritten) results in a crash.
>>>>>>>>
>>>>>>>> So, my question ultimately is: can you tell me where the
>>>>>>>> G__globalvarpointer (returned from G__getgvp()) is calculated
>>>>>>>> for an interpreted function? I suppose there's something bogus
>>>>>>>> since it all works perfectly well within correct bounds when i
>>>>>>>> replace the MyString object with a simple stack allocated char
>>>>>>>> array.
>>>>>>>>
>>>>>>>> Oh and the G__tagtable_setup() function called in
>>>>>>>> G__cpp_setup_tagtableMyCint() (generated source..) does return
>>>>>>>> the correct number for sizeof(MyString).
>>>>>>>>
>>>>>>>> My thanks in advance!
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> severin
>>>>>>>>
>>>>>>>> ps.: I hope this was more or less understandable but don't
>>>>>>>> hesitate to ask in case you need some more information.

Loop compile start (for a for or while).  Erasing old bytecode and resetting pc. Source/testscript.cpp(44)
  0, ff: LD_VAR item: 'i' index: 0 paran: 0 type: 'p' var: 01882cd8   x:\cint\source\cint\src\var.cxx:5666
  5, ff: LD 2  x:\cint\source\cint\src\expr.cxx:1812
  7, fe: OP2 '<' (60) 60  x:\cint\source\cint\src\opr.cxx:323
  9, fe: CNDJMP (for or while, assigned later)  x:\cint\source\cint\src\parse.cxx:2895
  b, fe: CL ./Source/testscript.cpp:44  x:\cint\source\cint\src\pcode.cxx:2558
  d, fe: CL ./Source/testscript.cpp:46  x:\cint\source\cint\src\pcode.cxx:2558
  f, fe: LD 1  x:\cint\source\cint\src\expr.cxx:1812
 11, fd: LD 1  x:\cint\source\cint\src\expr.cxx:1812
 13, fc: LD 1  x:\cint\source\cint\src\expr.cxx:1812
 15, fb: LD 1  x:\cint\source\cint\src\expr.cxx:1812
 17: LD_IFUNC test paran=4
G__compile_bytecode: begin bytecode compilation ...
G__compile_bytecode: calling G__interpret_func ...
!!!bytecode compilation of 'test' started at  Source/testscript.cpp(46)
  0, ff: ST_LVAR item: 'i' index: 0 paran: 0 type: 'p' var: 01883610  x:\cint\source\cint\src\var.cxx:4837
  5, ff: POP  x:\cint\source\cint\src\var.cxx:4133
  6, ff: ST_LVAR item: 'val' index: 0 paran: 0 type: 'p' var: 01883700  x:\cint\source\cint\src\var.cxx:4837
  b, ff: POP  x:\cint\source\cint\src\var.cxx:4133
  c, ff: ST_LVAR item: 'maxloop' index: 0 paran: 0 type: 'p' var: 018837f0  x:\cint\source\cint\src\var.cxx:4837
 11, ff: POP  x:\cint\source\cint\src\var.cxx:4133
 12, ff: ST_LVAR item: 'modme' index: 0 paran: 0 type: 'p' var: 018838e0  x:\cint\source\cint\src\var.cxx:4837
 17, ff: POP  x:\cint\source\cint\src\var.cxx:4133
 18: SETMEMFUNCENV
 19, ff: LD 25706040  x:\cint\source\cint\src\quote.cxx:35
 1b: RECMEMFUNCENV
Note: Bytecode compiler suspended. Source/testscript.cpp(32)
 1c: LD_FUNC C++ compiled Str paran=1
 1c, fe: CTOR_SETGVP msg index=0 paran=0  x:\cint\source\cint\src\var.cxx:4160
 27, fe: PUSHSTROS  x:\cint\source\cint\src\var.cxx:4171
 28, fe: SETSTROS  x:\cint\source\cint\src\var.cxx:4178
 29: SETGVP -1
 2b, fe: POPSTROS  x:\cint\source\cint\src\decl.cxx:3303
 2c, fe: CL ./Source/testscript.cpp:32  x:\cint\source\cint\src\pcode.cxx:2558
2e : RTN_FUNC
Bytecode compilation of test successful Source/testscript.cpp(33)
Optimize 3 start
  0: ST_LVAR index=0 paran=0 point p i
  G__ST_VAR optimized 8 G__LDST_LVAR_P
  5: POP
  6: ST_LVAR index=0 paran=0 point p val
  G__ST_VAR optimized 8 G__LDST_LVAR_P
  b: POP
  c: ST_LVAR index=0 paran=0 point p maxloop
  G__ST_VAR optimized 8 G__LDST_LVAR_P
 11: POP
 12: ST_LVAR index=0 paran=0 point p modme
  G__ST_VAR optimized 8 G__LDST_LVAR_P
 17: POP
 18: SETMEMFUNCENV
 19: LD 25706040 from ff  x:\cint\source\cint\src\pcode.cxx:4773
 1b: RECMEMFUNCENV
 1c: CTOR_SETGVP
 20: LD_FUNC 'compiled' paran: 1  x:\cint\source\cint\src\pcode.cxx:5138
 27: PUSHSTROS
 28: SETSTROS
 29: SETGVP
 2b: POPSTROS
 2c: CL ./Source/testscript.cpp:32  x:\cint\source\cint\src\pcode.cxx:4790
 2e: RTN_FUNC 0
 30: RETURN
Note: Bytecode compiler reset. Source/testscript.cpp(33)
G__compile_bytecode: finished G__interpret_func.
G__compile_bytecode: success.
G__compile_bytecode: end bytecode compilation.
G__exec_bytecode: starting bytecode execution ...
Running bytecode function test inst=187a3a0->18aa558 stack=187e520->10ae98
G__exec_asm: begin asm execution ...
  0,  4: LDST_LVAR_P index: 0 ldst: 1 'i' val: 1 (4.94066e-324)
  5,4: POP 1 -> 1
  6,  3: LDST_LVAR_P index: 0 ldst: 1 'val' val: 0 (1)
  b,3: POP 1 -> 1
  c,  2: LDST_LVAR_P index: 0 ldst: 1 'maxloop' val: 1 (4.94066e-324)
 11,2: POP 1 -> 1
 12,  1: LDST_LVAR_P index: 0 ldst: 1 'modme' val: 1 (4.94066e-324)
 17,1: POP 1 -> -8.58993e+008
 18,0: SETMEMFUNCENV 0 <- 0 0
 19,  0: LD 25706040(2.5706e+007) from data stack index ff
 1b,1: RECMEMFUNCENV 0 <- 104d30 0
 1c,1: CTOR_SETGVP 0010ADD0
 20,  1: LD_FUNC 'compiled' paran: 1  x:\cint\source\cint\src\bc_exec_asm.h:585
       : para[0]: (char*)0x1883e38  x:\cint\source\cint\src\bc_exec_asm.h:613
 27,1: PUSHSTROS 0x0 strosp=0
 28,1: SETSTROS 0x10add0
 29,0: SETGVP -1 1
 2b,0: POPSTROS 0x0 strosp=1
 2c,  0: CL ./Source/testscript.cpp:32  x:\cint\source\cint\src\bc_exec_asm.h:363
 2e,0: RTN_FUNC 0
G__exec_asm: end asm execution.
returns NULL
Exit bytecode function test restore inst=187a3a0 stack=187e520
G__exec_bytecode: end bytecode execution ...
 20, fa: LD_VAR item: 'i' index: 0 paran: 0 type: 'p' var: 01882cd8   x:\cint\source\cint\src\var.cxx:5666
 25, fa: OP1 ++var 14  x:\cint\source\cint\src\opr.cxx:301
 27, fa: JMP 0 (for or while, jump to begin of loop body) x:\cint\source\cint\src\parse.cxx:3107
Optimize 3 start
  0: LD_VAR index=0 paran=0 point p i
        G__LD_VAR optimized 6 to G__LDST_VAR_P
  5: LD 2 from ff  x:\cint\source\cint\src\pcode.cxx:4773
  7: OP2 '<'60
  9: CNDJMP to 29
  b: CL ./Source/testscript.cpp:44  x:\cint\source\cint\src\pcode.cxx:4790
  d: CL ./Source/testscript.cpp:46  x:\cint\source\cint\src\pcode.cxx:4790
  f: LD 1 from fe  x:\cint\source\cint\src\pcode.cxx:4773
 11: LD 1 from fd  x:\cint\source\cint\src\pcode.cxx:4773
 13: LD 1 from fc  x:\cint\source\cint\src\pcode.cxx:4773
 15: LD 1 from fb  x:\cint\source\cint\src\pcode.cxx:4773
 17: LD_IFUNC test paran=4
 1f: NOP
 20: LD_VAR index=0 paran=0 point p i
        G__LD_VAR optimized 6 to G__LDST_VAR_P
 25: OP1 14
 27: JMP 0
 29: RETURN

Bytecode loop compilation successful. (for for or while) Source/testscript.cpp(47)
G__exec_asm: begin asm execution ...
  0,0: LDST_VAR_P index=0 ldst=0 i -> 1 104 -1
  5,  1: LD 2(2) from data stack index ff
  7,2: OP2_OPTIMIZED h:1 i:2 -> i:1
  9,  1: CNDJMP 1 to 29
  b,  0: CL ./Source/testscript.cpp:44  x:\cint\source\cint\src\bc_exec_asm.h:363
  d,  0: CL ./Source/testscript.cpp:46  x:\cint\source\cint\src\bc_exec_asm.h:363
  f,  0: LD 1(1) from data stack index fe
 11,  1: LD 1(1) from data stack index fd
 13,  2: LD 1(1) from data stack index fc
 15,  3: LD 1(1) from data stack index fb
 17,  4: LD_IFUNC 'test' paran: 4  x:\cint\source\cint\src\bc_exec_asm.h:1452
call G__exec_bytecode optimized  x:\cint\source\cint\src\bc_exec_asm.h:1468
 17,  4: LD_FUNC 'øX‡
' paran: 4  x:\cint\source\cint\src\bc_exec_asm.h:588
       : para[0]: (int)1  x:\cint\source\cint\src\bc_exec_asm.h:613
       : para[1]: (double)1.00000000000000000e+000  x:\cint\source\cint\src\bc_exec_asm.h:613
       : para[2]: (int)1  x:\cint\source\cint\src\bc_exec_asm.h:613
       : para[3]: (int)1  x:\cint\source\cint\src\bc_exec_asm.h:613
G__exec_bytecode: starting bytecode execution ...
Running bytecode function test inst=187a3a0->18aa558 stack=187e520->1144e4
G__exec_asm: begin asm execution ...
  0,  4: LDST_LVAR_P index: 0 ldst: 1 'i' val: 1 (4.94066e-324)
  5,4: POP 1 -> 1
  6,  3: LDST_LVAR_P index: 0 ldst: 1 'val' val: 0 (1)
  b,3: POP 1 -> 1
  c,  2: LDST_LVAR_P index: 0 ldst: 1 'maxloop' val: 1 (4.94066e-324)
 11,2: POP 1 -> 1
 12,  1: LDST_LVAR_P index: 0 ldst: 1 'modme' val: 1 (4.94066e-324)
 17,1: POP 1 -> -8.58993e+008
 18,0: SETMEMFUNCENV 0 <- 0 0
 19,  0: LD 25706040(2.5706e+007) from data stack index ff
 1b,1: RECMEMFUNCENV 0 <- 10e37c 0
 1c,1: CTOR_SETGVP 0011441C
 20,  1: LD_FUNC 'compiled' paran: 1  x:\cint\source\cint\src\bc_exec_asm.h:585
       : para[0]: (char*)0x1883e38  x:\cint\source\cint\src\bc_exec_asm.h:613
 27,1: PUSHSTROS 0x0 strosp=0
 28,1: SETSTROS 0x11441c
 29,0: SETGVP -1 1
 2b,0: POPSTROS 0x0 strosp=1
 2c,  0: CL ./Source/testscript.cpp:32  x:\cint\source\cint\src\bc_exec_asm.h:363
 2e,0: RTN_FUNC 0
G__exec_asm: end asm execution.
returns NULL
Exit bytecode function test restore inst=187a3a0 stack=187e520
G__exec_bytecode: end bytecode execution ...
 1e,0: JMP 20
 20,0: LDST_VAR_P index=0 ldst=0 i -> 1 104 -1
 25,1: OP1_OPTIMIZED h:1 -> h:2
 27,1: JMP 0
  0,1: LDST_VAR_P index=0 ldst=0 i -> 2 104 -1
  5,  2: LD 2(2) from data stack index ff
  7,3: OP2_OPTIMIZED h:2 i:2 -> i:0
  9,  2: CNDJMP 0 to 29
 29,1: RETURN
G__exec_asm: end asm execution.

freetemp 0:(NULL)0x00000000

[Severin Ecker-2]

Hi,

I'm interpreting a script file of mine (using G__calc). now my problem
is that function style macros don't work in assignments... e.g.:

#define TEST(x)  #x

void func(void)
{
   TEST(hallo); //[1]
   const char* str = TEST(hallo); //[2]
}

[1] this works because 'normal' parsing checks for functions style
macros when it encounters a '(' character (parse.cxx, ~6740)
[2] this does not work because the code that constructs the local
variable checks for functions but not for functions style macros
(expr.cxx, ~1896)

I know that there's a cmdline switch to preprocess a file if i want to
generate some interpreter sources. But what I need is an in-code
preprocessing of a script file. Is something like this possible?

thanks.
cheers,
severin

[Axel Naumann]

Hi Severin,

 > I know that there's a cmdline switch to preprocess a file if i want to
 > generate some interpreter sources. But what I need is an in-code
 > preprocessing of a script file. Is something like this possible?

It's not currently available, so either way this will need to be changed
in CINT itself. You could pick up the current line from the preprocessor
by taking the line number of the current file and jumping to the same
line in the preprocessed file (but again: to be implemented). Or we add
the check for function style macros. The latter would of course be of
more general use. Can you help with that (for either CINT; we'll migrate
it to the other version)?

Cheers, Axel.

Severin Ecker wrote on 04/07/2009 01:56 PM:

> Hi,
>
> I'm interpreting a script file of mine (using G__calc). now my problem
> is that function style macros don't work in assignments... e.g.:
>
> #define TEST(x)  #x
>
> void func(void)
> {
>   TEST(hallo); //[1]
>   const char* str = TEST(hallo); //[2]
> }
>
> [1] this works because 'normal' parsing checks for functions style
> macros when it encounters a '(' character (parse.cxx, ~6740)
> [2] this does not work because the code that constructs the local
> variable checks for functions but not for functions style macros
> (expr.cxx, ~1896)
>
> I know that there's a cmdline switch to preprocess a file if i want to
> generate some interpreter sources. But what I need is an in-code
> preprocessing of a script file. Is something like this possible?
>
> thanks.
> cheers,
> severin
>
>

[Severin Ecker-2]

Hi,

consider the following script:

namespace myns {
    enum asdf { a1, a2, a3 };
    asdf nsGlobVar;
};

myns::asdf globVar;

class Test
{
public:
   void Func(void)
   {
        globVar = myns::a2;     // [1]
        myns::nsGlobVar = myns::a2;    // [1]
   }
};

calling Test::Func(); results in an access violation (at least on my
system, clearly it depends on the concrete memory location which be
written to).

[1] works perfectly well and correct
[2] yields in an access violation (basically var.cxx G__letvariable ~ 1500)
       G__ASSIGN_VAR(G__INTALLOC, int, G__int, result.obj.i);
       first the offset for the target variable is calculated
(result.ref = G__struct_offset + var->p[ig15] + (linear_index *
G__INTALLOC);) which is then dereferenced. now, in the case of a global
variable G__struct_offset is 0, but as soon as it's a member of a
namespace G__struct_offset seems to become some weird offset value from
within the class' internal member-var location, which, in the case above
is bogus since myns::nsGlobVar is still a global variable and not a member.

note: accessing a global variable that's located inside a namespace from
within a free function (instead of a member function) works like a charm
as well.

any chance that you can reproduce this, and help me figure out a
solution? or is this known to be unsupported?

thanks and cheers,
severin

ps.: i have both, support for the stringify operator (#) and function
macro support in assignments implemented here and it seems to work for
the test cases I have. I'll try to send you a patch as soon as I find
time to put one together.

[Philippe Canal]

 > ps.: i have both, support for the stringify operator (#) and function
macro support in assignments implemented here
 > and it seems to work for the test cases I have. I'll try to send you
a patch as soon as I find time to put one together.

Please do :).

 > calling Test::Func(); results in an access violation (at least on my
system, clearly it depends on the concrete
 > memory location which be written to).

I can indeed reproduce this problem.

There is an unfortunate ambiguity in CINT between local static, global
variables and static global variable that
makes it harder than it should to fix this issue.    I noted that using

namespace myns {
   ....
   static asdf nsGlobVar;
};

'solves' the problem.    So I would start with compare the behavior in
these 2 cases (with and without the 'static')

Cheers,
Philippe.


Severin Ecker wrote:

> Hi,
>
> consider the following script:
>
> namespace myns {
>    enum asdf { a1, a2, a3 };
>    asdf nsGlobVar;
> };
>
> myns::asdf globVar;
>
> class Test
> {
> public:
>   void Func(void)
>   {
>        globVar = myns::a2;     // [1]
>        myns::nsGlobVar = myns::a2;    // [1]
>   }
> };
>
> calling Test::Func(); results in an access violation (at least on my
> system, clearly it depends on the concrete memory location which be
> written to).
>
> [1] works perfectly well and correct
> [2] yields in an access violation (basically var.cxx G__letvariable ~
> 1500)
>       G__ASSIGN_VAR(G__INTALLOC, int, G__int, result.obj.i);
>       first the offset for the target variable is calculated
> (result.ref = G__struct_offset + var->p[ig15] + (linear_index *
> G__INTALLOC);) which is then dereferenced. now, in the case of a
> global variable G__struct_offset is 0, but as soon as it's a member of
> a namespace G__struct_offset seems to become some weird offset value
> from within the class' internal member-var location, which, in the
> case above is bogus since myns::nsGlobVar is still a global variable
> and not a member.
>
> note: accessing a global variable that's located inside a namespace
> from within a free function (instead of a member function) works like
> a charm as well.
>
> any chance that you can reproduce this, and help me figure out a
> solution? or is this known to be unsupported?
>
> thanks and cheers,
> severin
>
> ps.: i have both, support for the stringify operator (#) and function
> macro support in assignments implemented here and it seems to work for
> the test cases I have. I'll try to send you a patch as soon as I find
> time to put one together.
>