[omniORB] Memory management on NT 4.0

[Lars von Wedel]

This is a multi-part message in MIME format.
--------------20D666BEE85E2CEC47C1DAC2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

we're getting a '_CtrlsValidHeapPtr' exception... See the stack trace 
below (it's not very interesting except that it suggests that freeing
memory
is the problem).

I tried the examples on the machine where I compiled omniORB and
transferred
only the binary stuff. Anyway, we copied the project settings (.dsp)
from a 
different project and reorganized the files and now it works again...

We'll try to diff the two project files, maybe we can figure it out.
Anyway, Windows remains a strange thing to me...

Thanks for all answers,
Lars

> _free_dbg(void * 0x00b74b10, int 1) line 1011 + 48 bytes
> operator delete(void * 0x00b74b10) line 49 + 16 bytes
> omni::freeString(char * 0x00b74b10) line 240 + 33 bytes
> _CORBA_String_member::~_CORBA_String_member() line 199 + 11 bytes
> CONVERT! _lseeki64 + 29496 bytes
> CONVERT! `eh vector destructor iterator'(void *,unsigned int,int,void
> (*)(void *)) + 94 bytes
> CosNaming::NameComponent::`vector deleting destructor'(unsigned int 3) +
> 62 bytes
> _CORBA_Sequence<CosNaming::NameComponent>::freebuf(CosNaming::NameComponent
> * 0x00b74c34) line 140 + 34 bytes
> 
> _CORBA_Sequence<CosNaming::NameComponent>::~_CORBA_Sequence<CosNaming::NameComponent>()
> line 182 + 33 bytes
> 
> _CORBA_Unbounded_Sequence<CosNaming::NameComponent>::~_CORBA_Unbounded_Sequence<CosNaming::NameComponent>()
> line 311 + 37 bytes
> CosNaming::Name::~Name() + 37 bytes
> CosNaming::Name::`scalar deleting destructor'(unsigned int 1) + 37 bytes
> 
> CosNaming::Name_var::~Name_var() line 113 + 67 bytes
> $E365() + 34 bytes
> doexit(int 19, int 0, int 0) line 353
> exit(int 19) line 279 + 13 bytes
> mainCRTStartup() line 212
> KERNEL32! 77f1b9ea()

Duncan Grisby wrote:
> 
> On Friday 5 October, Lars von Wedel wrote:
> 
> > we've started developing with omniORB 3.0.2 and VC6++ on NT 4.0.
> > However, during runtime, I get exceptions whenever memory from any
> > CORBA objects is deallocated, e.g. when a X_var variable goes out of
> > scope of when I assign to a sequence variable a second time (and
> > thereby the former content is going to be freed up).
> 
> The only time I have heard of this problem, it was due to incompatible
> debug set-up between the application and the omniORB libraries. What
> exception do you get?  Do the omniORB echo examples work?  What if you
> modify eg1.cc to do some extra messing with String_vars, then compile
> it with our makefiles?
> 
> I believe the issue isn't quite as simple as just selecting debug or
> non-debug -- I think you have to choose the right debug settings from
> a number of options.
> 
> Cheers,
> 
> Duncan.
> 
> --
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --
--------------20D666BEE85E2CEC47C1DAC2
Content-Type: text/x-vcard; charset=us-ascii;
 name="vonWedel.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Lars von Wedel
Content-Disposition: attachment;
 filename="vonWedel.vcf"

begin:vcard 
n:von Wedel;Lars
tel;fax:++49 241 8092326
tel;work:++49 241 8095240
x-mozilla-html:FALSE
url:http://www.lfpt.rwth-aachen.de
org:RWTH Aachen;Lehrstuhl fuer Prozesstechnik
adr:;;Turmstrasse 46;52064 Aachen;;;Germany
version:2.1
email;internet:vonWedel@lfpt.rwth-aachen.de
fn:Lars von Wedel
end:vcard

--------------20D666BEE85E2CEC47C1DAC2--