Help! Segmentation violation while using stl

SEA · February 6, 2009, 8:42pm

CINT gives “Segmentation violation” with this code:

#include <string>

class B
{
public:
   string str;
};

void RunMe()
{
   B * arrB = new B[10];

   if( arrB )
      delete[] arrB;
}

It happens in debug build of both CINT5 and CINT7 (latest from svn feb 6, 09), built for msvc8.
It always and only happens when using any stl class in class B.
In release build of CINT it crashes on 2nd run (After 1st run file unloaded with command U), and with cint lib.
Any help appreciated please.

pcanal · February 9, 2009, 5:23pm

Hi,

You can work around the problem by adding a explicit default constructor:

class B { public: B() {} string str; };

Cheers,
Philippe.

pcanal · February 9, 2009, 5:50pm

Hi,

The underlying problem has been resolved in cint7.

Cheers,
Philippe.

SEA · February 9, 2009, 6:39pm

thank you!

hmmm, after getting updates from repository i’m getting errors:

debug.cxx cint7/src/debug.cxx(861) : error C2440: '=' : cannot convert from 'const char *' to 'char *' Conversion loses qualifiers cint7/src/debug.cxx(894) : error C2440: '=' : cannot convert from 'const char *' to 'char *' Conversion loses qualifiers cint7/src/debug.cxx(922) : error C2440: '=' : cannot convert from 'const char *' to 'char *' Conversion loses qualifiers cint7/src/debug.cxx(949) : error C2440: '=' : cannot convert from 'const char *' to 'char *' Conversion loses qualifiers make: *** [cint7/src/debug.obj] Error 2

pcanal · February 9, 2009, 6:57pm

Hi,

debug.cxx should now be fixed in the repository.

Cheers,
Philippe.

SEA · February 9, 2009, 8:01pm

thank you.

got them, there are more:

error.cxx cint7/src/error.cxx(281) : error C2440: 'initializing' : cannot convert from 'const char *' to 'char *' cint7/src/expr.cxx(46) : error C2440: 'initializing' : cannot convert from 'const char *' to 'char *' cint7/src/expr.cxx(187) : error C2440: 'initializing' : cannot convert from 'const char *' to 'char *' cint7/src/func.cxx(1920) : error C2440: '=' : cannot convert from 'const char *' to 'char *' cint7/src/func.cxx(3337) : error C2440: '=' : cannot convert from 'const char *' to 'char *'

SEA · February 9, 2009, 8:09pm

Also there were lots of warnings, not the FIXME ones:

[code]tool/rmkdepend//mainroot.cxx(40) : warning C4273: ‘unlink’ : inconsistent dll linkage
E:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\stdio.h(290)

sunos.obj : warning LNK4221: no public symbols found; archive member will be inaccessible
oldlink.obj : warning LNK4221: no public symbols found; archive member will be inaccessible
newsos.obj : warning LNK4221: no public symbols found; archive member will be inaccessible
bc_eh.obj : warning LNK4221: no public symbols found; archive member will be inaccessible
[/code]
and lots, ~49 warnings like these:

Warning: #pragma link, function log(valarray<int>) not found prec_stl/valarray(261) Warning: #pragma link, function log10(valarray<int>) not found prec_stl/valarray(262) Warning: #pragma link, function pow(valarray<int>,valarray<int>) not found prec_stl/valarray(263)

pcanal · February 10, 2009, 6:23pm

Hi,

All those warnings should be ‘harmless’ and the build should now work correctly (we will attempt to remove those warnings).

Cheers,
Philippe

SEA · February 10, 2009, 7:15pm

thank you.

What about those errors?
There are more const char * conversions errors - Pls take a look at another my message right above one with warnings question: http://root.cern.ch/phpBB2/viewtopic.php?p=33686#33686

pcanal · February 10, 2009, 7:19pm

Hi,

The const char* conversion are now fixed in the svn repository.
The “no public symbols found” are also fixed.

Cheers,
Philippe

pcanal · February 11, 2009, 4:15pm

Hi,

The vc8 and vc9 should now work smoothly (there will still be some minor warning about valarray). Let me know if you have any problems.

Thanks,
Philippe.

SEA · February 11, 2009, 4:45pm

Thanks
Unfortunately CINT still crashes on second run of this code: http://root.cern.ch/phpBB2/viewtopic.php?p=33706#33706

Second run means:
X C:\CINT\failtest\RunMe.cxx
U C:\CINT\failtest\RunMe.cxx
X C:\CINT\failtest\RunMe.cxx
Error: Illegal assignment to G__STRING c:\cint\cint7\stl_string(12)
!!!Error recovered!!!

and i have more complicated code that crashes at first run, but generally it similar to this

pcanal · February 11, 2009, 4:49pm

Hi,

You can work around this problem by doing:cint.exe> { #include <string> } cint.exe> X RunMe.cxx

Cheers,
Philippe.

SEA · February 11, 2009, 5:03pm

Is there similar workaround for lib cint ?

pcanal · February 11, 2009, 5:06pm

What do you mean (‘lib cint’)?

Cheers,
Philippe

SEA · February 11, 2009, 5:10pm

I use CINT as dll built with some additional callbacks to load by my program.

pcanal · February 11, 2009, 5:18pm

Hi,

I am not sure what mechanism you are using .

Anyway, the point of the working around is to load all the ‘infrastructure’ library before loading the (user) scripts that will be reloaded. A script reload (or unload) imply the unloading of all script, includes and library that have been loaded since.

Cheers,
Philippe.

SEA · February 11, 2009, 5:40pm

Thank you, Philippe

I will give a try.
So, generally right after loading my dll with embedded CINT i should do something like:

Is there a way to add those to dictionary while building that dll?

BTW, though you wrote in other topic in “cint bugs and features” that this bug is fixed, i still have to use that workaround even with latest CINT7 built with msvc9

pcanal · February 11, 2009, 5:44pm

[quote]BTW, though you wrote in other topic in “cint bugs and features” that this bug is fixed, i still have to use that workaround even with latest CINT7 built with msvc9[/quote]My apologies I had mis-read your post (and did not ‘see’ the part where you mentioned that this happens in Cint7 after reloads.

pcanal · February 11, 2009, 5:46pm

[quote]So, generally right after loading my dll with embedded CINT i should do something like: [/quote]Yes

[quote]Is there a way to add those to dictionary while building that dll?[/quote]I don’t think so.

Cheers,
Philippe.