Title: | ObjectBroker Development - BEA Systems' CORBA |
Notice: | See note 2 for kit locations; note 4 for training |
Moderator: | RECV::GUMBEL d |
Created: | Thu Dec 27 1990 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 2482 |
Total number of notes: | 13057 |
We have noticed a memory leak (again!!, this is a severe one) on the client side. If you have user defined types defined as: typedef struct tString_ { string Ustr; } tString; typedef sequence<tString> tUseqtString; typedef sequence<string> tUseqUstr; typedef struct tUDT5_ { string Ustr; tUseqUstr UseqUstr; } tUDT5; // typedef sequence<SecuritySet> SecuritySets; typedef sequence<tUDT5> tUseqUDT5; typedef struct tUDT51_ { string Ustr; tUseqtString UseqtString; } tUDT51; typedef sequence<tUDT51> tUseqUDT51; These types are used as attributes in an interface, e.g: interface i1 { readonly attribute tUseqUDT5 useqUDT5; readonly attribute tUseqUDT51 useqUDT51; } Then useqUDT5 leaks but useqUDT51 doesn't. The difference between the two is that useqUDT51 has encapsulated the unbounded string sequence which generates a String_var. The server side doesn't leak on either useqUDT5 or useqUDT51 which is interersting. Gunnar (actually John Donaldson)
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
2465.1 | UTROP1::UTROP1::SCHOUTEN_J | Tue Apr 15 1997 03:52 | 13 | ||
By the way... OBB v2.7-11 on NT 4. As the .0 says, we can work round these client leaks by encapsulating all strings in structs (and presumably forcing the generation of string vars). However, we want to know: is this real?; is this going to be fixed? Also we are kind of surprised that the server 'knows' how to clean up these sequences and the client doesn't! John D. | |||||
2465.2 | REQUE::BOWER | Peter Bower, ObjectBroker | Tue Apr 15 1997 07:38 | 5 | |
The tUseqUstr sequence has a generated class (_ForSeq_var) that should be handling the memory allocation. We will have to reproduce it here. If you have a sample client/server written that shows the problem, it would save us some time. | |||||
2465.3 | LEMAN::DONALDSON | Froggisattva! Froggisattva! | Wed Apr 23 1997 08:15 | 6 | |
Peter, sorry for the delay. The problem is still there of course. I can give you some sample code but not today. John D. |