nu.&I8߮<~;
z{mʗ{V
z{S}ĝ xjǺ
Hi Marc,
Does the GC problem been solved?
Regards
luowy
----- ?? -----
???: Blackbox Support Oberon microsystems AG
? ?: Re: [BLACKBOX] Windows 7
? ?: 2012?8?8? 23:31:59
Thank you very much for the error report, Robert and Bernhard!
We are currently working on a correction and we will post it as soon as possible.
Thanks again and kind regards,
Marc
> -----Original Message-----
> From: BlackBox [mailto:BLACKBOX{([at]})nowhere.xyBehalf Of
> Treutwein Bernhard
> Sent: Mittwoch, 8. August 2012 15:52
> To: BLACKBOX{([at]})nowhere.xy
> Subject: Re: [BLACKBOX] Windows 7
>
> Bob,
>
> > The problem is related to requests for large amounts of memory.
>
> yes, but it is very strange. It is only with a special range
> of values.
>
> Below is a tiny test program with a small dialog.
>
> With the given default 2147483647 no problem. Neither with
> 214748 or 21474800.
> With 214748000 and some other values it gives a Trap 0, i.e.
> NEW returns NIL.
>
> But with 327670000 there is an index out of range trap in
> Kernel.OldBlock (trap viewer
> appended as StdCoded file) and I had one number, where it
> resulted in an
> avalanche of trap viewer, but I did not write that number down.
>
> In the included trap viewer there is a negative value for
> size in Kernel.NewArr.
> I guess that somewhere around here is a logical error ... or
> the statement
> size := headSize + nofelem * t.size; silently overflows to
> negative values
>
> Regards
> --
> Bernhard
nu.&I8߮<~;
z{mʗbqb
z{m}ޝ xjǺ
z{Ch+bv!~)^{\rtf1\ansi\ansicpg1252\fromtext \fbidis \deff0{\fonttbl
{\f0\fswiss Arial;}
{\f1\fmodern Courier New;}
{\f2\fnil\fcharset2 Symbol;}
{\f3\fmodern\fcharset0 Courier New;}}
{\colortbl\red0\green0\blue0;\red0\green0\blue255;}
\uc1\pard\plain\deftab360 \f0\fs20 \par
Hi Marc,\par
\par
Does the GC problem been solved?\par
\par
\par
\par
Regards\par
\par
luowy\par
----- ?? ----- \par
???: Blackbox Support Oberon microsystems AG \par
? ?: Re: [BLACKBOX] Windows 7\par
? ?: 2012?8?8? 23:31:59\par
\par
Thank you very much for the error report, Robert and Bernhard!\par
\par
We are currently working on a correction and we will post it as soon as possible.\par
\par
Thanks again and kind regards,\par
Marc\par
\par
\par
> -----Original Message-----\par
> From: BlackBox [mailto:BLACKBOX@LISTS.OBERON.CH] On Behalf Of \par
> Treutwein Bernhard\par
> Sent: Mittwoch, 8. August 2012 15:52\par
> To: BLACKBOX{([at]})nowhere.xy
> Subject: Re: [BLACKBOX] Windows 7\par
> \par
> Bob,\par
> \par
> > The problem is related to requests for large amounts of memory.\par
> \par
> yes, but it is very strange. It is only with a special range \par
> of values.\par
> \par
> Below is a tiny test program with a small dialog.\par
> \par
> With the given default 2147483647 no problem. Neither with \par
> 214748 or 21474800.\par
> With 214748000 and some other values it gives a Trap 0, i.e. \par
> NEW returns NIL.\par
> \par
> But with 327670000 there is an index out of range trap in \par
> Kernel.OldBlock (trap viewer\par
> appended as StdCoded file) and I had one number, where it \par
> resulted in an\par
> avalanche of trap viewer, but I did not write that number down.\par
> \par
> In the included trap viewer there is a negative value for \par
> size in Kernel.NewArr. \par
> I guess that somewhere around here is a logical error ... or \par
> the statement\par
> size := headSize + nofelem * t.size; silently overflows to \par
> negative values\par
> \par
> Regards\par
> --\par
> Bernhard\par
}nu.&I8߮<~;
Received on Wed Aug 29 2012 - 21:00:48 UTC