After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 164940 - gdk_rgb_preprocess_dm_565 should use .rodata section
gdk_rgb_preprocess_dm_565 should use .rodata section
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.4.x
Other All
: Normal normal
: Small fix
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-01-22 21:32 UTC by Ben Maurer
Modified: 2005-03-10 15:18 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
A little program to generate the stuff needed (63.34 KB, text/x-csrc)
2005-02-02 02:05 UTC, Ben Maurer
  Details
The generated array as a diff (139.32 KB, patch)
2005-02-06 20:52 UTC, Tommi Komulainen
none Details | Review

Description Ben Maurer 2005-01-22 21:32:13 UTC
Please describe the problem:
The code for gdk_rgb_preprocess_dm_565 contains:

static void
gdk_rgb_preprocess_dm_565 (void)
{
  int i;
  guint32 dith;

  if (DM_565 == NULL)
    {
      DM_565 = g_new (guint32, DM_WIDTH * DM_HEIGHT);

The data entered into the array is constant. It should be declared as a const
array with the values precomputated, so that you don't have to malloc for everyone. 

Steps to reproduce:
Run valgrind on an application that hits this spot, use --show-reachable=yes.

Actual results:
==26327== 65536 bytes in 1 blocks are still reachable in loss record 13948 of 13952
==26327==    at 0x3414A584: malloc (in /usr/lib/valgrind/vgpreload_addrcheck.so)
==26327==    by 0x341A0E86: g_malloc (in /opt/gnome/lib/libglib-2.0.so.0.400.6)
==26327==    by 0x357E25CD: gdk_rgb_preprocess_dm_565 (gdkrgb.c:1114)
==26327==    by 0x357E57F3: gdk_rgb_select_conv (gdkrgb.c:2919)
==26327==    by 0x357E1E5D: gdk_rgb_create_info (gdkrgb.c:678)
==26327==    by 0x357E1F64: gdk_rgb_get_info_from_colormap (gdkrgb.c:716)
==26327==    by 0x357E1FA1: gdk_rgb_xpixel_from_rgb_internal (gdkrgb.c:727)
==26327==    by 0x357E22F7: gdk_rgb_find_color (gdkrgb.c:825)

Expected results:
No such allocation

Does this happen every time?
Yes

Other information:
Comment 1 Federico Mena Quintero 2005-02-02 01:25:47 UTC
Nice catch.  Care to give us a patch? :)
Comment 2 Ben Maurer 2005-02-02 02:05:18 UTC
Created attachment 36851 [details]
A little program to generate the stuff needed

This will generate the arrays, so you can copy and paste this in. I have not
tested that this actually works, but I see no reason it wouldn't
Comment 3 Tommi Komulainen 2005-02-06 20:52:26 UTC
Created attachment 37069 [details] [review]
The generated array as a diff

Here's a diff of the generated array inserted in the source (gtk 2.4.14)  There
were two instances which needed an additional 'const' to compile with the const
array, but those instances should've had the 'const' all along.

The precalculated array is inside '#if 1' just in case, with an additional
#define to make gdk_rgb_preprocess_dm_565() a no-op.
Comment 4 Federico Mena Quintero 2005-02-22 19:31:09 UTC
Thanks for the patch, Tommi!  I modified it a bit, included the preprocessed
array for the 8x8 matrix, and committed it to CVS (HEAD and gtk-2-6).