Hi Simon,
I'm sorry I don't have a test case, aside from what I've sent already,
and it's sometimes difficult to reproduce. (though note that the
GSLHaskell library can still be downloaded at the provided URL)
However, I've checked and double-checked our code and can't find
anything on our side which could result in the reported bug.
Since it's happening only for allocations above 2^20-8128 bytes, I
would recommend creating a ticket and some time checking the heap code
for any special cases that happen for allocations near 1MB.
Frederik
On Tue, Aug 08, 2006 at 03:18:34PM +0100, Simon Marlow wrote:
> (cleaning up old mail). Frederik: did you ever get to the bottom of this?
> Do you have a test case,
> and should we create a ticket for it?
>
> Cheers,
> Simon
>
> Frederik Eaton wrote:
> >I'm now using 6.4.2. The bug still persists, but I can't immediately
> >reproduce it with basic GSLHaskell operations, nor with raw memory
> >operations. It is even difficult to reproduce as it is, the examples I
> >gave don't trigger it anymore (I was running them under 6.4.1). For
> >instance, this gives a correct result:
> >>dot (useFast $ $(dim 1000000) (2*vconst 2)) (vconst 4)
> >and this gives an incorrect result:
> >>dot (useFast $ $(dim 1000000) (2.*vconst 2)) (vconst 4)
> >(the first one creates a new matrix of 2's and does element-wise
> >multiplication; the second just scales by 2)
> >It could be a bug in our code, but I'd be surprised. It only triggers
> >for vectors of length 130056 or greater (that's 130056 8-byte doubles,
> >or 2^20-8128 bytes). If something were being prematurely finalized, one
> >would imagine that shorter vectors would also expose the problem. Most
> >of all, it seems very strange that in certain situations two different
> >objects would get the same address when they're large, but not when
> >they're small. But I'll keep looking for the source of the problem.
> >Frederik
> >On Fri, Jun 02, 2006 at 05:11:24PM +0200, Alberto Ruiz wrote:
> >>Hi Frederik, I will be out of town this weekend (I really need it!), I will
> >>take a look at the
> >>problem on Monday. By now my recommendation is:
> >>
> >>1) try to reproduce the problem without GSLHaskell or any other library,
> >>using just mallocArray,
> >>newArray, etc. with those big sizes. (Use ghc 6.4.2 or better..)
> >>
> >>2) If this is not possible, try to reproduce the problem with the simplest
> >>possible example using
> >>the unmodified GSLHaskell.
> >>Alberto
> >>
> >>On Friday 02 June 2006 16:15, Frederik Eaton wrote:
> >>
> >>>Hi Alberto,
> >>>
> >>>I'm experiencing a problem which may be a bug in GHC. Here I take the
> >>>dot product of two vectors. I put debugging traces in the 'dotR' C
> >>>function (which I call in 'dot'), so one can see the addresses of the
> >>>memory blocks. When the vectors are below a certain size, the function
> >>>seems to give the correct result. However, when they are above a
> >>>certain size, the same pointers are sometimes used for both arguments
> >>>(ap and bp), and the result is of course incorrect. The incorrect
> >>>result is consistent with both pointers referring to the first vector
> >>>(vconst 2). Also, with other arguments I sometimes get heap
> >>>corruption. Any idea what might be the problem?
> >>>
> >>>Prelude Vector> print $ (dot $ useFast $ $(dim 1000) $ (vconst 2)) (ones)
> >>>ap=0xb1b0a008, bp=0xb1b0c008, rp=0xb1b036c8
> >>>an=1000, bn=1000, rn=1
> >>>res=2000.000000
> >>>2000.0
> >>>Prelude Vector> print $ (dot $ useFast $ $(dim 1000000) $ (vconst 2))
> >>>(ones) ap=0xb3402008, bp=0xb3402008, rp=0xb1b0c770
> >>>an=1000000, bn=1000000, rn=1
> >>>res=4000000.000000
> >>>4000000.0
> >>>Prelude Vector> print $ (dot $ useFast $ $(dim 1000000) $ (vconst 2))
> >>>(vconst 2) ap=0xb2c02008, bp=0xb2302008, rp=0xb1b08780
> >>>an=1000000, bn=1000000, rn=1
> >>>ap[130055]=2.000000 bp[130055]=-0.000000
> >>>ap[130056]=2.000000 bp[130056]=2.000001
> >>>ap[130058]=2.000000 bp[130058]=2.000000
> >>>ap[130059]=2.000000 bp[130059]=0.000000
> >>>ap[130060]=2.000000 bp[130060]=2.000001
> >>>...
> >>>res=3992888.004728
> >>>3992888.004727577
> >>>
> >>>Here is dotR:
> >>>
> >>>int dotR(DVEC(a), DVEC(b), DVEC(r)) {
> >>> REQUIRES(an == bn && rn == 1, BAD_SIZE);
> >>> DEBUGMSG("dotR");
> >>> fprintf(stderr,"ap=%p, bp=%p, rp=%p\n",ap,bp,rp);
> >>> fprintf(stderr,"an=%d, bn=%d, rn=%d\n",an,bn,rn);
> >>> double res=0.0;
> >>> int i;
> >>> for(i=0; i<an; i++) {
> >>> if(ap[i] != floor(ap[i]) || bp[i] != floor(bp[i]))
> >>> fprintf(stderr,"ap[%d]=%lf bp[%d]=%lf\n",i,ap[i],i,bp[i]);
> >>> res += ap[i]*bp[i];
> >>> }
> >>> fprintf(stderr,"res=%lf\n",res);
> >>> rp[0] = res;
> >>> OK
> >>>}
> >>>
> >>>I switched to not using gsl here, so that I could be sure the bug
> >>>wasn't in gsl. However, when using gsl the same problems occur. So I
> >>>think it may be heap corruption in ghc. But I don't know how to debug
> >>>that. I tried running in valgrind but it doesn't show anything
> >>>obvious. If you want to run what I have, here is my code:
> >>>
> >>>http://ofb.net/~frederik/GSLHaskell2.tar.gz
> >>>
> >>>The problem is exposed by building and running:
> >>>
> >>>print -l ':m Vector' 'print $ (dot $ useFast $ $(dim 1000000) $ (vconst 2))
> >>>(vconst 2)' | =ghci -package GSL -fglasgow-exts
> >>>
> >>>Thanks,
> >>>
> >>>Frederik
> >>
>
--
http://ofb.net/~frederik/
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
