Issues with std::list

ROOT
1

Hi,
I ran into two problems with std::list, win32gdk (I remember having seen this on linux, too), current cvs.

push_back

#include <list> testmacro() { std::list<Int_t> l; l.push_back(1); }Segment violation with

~list

#include <list> testmacro() { std::list<Int_t> l; }Segment violation.
Axel.

2

Hi Axel,

Did you generate the cintdlls?

Cheers,
Philippe.

3

No. Is that a prerequisite, even when interpreting a macro? I’m a bit surprised, though - the headers for an interpreted std::list are there (even with #ifdef CINT parts) - but they don’t seem to work.

Axel.

4

Hi Axel,

The building of the cintdlls is not a pre-requisite. You should be able to work with interpreted STL classes. However their use is limited because they support less of the standard as the compiled version and, more importantly, they can not be used in conjunction with any user compiled code (which uses the same containers).

Also, I can not reproduce the problems you mention above!

Cheers,
Philippe.

5

I’ve rebuilt everything, fresh from cvs, and the problem is still there. I used configure win32gdk --build=debug. MSVC told me (when I was still compiling with the nice “check for things that should not happen at runtime” flags, /RTC*, I rebuilt with the standard flags later on) that in var.c:5527 “*result = para;” para is not initialized. After that I get the Cint “Error: illegal pointer to class object p 0x0 922 FILE:_list.h LINE:265”, and finally a access violation at var.c:3005 “G__ASSIGN_PVAR(char,G__int,result.obj.i)”.

If that doesn’t help, and if you’re still unable to confirm this, I’ll try it on another windows machine.

Axel.

6

What is the stack trace?

Philippe.

7

Hi Philippe,

> libCint.dll!G__letvariable() Line 3005 + 0x529 C libCint.dll!G__letstructmem() Line 5204 + 0x2f C libCint.dll!G__letvariable() Line 2197 + 0x42 C libCint.dll!G__getexpr() Line 1653 + 0x31 C libCint.dll!G__exec_statement() Line 4912 + 0x13 C libCint.dll!G__interpret_func() Line 7373 + 0xc C libCint.dll!G__getfunction() Line 3183 + 0x41 C libCint.dll!G__getitem() Line 2342 + 0x16 C libCint.dll!G__getexpr() Line 1707 + 0x2b C libCint.dll!G__exec_function() Line 521 + 0xd C libCint.dll!G__exec_statement() Line 4826 + 0x27 C libCint.dll!G__exec_loop() Line 3139 + 0xc C libCint.dll!G__exec_while() Line 3347 + 0x13 C libCint.dll!G__exec_statement() Line 4735 + 0xc C libCint.dll!G__interpret_func() Line 7373 + 0xc C libCint.dll!G__getfunction() Line 3183 + 0x41 C libCint.dll!G__getitem() Line 2342 + 0x16 C libCint.dll!G__getexpr() Line 1707 + 0x2b C libCint.dll!G__exec_function() Line 521 + 0xd C libCint.dll!G__exec_statement() Line 4826 + 0x27 C libCint.dll!G__interpret_func() Line 7373 + 0xc C libCint.dll!G__getfunction() Line 3183 + 0x41 C libCint.dll!G__destroy() Line 614 + 0x19 C libCint.dll!G__interpret_func() Line 7931 + 0xe C libCint.dll!G__getfunction() Line 3502 + 0x2b C libCint.dll!G__getitem() Line 2342 + 0x16 C libCint.dll!G__getexpr() Line 1707 + 0x2b C libCint.dll!G__calc_internal() Line 233 + 0xd C libCint.dll!G__process_cmd() Line 2865 + 0x13 C libCore.dll!TCint::ProcessLine(const char * line=0x103f72d8, TInterpreter::EErrorCode * error=0x00000000) Line 292 + 0x1f C++ libCore.dll!TCint::ProcessLineSynch(const char * line=0x103f72d8, TInterpreter::EErrorCode * error=0x00000000) Line 338 + 0x16 C++ libWin32gdk.dll!p2InterpreterProcessLineSynchline(void * in=0x0677b528) Line 51 + 0x2f C++ libWin32gdk.dll!TGWin32ProxyBase::ExecuteCallBack(bool sync=true) Line 248 + 0x16 C++ libWin32gdk.dll!MessageProcessingLoop(void * p=0x00000000) Line 813 C++ kernel32.dll!RegisterWaitForInputIdle() + 0x43
for the access violation. result is

[code]- result {…} G__value

  • obj {…} __unnamed
    d 5.645701968866e-316#DEN double
    i 0x06cfa048 long
  • reftype {…} G__p2p
    i 0x06cfa048 long
    reftype 0x00000000 int
    ch 0x48 ‘H’ char
    sh 0xa048 short
    in 0x06cfa048 int
    fl 7.8100258e-035 float
    uch 0x48 ‘H’ unsigned char
    ush 0xa048 unsigned short
    uin 0x06cfa048 unsigned int
    ulo 0x06cfa048 unsigned long
    type 0x00000055 int
    tagnum 0x0000039a int
    typenum 0xffffffff int
    ref 0x00000065 long
    isconst 0 char
    [/code]
    and ig15==0, thus var->reftype[ig15] == 0. G__struct_offset==101, p_inc==0. The address that cint tries to write to is 0x65==101. The expression that G__getexpr() [stack frame #4] is working on is “p->next=n”.

Axel.

8

Hello Axel,

It is almost a prerequisite to have cintdlls compiled if you use STL containers. Without them, vector container may work to some extent,
but other containers will have severe limitations.

Thank you
Masa Goto

9

Hi Axel,

Once I rebuild with the /RTC* flags, I can reproduce the problem.
In this unclear, but it seems to be related to the lifetime of temporary
and/or initialization. This crash should not happen however, we should
fix it only once we rewrote the object lifetime part of CINT.
In addition, there is a simple, more robust work around … generate the cintdlls.

Cheers,
Philippe.

10

Hi Masa, hi Philippe,
thanks, I’ll just build the dll then.
Axel.