BitBltSimulation>>copyLoop, read ahead memory failure.

After an afternoon of messing with the Cairo plugin and trying to get  
the PNG import/export routines to work, which are like 30 times  
faster than the smalltalk code,
I've decided we have a problem with BitBltSimulation>>copyLoop


The Cairo surface maps a 512x348 PNG image, it's 32bits and a row  
spans 2048 bytes.
So Cairo cheerfully allocates a chunk of memory 786,432 bytes to  
store the image data and we declare that a surface so bitblt has to  
copy in and our of our data area.
  I'll note the Virtual Memory system marks the page after my  
allocation of the data bytes as non-readable. Of course some times it  
is readable, and sometimes not but your milage may vary and certainly  
it depends on what the operating system thinks.

Then we invoke  foo displayOn: Display where foo is a form that maps  
to the Surface and we die.

Why


In BitBltSimulation>>copyLoop

                {Lots of code, then }

                "This last section, if used, requires masking of the destination  
store..."
                nWords > 1 ifTrue:
                        [destMask := mask2.
                        thisWord := self srcLongAt: sourceIndex.  "pick up next word"
                        sourceIndex := sourceIndex + hInc.
                        skewWord := ((prevWord bitAnd: notSkewMask) bitShift: unskew)
                                                        bitOr:  "32-bit rotate"
                                                ((thisWord bitAnd: skewMask) bitShift: skew).
                        destWord := self dstLongAt: destIndex.
                        mergeWord := self mergeFn: (skewWord bitAnd: halftoneWord) with:  
destWord.
                        destWord := (destMask bitAnd: mergeWord) bitOr:
                                                        (destWord bitAnd: destMask bitInvert32).
                        self dstLongAt: destIndex put: destWord.
                        destIndex := destIndex + hInc].


At

thisWord := self srcLongAt: sourceIndex.  "pick up next word"

we die on a virtual memory read error because the address is not  
readable, the virtual memory page is the
page after the 786,432 bytes that were allocated to store the cairo  
surface data.
I'll note i is 384
word is 512
preload is true
sourceIndex does point to the next word after the last word allocated  
for the surface.
sourceDelta is -4

Likely we're trying to preload the next word past the last word of  
our data area? Bad idea.

I'd rather not hack, so if someone has an idea how to fix that would  
be good.


--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

Yes, it has always been that way. copyLoop reads one word after the end
of the bitmap. It's never used but it'll attempt to touch the memory.

Cheers,
   - Andreas

John M McIntosh wrote:

On 12-Oct-06, at 9:50 PM, Andreas Raab wrote:

> Yes, it has always been that way. copyLoop reads one word after the  
> end of the bitmap. It's never used but it'll attempt to touch the  
> memory.
>
> Cheers,
>   - Andreas

Ok, well should it read ?

                "This last section, if used, requires masking of the destination  
store..."
                (nWords > 1 and: [(preload and: [i=bbH]) not]) ifTrue: []

where we check preload and if the i value is equal to the height we  
don't do the prefetch?
Does that sound reasonable?


--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===