Bug 435719 - pixel 0 releases black color(0,0,0) by setting color depth to 8bit on RHEL4
pixel 0 releases black color(0,0,0) by setting color depth to 8bit on RHEL4
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xorg-x11-server (Show other bugs)
7.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: Adam Jackson
Desktop QE
: Triaged
Depends On:
Blocks: 1203710 1205791 1295825 485811
  Show dependency treegraph
 
Reported: 2008-03-03 10:18 EST by Alan Matsuoka
Modified: 2016-12-01 11:36 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-01 11:36:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sysreport (292.24 KB, application/x-bzip2)
2008-03-03 10:18 EST, Alan Matsuoka
no flags Details
test programs (10.00 KB, application/x-tar)
2008-03-03 10:19 EST, Alan Matsuoka
no flags Details
results (14.80 KB, text/plain)
2008-03-03 10:19 EST, Alan Matsuoka
no flags Details
xorg.conf from sosreport. (4.17 KB, text/plain)
2008-03-03 18:50 EST, Matěj Cepl
no flags Details
Xorg.0.log from sosreport. (22.04 KB, text/plain)
2008-03-03 18:50 EST, Matěj Cepl
no flags Details

  None (edit)
Description Alan Matsuoka 2008-03-03 10:18:08 EST
*Description of problem:

In the default colormap, pixel 0 refers to black
color(0,0,0). However, pixel 0 refers to the other color
after my customer did the following operation.

1. Set the color depth to 8bit on RHEL4

2.Run XAllocNamedColor( dsp, cmap, "black", &color, &exact )
 more than 32768 times, reference to black pixel shift to
 other pixel number that is not 0.

3. Runs XAllocNamedColor with other color, pink for example,
  RGB value of pixel 0 becomes the RGB value for pink. Thus
  pixel 0 released black(0,0,0). This will show pink where
  black should show in your screen.


*How reproducible:
Always.


*Steps to Reproduce:

The customer gave us the test program to reproduce this(See the attachment -
test_program.tar). Do the following.

1. Set the color depth to 8bit on RHEL4

2. Compile dumpcolor.c/allocblack.c/allocpink.c as follows.

  gcc dumpcolor.c -lX11 -L /usr/X11R6/lib -o dumpcolor
  gcc allocblack.c -lX11 -L /usr/X11R6/lib -o allocblack
  gcc allocpink.c -lX11 -L /usr/X11R6/lib -o allocpink

3. Start X with mwm window manager -> xinit -e mwm

4. Run ./dumpcolor :0.0 0

5. Run ./allocblack :0.0 40000
  -> At this stage, pixel 0 refers to the other pixel

6. Run ./allocpink :0.0
  -> RGB of pink is placed in pixel 0

7. Run ./dumpcolor to see that pixel 0 now refers to RGB of
  pink.


*Actual results:
pixel 0 refers to the other color.


*Expected results:
pixel 0 should refer to black color(0,0,0).


*Additional info:
This only occurs in color depth of 8bit.

We have posted this issue to xgl-devel@redhat.com and got the
following reply.

-------------------------------------------------------------
Subject:
Re: Pixel 0 shows RGB value thats are not black(0.0,0) with 8bit depth on RHEL4
From:
Adam Jackson <ajackson@redhat.com>
Date:
Tue, 26 Feb 2008 12:13:26 -0500
To:
xgl-devel@redhat.com
CC:
Kenji Suzuoki <ksuzuoki@redhat.com>

On Tue, 2008-02-26 at 17:51 +1000, Kenji Suzuoki wrote:
> > Hi there,
> >
> > A customer is asking if it is a X's bug that pixel 0 releases black
> > color(0,0,0) after certain condition.
> >
> > Setting color depth to 8bit on RHEL4, then run
> >
> > XAllocNamedColor( dsp, cmap, "black", &color, &exact ) ;
> >
> > more than 32768 times, reference to black pixel shift to other pixel
> > number that is not 0.
> >
> > After that if he runs XAllocNamedColor with other color, pink for
> > example, RGB value of pixel 0 becomes the RGB value for pink. Thus
> > pixel 0 released black(0,0,0).
> >
> > [ Questions ]
> > -----------------------------------------------------------------------
> > 1. Is this a bug ?

Yes.  Yes, very much so.

Colormap slots have reference counts, so that when the client holding
that slot dies, it releases any slots it was holding on to.  The
reference count happens to be a short int.  D'oh.  (Not even unsigned
short!  Oh man.)

> > 2. Does RHEL4 support 8bit depth ?

Yes.
-------------------------------------------------------------

*Attachment
sysreport - RHEL4UP4.tar.bz2
test program - test_program.tar
result - our test result using the test program
Comment 1 Alan Matsuoka 2008-03-03 10:18:08 EST
Created attachment 296616 [details]
sysreport
Comment 2 Alan Matsuoka 2008-03-03 10:19:00 EST
Created attachment 296617 [details]
test programs
Comment 3 Alan Matsuoka 2008-03-03 10:19:26 EST
Created attachment 296618 [details]
results
Comment 4 Matěj Cepl 2008-03-03 18:50:31 EST
Created attachment 296690 [details]
xorg.conf from sosreport.
Comment 5 Matěj Cepl 2008-03-03 18:50:36 EST
Created attachment 296691 [details]
Xorg.0.log from sosreport.
Comment 8 RHEL Product and Program Management 2009-03-12 14:55:25 EDT
Since RHEL 4.8 External Beta has begun, and this bugzilla remains 
unresolved, it has been rejected as it is not proposed as exception or 
blocker.
Comment 11 RHEL Product and Program Management 2010-10-22 14:56:33 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 12 Adam Jackson 2012-04-17 15:13:58 EDT
The issue underlying this bug is still present in upstream Xorg.  No further non-security updates are planned to X for RHEL4, so I'm retargeting this bug for RHEL7 development.  Once and if fixed there it may be possible include this fix in a future RHEL6 backport.  However, RHEL5's X server is ABI-frozen so this can not be fixed there.

Note You need to log in before you can comment on or make changes to this bug.