toghe
1/6/2006 1:07:00 PM
Tx for the quick response !
The strange thing is that the code is working correctly if the record has a
recid, eg.
for i = 1..10000
{
select c;
c.orig();
}
So I fear reporting this to Microsoft is only gonna result in
'use the workaround: if (c.RecId) c.orig();'
But anyway, tx for testing it out :)
Grts,
Toghe
"Luegisdorf" wrote:
> Hi Toghe
>
> Have tried your example and get the same error. It looks like the garbage
> collector doesn't remove the custtable objects which are created by the
> kernel common class by calling .orig().
>
> I guess even that's a kernel class (common) which is constructing the
> custtable objects, the default garbage collector used to free memory for x++
> objects doesn't work in kernel. May be the kernel (which was written in
> Visual C++) need a special call to activate the garbage collector and was
> forgotten in method orig() on common class .. or they haven't a automatic
> garbage collector and need to free the memory by self programming and have
> forgotten to implement this routine in the orig() method.
>
> In every case it is a bug. When I was testing with a loop for 200'000,
> Axapta works still be stable, job finished - but the memory was increasing
> and stay high for the whole rest of the Axapta session.
>
> I think it makes sense to report this to Microsoft.
>
> Best regards
> Patrick
>
> "toghe" wrote:
>
> > Did anybody hear about the following problem:
> >
> > Calling this.orig() a million times on a not existing record (record without
> > recid) results then in an out of memory leak:
> >
> > static void Job4(Args _args)
> > {
> > CustTable c;
> > int i;
> > ;
> >
> > for (i = 1; i < 1000000; i++)
> > {
> > c.orig();
> > }
> >
> >
> > Grts,
> > toghe