Thank you Ben, I think this is the information I was looking for.
nicolai 2015-05-14 17:41 GMT+02:00 Ben Coman <[email protected]>: > I can't follow all the details, but I dug up for a few references that > might relate... > > * [Vm-dev] There might be a bug in Bitblt copyloop > > http://lists.squeakfoundation.org/pipermail/vm-dev/2012-April/010303.html > > * BitBltSimulation>>copyLoop, read ahead memory failure. > > http://forum.world.st/BitBltSimulation-gt-gt-copyLoop-read-ahead-memory-failure-td56201.html > > * [Squeakland] [BUG] Can't use Squeakland plugin very well from Firefox... > > http://lists.squeakland.org/pipermail/squeakland/2006-November/003380.html > Review 3.8.13.b3 > > * Macintosh release - source code change notes > http://wiki.squeak.org/squeak/5585 > Review 3.8.13.b3 > > * [pypy-commit] lang-smalltalk default: reverted the optimization to the > copyLoop because it introduced clipping errors (BTC: Strange that smalltalk > is mixing with pypy, so this might not relate at all) > https://mail.python.org/pipermail//pypy-commit/2013-April/073156.html > > cheers -ben > > > On Thu, May 14, 2015 at 5:22 AM, Nicolai Hess <[email protected]> wrote: > >> >> >> 2015-05-08 22:28 GMT+02:00 Igor Stasenko <[email protected]>: >> >>> >>> >>> On 8 May 2015 at 22:20, Nicolai Hess <[email protected]> wrote: >>> >>>> >>>> >>>> 2015-05-08 21:42 GMT+02:00 Igor Stasenko <[email protected]>: >>>> >>>>> >>>>> >>>>> On 8 May 2015 at 21:32, Igor Stasenko <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 8 May 2015 at 00:43, Nicolai Hess <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> Some testers needed! >>>>>>> >>>>>>> I can not reproduce the BitBlt bug and I would like to get this >>>>>>> right, so that surface pattern >>>>>>> paints use the correct form dimension. >>>>>>> >>>>>>> Be sure, my fried, the bug is there, sitting in VM. >>>>>> Bitblt implementation prereads a pixel from bitmap *before* checking >>>>>> the loop bounds, meaning that it reads at least a single byte beyond the >>>>>> actual contents of the bitmap. >>>>>> It is not harmful in cases when bitmap is allocated in object memory >>>>>> since VM memory design actually guarantees, that there are at least >>>>>> certain >>>>>> amount of bytes in form of breathing space always available, so reading >>>>>> single word past any allocated object is not hurts.. >>>>>> But not in case, when bitmap residing in external heap.. because >>>>>> reading beyond allocated space might cause segmentation fault.. and it >>>>>> was, >>>>>> until i figured what was causing it and where the bug is. >>>>>> >>>>> >>>> This mean it can happen every time we read form data from a surface >>>> plugin - it is not only an issue for athens/cairo. >>>> >>>> Right, this is not cairo-only issue.. It just manifested itself when i >>> was started using external surfaces allocated by cairo with bitblt. >>> Which was causing occasional, irregular crashes time to time and i was >>> quite lucky finding the cause of it. >>> >> >> >> Any chance you remember what triggers this error? What code did you use, >> simple drawings or more advanced >> use of athens. Image patterns, gradient patterns. >> Or at least, what platform mac/win/linux? >> >> I tried different vm/image versions but only on windows so far. >> >> There were some changes on some bitblt functions, maybe the bug does not >> exist anymore? >> >> >> nicolai >> >> >>> >>> >>>> I will take a look at bitblt implementation. >>>> >>>> Thank you ! >>>> >>>> >>>>> >>>>>> >>>>> The workaround, that i introduced was simply to tell Cairo to allocate >>>>> surface 1 row taller and then use smaller height in bitblt operations, so >>>>> it can never use the last row.. >>>>> that, of course, going in conflict of using cairo for a patterns to >>>>> fill things with bitmaps, which relying on surface's dimensions and using >>>>> all its pixels.. >>>>> :( >>>>> >>>>> hmm.. >>>>> >>>>>> >>>>>> >>>>>>> Prefered test setup: >>>>>>> a (fresh) pharo image >>>>>>> load bleeding edge from Bloc (because with bloc the whole (morphic) >>>>>>> world is drawn with athens). >>>>>>> change to watery theme ( because it makes some heavy use of form >>>>>>> fills) >>>>>>> verify that vertical scrollbars have this artifact (blank lines). >>>>>>> load the attached code (this code reverts igors change for the 1 >>>>>>> pixel extra height. >>>>>>> >>>>>>> please report back >>>>>>> what platform windows/linux/mac 32/64 bit >>>>>>> what pharo vm and image version. >>>>>>> >>>>>>> For me >>>>>>> Windows 7 32 bit >>>>>>> Win32 built on Apr 9 2015 21:05:04 Compiler: 4.6.2 >>>>>>> Latest update: #50039 >>>>>>> >>>>>>> -> no segfault >>>>>>> >>>>>>> thanks in advance >>>>>>> >>>>>>> >>>>>>> 2015-03-13 21:22 GMT+01:00 stepharo <[email protected]>: >>>>>>> >>>>>>>> I do not know. May be igor is reading this mailing-list but I >>>>>>>> doubt. >>>>>>>> >>>>>>>> >>>>>>>> 2015-01-27 21:46 GMT+01:00 Nicolai Hess <[email protected]>: >>>>>>>> >>>>>>>> Anyone knows what this BitBlt bug is or was? >>>>>>>>> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row >>>>>>>>> missing >>>>>>>>> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra >>>>>>>>> height for Cairo surface >>>>>>>>> >>>>>>>>> Because with the fix in 13236, it is not (easily) possible to >>>>>>>>> make >>>>>>>>> a repeating (vertical) pattern paint with 1 pixel height: >>>>>>>>> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size >>>>>>>>> for Athens surface pattern paint from a Form >>>>>>>>> >>>>>>>>> >>>>>>>>> nicolai >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> BUMP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >
