Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix podview, and a few cleanups to PodView and TextView #1

Merged
merged 9 commits into from
Jun 19, 2013
Merged

Fix podview, and a few cleanups to PodView and TextView #1

merged 9 commits into from
Jun 19, 2013

Conversation

run4flat
Copy link
Contributor

I've been looking closely at Prima::TextView for the last couple of weeks. I began working on revised documentation for Prima::TextView (not included in this patch) and in the process came across a handful of niggles and bugs. One bug is a series of warnings from PodView when and =over block is not followed by a distance, which I've silenced. The other is an issue with PodView's handling of C<< $widget->method() >> which ends up getting rendered as if I had said C<< $widget-method()> >>.

This pull request solves these two bugs, makes a few parts of TextView a little more legible by using named variables in place of $_, and adds a functioning Synopsis to TextView.

@run4flat
Make recalc_ymap a bit more legible; remove direct assignment to $_
a9b6553
@run4flat
Use named iteration variables in TextView::on_paint
790de6f
@run4flat
Improved error return value handling in TextView's block_draw
a0577a4
@run4flat
Added unexpected op handling via an else clause in TextView's block_draw
edb3e45
@run4flat
Minor comment tweak
7669c21
@run4flat
Add SYNOPSIS to TextView
051c747
@run4flat
Lightly cleaned up Prima::PodView::read_paragraph
7aa9851 
Because of the way that PodView matched against the =over pod
directive, it was sometimes matching the undefined value against
a regex. Such behavior issued this warning:

  Use of uninitialized value $_ in pattern match

This commit lightly revises how the directives are processed. It
also removes the non-localized explicit assignment to $_.
@run4flat
Added annotation to on_paint and revised erroneous else condition in …
2e3bca5 
…block_draw
@run4flat
Fix Prima::PodView's rendering of certain in-paragraph code blocks
d817987 
The following example paragraph is incorrectly rendered with PodView:

 To turn off frobnication, simply say C<< $widget->frobnicate(0) >>.

This commit fixes that and reduces the text captures in multibracket
in-paragraph code blocks, which should make it ever so slightly more
efficient.
dk added a commit that referenced this pull request Jun 19, 2013
@dk
Merge pull request #1 from run4flat/fix-podview
b8a0ceb 
Fix podview, and a few cleanups to PodView and TextView
@dk dk merged commit b8a0ceb into dk:master Jun 19, 2013
@dk
Copy link
Owner

dk commented Jun 19, 2013

Excellent work, thank you! Merged all right

/dk

On Wed, Jun 19, 2013 at 08:40:27AM -0700, run4flat wrote:

I've been looking closely at Prima::TextView for the last couple of weeks. I began working on revised documentation for Prima::TextView (not included in this patch) and in the process came across a handful of niggles and bugs. One bug is a series of warnings from PodView when and =over block is not followed by a distance, which I've silenced. The other is an issue with PodView's handling of C&lt;&lt; $widget-&gt;method() &gt;&gt; which ends up getting rendered as if I had said C&lt;&lt; $widget-method()&gt; &gt;&gt;.

This pull request solves these two bugs, makes a few parts of TextView a little more legible by using named variables in place of $_, and adds a functioning Synopsis to TextView.
You can merge this Pull Request by running:

git pull https://github.com/run4flat/Prima fix-podview

Or you can view, comment on it, or merge it online at:

#1

-- Commit Summary --

  • Make recalc_ymap a bit more legible; remove direct assignment to $_
  • Use named iteration variables in TextView::on_paint
  • Improved error return value handling in TextView's block_draw
  • Added unexpected op handling via an else clause in TextView's block_draw
  • Minor comment tweak
  • Add SYNOPSIS to TextView
  • Lightly cleaned up Prima::PodView::read_paragraph
  • Added annotation to on_paint and revised erroneous else condition in block_draw
  • Fix Prima::PodView's rendering of certain in-paragraph code blocks

-- File Changes --

M Prima/PodView.pm (19)
M Prima/TextView.pm (71)

-- Patch Links --

https://github.com/dk/Prima/pull/1.patch
https://github.com/dk/Prima/pull/1.diff

Sincerely,
Dmitry Karasik

@run4flat run4flat deleted the fix-podview branch June 19, 2013 20:56
@dk dk mentioned this pull request Oct 8, 2013
Closed
dk added a commit that referenced this pull request Jun 15, 2020
@dk
workaround Xorg/Xwayland garbled input bug with stippled output after…
340c077 
… repeated XSetRegion

I observed garbled input in a rather rare but 100% reproducible conditions when drawing
grids. The issue is rather complicated but it is truly a bug (will describe later)
that could be seen on my ubuntu 18. It's so complicated so I gave up to write a simple
perl script to show it (and even then a pure C version would be needed to submit as a bug
report, so I gave up). But the following needs to be true, apparently:

1) invalid region must contain 2 disjoint rectangles
2) paint must use XSetFillStyle(FillOpaqueStippled) drawing rectangle/bar over one of these rectangles
3) paint must then issue XSetRegion altering the region set in #1 in some way
4) paint must draw solid lines along the rectangles from #1

This gets the freshly drawn steps 3 and 4 blitted over with old pixels, leaving
only #2 parts visible on the screen. With #3 and #4 ignored, that drawing is
garbled horribly. I ran that with delays and could that rectangles between #1
and #2 were properly cleared, then #2 was drawn over, then #3 and #4, and then
suddenly the painted bits were completely reverted, except the bits from #2.

Looks very much a XWayland/wayland issue, but it's not there on my another ubuntu 18 laptop.
dk added a commit that referenced this pull request Jun 30, 2021
@dk
workaround Xorg/Xwayland garbled input bug with stippled output after…
888d27f 
… repeated XSetRegion

I observed garbled input in a rather rare but 100% reproducible conditions when drawing
grids. The issue is rather complicated but it is truly a bug (will describe later)
that could be seen on my ubuntu 18. It's so complicated so I gave up to write a simple
perl script to show it (and even then a pure C version would be needed to submit as a bug
report, so I gave up). But the following needs to be true, apparently:

1) invalid region must contain 2 disjoint rectangles
2) paint must use XSetFillStyle(FillOpaqueStippled) drawing rectangle/bar over one of these rectangles
3) paint must then issue XSetRegion altering the region set in #1 in some way
4) paint must draw solid lines along the rectangles from #1

This gets the freshly drawn steps 3 and 4 blitted over with old pixels, leaving
only #2 parts visible on the screen. With #3 and #4 ignored, that drawing is
garbled horribly. I ran that with delays and could that rectangles between #1
and #2 were properly cleared, then #2 was drawn over, then #3 and #4, and then
suddenly the painted bits were completely reverted, except the bits from #2.

Looks very much a XWayland/wayland issue, but it's not there on my another ubuntu 18 laptop.
ppisar added a commit to ppisar/Prima that referenced this pull request Feb 6, 2024
@ppisar
Fix memory handling in prima_fc_fonts()
6777cb8 
t/Image/Text.t frequently aborted with "buffer overflow detected" on
i686 and s390x platforms:

    #0  0x000003fff79ae3ca in __pthread_kill_implementation () at /lib64/libc.so.6
    dk#1  0x000003fff7954460 in raise () at /lib64/libc.so.6
    dk#2  0x000003fff793449c in abort () at /lib64/libc.so.6
    dk#3  0x000003fff79a0a2a in __libc_message_impl () at /lib64/libc.so.6
    dk#4  0x000003fff7a3aadc in __fortify_fail () at /lib64/libc.so.6
    dk#5  0x000003fff7a3a368 in __chk_fail () at /lib64/libc.so.6
    dk#6  0x000003fff7a3b400 in __memset_chk () at /lib64/libc.so.6
    dk#7  0x000003fff6ea4cce in bzero
        (__len=<optimized out>, __dest=0x580d3f50ee0, __dest=<optimized out>, __len=<optimized out>)
        at /usr/include/bits/strings_fortified.h:32
    dk#8  prima_fc_fonts (array=<optimized out>, facename=0x0, encoding=0x0, retCount=0x3ffffff929c)
        at unix/fontconfig.c:610
    dk#9  0x000003fff6dbd68e in Application_fonts
        (self=2929175997600, name=0x2aa007a31e0 "", encoding=0x2aa005d19b0 "") at class/Application.c:310
    dk#10 0x000003fff6dd1234 in Image_fonts_FROMPERL (my_perl=<optimized out>, cv=<optimized out>)
        at include/generic/Image.inc:375
    dk#11 0x000003fff7c4a69a in Perl_pp_entersub () at /lib64/libperl.so.5.38
    dk#12 0x000003fff7c3a6f2 in Perl_runops_standard () at /lib64/libperl.so.5.38
    dk#13 0x000003fff7b7b994 in perl_run () at /lib64/libperl.so.5.38
    dk#14 0x000002aa000013ae in main ()

There were two issues: prima_fc_fonts(..., int *retCount) incorrectly
updated its last argument. Next, when called again, it used this wrong
argument to compute how much memory will be allocated. However, during
this computation an integer could overflow. Then not enough memory
could be allocated, and finally bzero() could be asked to zero
a memory beyond that allocation.

This patch fixes both issues.

CPAN RT#151594
ppisar added a commit to ppisar/Prima that referenced this pull request Feb 6, 2024
@ppisar
Fix memory handling in prima_fc_fonts()
4000a7d 
t/Image/Text.t frequently aborted with "buffer overflow detected" on
i686 and s390x platforms:

    #0  0x000003fff79ae3ca in __pthread_kill_implementation () at /lib64/libc.so.6
    dk#1  0x000003fff7954460 in raise () at /lib64/libc.so.6
    dk#2  0x000003fff793449c in abort () at /lib64/libc.so.6
    dk#3  0x000003fff79a0a2a in __libc_message_impl () at /lib64/libc.so.6
    dk#4  0x000003fff7a3aadc in __fortify_fail () at /lib64/libc.so.6
    dk#5  0x000003fff7a3a368 in __chk_fail () at /lib64/libc.so.6
    dk#6  0x000003fff7a3b400 in __memset_chk () at /lib64/libc.so.6
    dk#7  0x000003fff6ea4cce in bzero
        (__len=<optimized out>, __dest=0x580d3f50ee0, __dest=<optimized out>, __len=<optimized out>)
        at /usr/include/bits/strings_fortified.h:32
    dk#8  prima_fc_fonts (array=<optimized out>, facename=0x0, encoding=0x0, retCount=0x3ffffff929c)
        at unix/fontconfig.c:610
    dk#9  0x000003fff6dbd68e in Application_fonts
        (self=2929175997600, name=0x2aa007a31e0 "", encoding=0x2aa005d19b0 "") at class/Application.c:310
    dk#10 0x000003fff6dd1234 in Image_fonts_FROMPERL (my_perl=<optimized out>, cv=<optimized out>)
        at include/generic/Image.inc:375
    dk#11 0x000003fff7c4a69a in Perl_pp_entersub () at /lib64/libperl.so.5.38
    dk#12 0x000003fff7c3a6f2 in Perl_runops_standard () at /lib64/libperl.so.5.38
    dk#13 0x000003fff7b7b994 in perl_run () at /lib64/libperl.so.5.38
    dk#14 0x000002aa000013ae in main ()

prima_fc_fonts(..., int *retCount) uses *retCount argument to compute
how much memory will be allocated. However, if value of this argument
is too big, during this computation an integer could overflow. Then
not enough memory could be allocated, and finally bzero() could be
asked to zero a memory beyond that allocation.

This patch fixes the overflow. Why the argument is insantely large is
not clear yet.

CPAN RT#151594
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@run4flat @dk