[omniORB] String handling problem with VC7.1

[Ecker Severin]

Hi,

I'm wondering if I'm just using CORBA in an incorrect way or if there
really is an issue but whenever I try to use the following code I get an
debug assertion failure:

Code I'm trying to get to work:

CosNaming::Name var;
var.length(1);
var[0].id = (const char*)"test";


the assertion failuer happens here:
stringtypes.h

in the _CORBA_String_helper class

static inline void free(char* s) {
if (s && s != empty_string) delete[] s;
}

For some reason the condition hold true and attempts are made to delete
an invalid string resource. As you can see above I just want to assign a
string to a completely new and fresh corba object (the id string) which
does have the value 'empty_string' at the time of my assignment
statement.

Hope someone can help me!

Thanks in advance!

Best regards,
severin

[Matej Kenda]

Hi Severin,

Post by Ecker Severin
static inline void free(char* s) {
if (s && s != empty_string) delete[] s;
}
For some reason the condition hold true and attempts are made to delete
an invalid string resource. As you can see above I just want to assign a
string to a completely new and fresh corba object (the id string) which
does have the value 'empty_string' at the time of my assignment
statement.

I suspect that you are using non-debug and debug versions of MS C
runtime library: one is used by the omniORB and the other is used by
your application.

The string gets allocated in one heap and wants to get deallocated in another.

HTH,

Matej

[bjorn rohde jensen]

Post by Matej Kenda
Hi Severin,

Post by Ecker Severin
static inline void free(char* s) {
if (s && s != empty_string) delete[] s;
}
For some reason the condition hold true and attempts are made to delete
an invalid string resource. As you can see above I just want to assign a
string to a completely new and fresh corba object (the id string) which
does have the value 'empty_string' at the time of my assignment
statement.

I suspect that you are using non-debug and debug versions of MS C
runtime library: one is used by the omniORB and the other is used by
your application.
The string gets allocated in one heap and wants to get deallocated in another.
HTH,
Matej

I would say,the problem is, when you assign the constant pointer to
var.id, var assumes ownership of the memory pointed to, and it will
attempt to free it, when the variable releases ownership of it.
CosNaming::Name behaves like _var types in that respect, and your
runtime is quite right to complain about freeing string constants.

[Carlos]

Post by bjorn rohde jensen

Post by Matej Kenda
Hi Severin,

Post by Ecker Severin
static inline void free(char* s) {
if (s && s != empty_string) delete[] s;
}
For some reason the condition hold true and attempts are made to delete
an invalid string resource. As you can see above I just want to assign a
string to a completely new and fresh corba object (the id string) which
does have the value 'empty_string' at the time of my assignment
statement.

I suspect that you are using non-debug and debug versions of MS C
runtime library: one is used by the omniORB and the other is used by
your application.
The string gets allocated in one heap and wants to get deallocated in another.
HTH,
Matej

I would say,the problem is, when you assign the constant pointer to
var.id, var assumes ownership of the memory pointed to, and it will
attempt to free it, when the variable releases ownership of it.
CosNaming::Name behaves like _var types in that respect, and your
runtime is quite right to complain about freeing string constants.

I don't agree with you, Bjorn, because

CosNaming::Name var;
var.length(1);
var[0].id = (const char*)"test";

is correct, what you say is correct if the code is

var[0].id = "test";

in this case "test" is char* type, so var[0].id assumes the ownership,
but whith the cast (const char*) var[0].id creates a copy and assumes
the ownership of the copy.

Really I don't know which can be the problem because that code is
correct, I use it a lot of times in linux (whith a lot of g++ versions)
and I never use windows platforms because I think they are problematic
platforms ;)


Cheers.

Carlos.

Post by bjorn rohde jensen
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[bjorn rohde jensen]

Post by Carlos

Post by bjorn rohde jensen

Post by Matej Kenda
Hi Severin,

Post by Ecker Severin
static inline void free(char* s) {
if (s && s != empty_string) delete[] s;
}
For some reason the condition hold true and attempts are made to delete
an invalid string resource. As you can see above I just want to assign a
string to a completely new and fresh corba object (the id string) which
does have the value 'empty_string' at the time of my assignment
statement.

I suspect that you are using non-debug and debug versions of MS C
runtime library: one is used by the omniORB and the other is used by
your application.
The string gets allocated in one heap and wants to get deallocated in another.
HTH,
Matej

I would say,the problem is, when you assign the constant pointer to
var.id, var assumes ownership of the memory pointed to, and it will
attempt to free it, when the variable releases ownership of it.
CosNaming::Name behaves like _var types in that respect, and your
runtime is quite right to complain about freeing string constants.

I don't agree with you, Bjorn, because
CosNaming::Name var;
var.length(1);
var[0].id = (const char*)"test";
is correct, what you say is correct if the code is
var[0].id = "test";
in this case "test" is char* type, so var[0].id assumes the ownership,
but whith the cast (const char*) var[0].id creates a copy and assumes
the ownership of the copy.
Really I don't know which can be the problem because that code is
correct, I use it a lot of times in linux (whith a lot of g++ versions)
and I never use windows platforms because I think they are problematic
platforms ;)
Cheers.
Carlos.

Post by bjorn rohde jensen
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

Ah yes, you are right, the const cast does force a deep copy, so matej
is probably right, you are mixing runtime and debug libs. Never used
casting to force the deep copies, i like string_dup("test") better.

Omniorb libs are build in both debug and release versions on windows. I
think, the naming convention is that if bla.dll or bla_rt.dll is the
release version, then blad.dll or bla_rtd.dll is the debug version.
Windows libs are indeed weird.

Your windows compiler thingie should have some tab with a text field
for extra libraries during linking, try checking the omni libs there
against the omni docu.

[Wernke zur Borg]

Post by bjorn rohde jensen
Never used
casting to force the deep copies, i like string_dup("test") better.

This also goes for me, so my question is, just out of curiosity, does it
work when you use string_dup("test") ?

Regards, Wernke