Testers needed! Re: Athens BitBlt bug?
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. 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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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
the code (reverting igors change for the 1 pixel extra height) 2015-05-08 0:43 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
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.
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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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
2015-05-08 10:05 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi
2015-05-08 1:43 GMT+03:00 Nicolai Hess <nicolaihess@web.de>:
load bleeding edge from Bloc
Code for loading it can be very helpfull
:) Gofer new smalltalkhubUser: 'Pharo' project: 'Bloc'; load; configurationOf: 'Bloc'; loadBleedingEdge
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de> 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.
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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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.
On 8 May 2015 at 21:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de> 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.
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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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.
2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 21:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de> 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. 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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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.
On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess@web.de> wrote:
2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 21:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de> 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.
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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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.
Indeed I'm amazed. Freaky logic. Stef Le 8/5/15 22:28, Igor Stasenko a écrit :
On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com>>:
On 8 May 2015 at 21:32, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> 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.
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 <stepharo@free.fr <mailto:stepharo@free.fr>>:
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 <nicolaihess@web.de <mailto:nicolaihess@web.de>>:
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.
2015-05-08 22:28 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess@web.de> wrote:
2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 21:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de> 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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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.
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-fail... * [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 <nicolaihess@web.de> wrote:
2015-05-08 22:28 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess@web.de> wrote:
2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 21:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de> 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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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.
Thank you Ben, I think this is the information I was looking for. nicolai 2015-05-14 17:41 GMT+02:00 Ben Coman <btc@openinworld.com>:
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-fail...
* [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 <nicolaihess@web.de> wrote:
2015-05-08 22:28 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess@web.de> wrote:
2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 21:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de> 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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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.
On 13 May 2015 at 23:22, Nicolai Hess <nicolaihess@web.de> wrote:
2015-05-08 22:28 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess@web.de> wrote:
2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 8 May 2015 at 21:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess@web.de> 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?
the easiest way to reproduce it would be:
- allocate a new surface of such dimensions, that its buffer size will be aligned with 4k page boundary (a smallest one would be 1x1024, or 1024x1, since one pixel is 4 bytes) - try to blit this surface with bitblt - crash (sure it happens not always, since often there could be another memory page allocated for other purposes with read access granted, but if you continuously do that, you will inevitable face the crash)
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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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.
-- Best regards, Igor Stasenko.
2015-06-09 18:03 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
the easiest way to reproduce it would be: - allocate a new surface of such dimensions, that its buffer size will be aligned with 4k page boundary (a smallest one would be 1x1024, or 1024x1, since one pixel is 4 bytes) - try to blit this surface with bitblt - crash
(sure it happens not always, since often there could be another memory page allocated for other purposes with read access granted, but if you continuously do that, you will inevitable face the crash)
Thank you for your feedback, but still no "luck" - no crash. Do you remember if this happens on windows at all or only on mac?
-- Best regards, Igor Stasenko.
On 9 June 2015 at 22:54, Nicolai Hess <nicolaihess@web.de> wrote:
2015-06-09 18:03 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
the easiest way to reproduce it would be: - allocate a new surface of such dimensions, that its buffer size will be aligned with 4k page boundary (a smallest one would be 1x1024, or 1024x1, since one pixel is 4 bytes) - try to blit this surface with bitblt - crash
(sure it happens not always, since often there could be another memory page allocated for other purposes with read access granted, but if you continuously do that, you will inevitable face the crash)
Thank you for your feedback, but still no "luck" - no crash.
Do you remember if this happens on windows at all or only on mac?
Dunno. I had it on my mac.
Sure it may depend on how OS/C libs allocating memory. Anyways, since we're talking about using bitmaps as fill patterns for cairo, it should be safe as long as bitblt never involved with it. Actually registering surfaces with bitblt required only if they used in operations like copying their contents to Display form require this workaround, since it involves bitblt primitive(s). For the rest of cases (and if one day, hopefully we stop using bitblt altogether), the need in this workaround can be completely eliminated. So the issue can be localized if we split implementation and make a subclass, lets say CairoMorphicCompatibleSurface, where we move all registering logic together with workarounds, and in basic class simply throw exception on attempt to use it #asForm.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Fri, May 8, 2015 at 6:43 AM, Nicolai Hess <nicolaihess@web.de> 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.
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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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
I am unable to produce the segfault on OSX Mavericks with neither old nor new VMs... Image ----- /Users/ben/Library/Application Support/Pharo/images/Athens BitBlt-50041/Athens BitBlt-50041.image Pharo5.0 Latest update: #50041 Unnamed Virtual Machine --------------- /Applications/Pharo.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14826 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14826 NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 Virtual Machine --------------- /Users/ben/Library/Application Support/Pharo/vm/pharo-mac-stable-vm/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14904 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14904 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 cheers -ben
Thank you for testing. I am sorry but I missed one additional change. This change set issue_14183.cs did not revert all. The one thing I was missing is a change in AthensCairoSurface class>>createGetSurfaceFormatFn here, it tells the bitblt the size of the external form data, and igor made this height one line smaller to prevent the wrong memory access. please test again, with this cs: issue_14813_II.cs You need to save and restart the image to use the change in createGetSurfaceFormatFn (I don't know how to manually reinitialize this method). But even with this change, I can not reproduce a segfault. I will take a look at the bitblt implementation and try to find the place where the wrong memory access could happen. nicolai 2015-05-09 10:41 GMT+02:00 Ben Coman <btc@openinworld.com>:
On Fri, May 8, 2015 at 6:43 AM, Nicolai Hess <nicolaihess@web.de> 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.
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 <stepharo@free.fr>:
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 <nicolaihess@web.de>:
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
I am unable to produce the segfault on OSX Mavericks with neither old nor new VMs...
Image ----- /Users/ben/Library/Application Support/Pharo/images/Athens BitBlt-50041/Athens BitBlt-50041.image Pharo5.0 Latest update: #50041 Unnamed
Virtual Machine --------------- /Applications/Pharo.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14826
Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14826 NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
Virtual Machine --------------- /Users/ben/Library/Application Support/Pharo/vm/pharo-mac-stable-vm/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14904
Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14904 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015
cheers -ben
participants (5)
-
Ben Coman -
Denis Kudriashov -
Igor Stasenko -
Nicolai Hess -
stepharo