we are not looking at C++ string overflow. string.max_size() = 4294967294;
with gcc 2.96, RH 7.3 on i686. It is hard to beat that unless we try
really hard.
It is not TString over flow either.
{
TCut s; long I=0;
for (; I<429496729; I+=10) { cerr<<I<<" "; s += "aaaaaaaaaa";
if (I>10000 && !(I%10000)) cout<<s<<endl; }
}
A TCut is easily longer than 100k chars. It is hard to beat that too.
Then it comes down the the place where the cut is actually evaluated. But
that it hard to debug. Who knows what ROOT is doing inside. Anyone looked
at which line the code seg faulted?
For the moment, I guess, we either sacrify one TOF, or use a two stage
cut. I will have a look at it.
Chi
On Mon, 28 Oct 2002, Simon Sirca wrote:
> Hi,
>
> On Mon, 28 Oct 2002, zhangchi wrote:
>
> > a block on a PC is what, a few killo?
>
> I think 512K Adrian mentions is not what the C++ guys are referring to.
> Perhaps they meant the filesystem block sizes which are usually limited
> to 4K or 8K (although Linux only supports 4K on i686 machines, and 4K
> is also the page size), not the fragment sizes, which are indeed (usually)
> 512K.
>
> > I welcome any suggestion to go arround these limits
>
> Instead of bypassing the limits, perhaps we should think about fishing
> for such details of the code as subscript overflows. At least in the
> Blast code this can be done by furnishing critical memory allocations
> with exception catching. Every failure in new() can be made to throw
> an exception which can be caught (and handled). Before accusing Draw()
> (which, however, is not an unlikely candidate) one could check if our
> side of the code performs as it should.
>
> Simon
>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST