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.

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

Minor changes for Mac OSX to compile without warnings and Fontconfig ... #12

Closed
wants to merge 1 commit into from

Conversation

vikasnkumar
Copy link
Contributor

  • Compile warnings for size differences between a possible pointer which could be 64-bit to a 32-bit number.
  • Fontconfig correction as suggested by Dmitry.

@dk
Copy link
Owner

dk commented Jan 11, 2014

I don't like this diff .. I don't understand the first double typecast, it looks wrong to me . The second diff is also wrong, NEED_EXPLICIT_FC_SCALABLE is needed for the older FC version, not for the newer ones.

@dk dk closed this Jan 11, 2014
@vikasnkumar
Copy link
Contributor Author

On 01/11/2014 04:59 PM, Dmitry Karasik wrote:

I don't like this diff .. I don't understand the first double
typecast, it looks wrong to me . The second diff is also wrong,
NEED_EXPLICIT_FC_SCALABLE is needed for the older FC version, not for
the newer ones.


Reply to this email directly or view it on GitHub
#12 (comment).

I agree. But when I set it this way the FontConfig warnings stop
happening. Maybe it is just the behaviour of the MacPorts install of
fontconfig and I have ignored it so far. It doesn't matter much as I
just redirect STDERR to /dev/null.

gcc gives the following warning:

img/codec_Xpm.c:210: warning: cast from pointer to integer of different size
img/codec_Xpm.c:219: warning: cast to pointer from integer of different size

I have a 64-bit Mac. So a pointer is 64-bits. uintptr_t refers to an
unsigned int of 64-bits and is a typecast to convert a pointer to an
integer value without issuing a warning. Then I convert that to the
Color type which is a uint32_t. That's why the double type cast.
Converting a 32-bit integer to a 64-bit pointer will inevitably lead to
problems.

I am not sure if I saw this on Linux. the Mac OSX, even though they call
it Unix, is a weird Unix and does some non-standard things.

You should see the amount of warnings spewed when the default C compiler
on the Mac "clang" is used.

I believe you should be able to see the same issues on a FreeBSD system
as it has clang as the default compiler or as an optional compiler. But
it is not important, I use gcc as the compiler by setting the CC
variable on the command line.

ppisar added a commit to ppisar/Prima that referenced this pull request Feb 6, 2024
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
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants