Testers needed! Re: Athens BitBlt bug?

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 <[hidden email]>:

Anyone knows what this BitBlt bug is or was?

12818 Last row missing

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 Wrong size for Athens surface pattern paint from a Form

nicolai

BUMP

 

load bleeding edge from Bloc

Hi

2015-05-08 1:43 GMT+03:00 Nicolai Hess <[hidden email]>:

load bleeding edge from Bloc

Code for loading it can be very helpfull

Thanks.

I check your scenario on Windows7.
All work like you said. And with your fix artifacts are disappeared

2015-05-08 11:25 GMT+03:00 Nicolai Hess <[hidden email]>:

2015-05-08 10:05 GMT+02:00 Denis Kudriashov <[hidden email]>:

Hi

2015-05-08 1:43 GMT+03:00 Nicolai Hess <[hidden email]>:

load bleeding edge from Bloc

Code for loading it can be very helpfull

:)

Gofer new
    smalltalkhubUser: 'Pharo' project: 'Bloc';
    load;
    configurationOf: 'Bloc';
loadBleedingEdge

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 <[hidden email]>:

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 <[hidden email]>:

Anyone knows what this BitBlt bug is or was?

12818 Last row missing

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 Wrong size for Athens surface pattern paint from a Form

nicolai

BUMP

 

On 8 May 2015 at 00:43, Nicolai Hess <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

Anyone knows what this BitBlt bug is or was?

12818 Last row missing

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 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 <[hidden email]> wrote:

On 8 May 2015 at 00:43, Nicolai Hess <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

Anyone knows what this BitBlt bug is or was?

12818 Last row missing

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 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 <[hidden email]>:

On 8 May 2015 at 21:32, Igor Stasenko <[hidden email]> wrote:

On 8 May 2015 at 00:43, Nicolai Hess <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

Anyone knows what this BitBlt bug is or was?

12818 Last row missing

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 Wrong size for Athens surface pattern paint from a Form

nicolai

BUMP

 

--

Best regards,
Igor Stasenko.

--

Best regards,
Igor Stasenko.

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 <[hidden email]>:

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 <[hidden email]>:

Anyone knows what this BitBlt bug is or was?

12818 Last row missing

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 Wrong size for Athens surface pattern paint from a Form

nicolai

BUMP

              

On 8 May 2015 at 22:20, Nicolai Hess <[hidden email]> wrote:

2015-05-08 21:42 GMT+02:00 Igor Stasenko <[hidden email]>:

On 8 May 2015 at 21:32, Igor Stasenko <[hidden email]> wrote:

On 8 May 2015 at 00:43, Nicolai Hess <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

Anyone knows what this BitBlt bug is or was?

12818 Last row missing

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 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 <[hidden email]>:

On 8 May 2015 at 22:20, Nicolai Hess <[hidden email]> wrote:

2015-05-08 21:42 GMT+02:00 Igor Stasenko <[hidden email]>:

On 8 May 2015 at 21:32, Igor Stasenko <[hidden email]> wrote:

On 8 May 2015 at 00:43, Nicolai Hess <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

Anyone knows what this BitBlt bug is or was?

12818 Last row missing

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 Wrong size for Athens surface pattern paint from a Form

nicolai

BUMP

 

--

Best regards,
Igor Stasenko.

--

Best regards,
Igor Stasenko.

--

Best regards,
Igor Stasenko.

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)

 

--

Best regards,
Igor Stasenko.

2015-06-09 18:03 GMT+02:00 Igor Stasenko <[hidden email]>:

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.