Bug 429218 - xchat crashes when transparent background enabled
xchat crashes when transparent background enabled
Product: Fedora
Classification: Fedora
Component: xchat (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Kevin Kofler
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-17 18:33 EST by Jason Farrell
Modified: 2008-01-19 01:10 EST (History)
3 users (show)

See Also:
Fixed In Version: 1:2.8.4-11.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-19 01:10:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backtrace (1.95 KB, application/octet-stream)
2008-01-17 19:16 EST, Jason Farrell
no flags Details
backtrace --sync (4.39 KB, text/plain)
2008-01-18 02:59 EST, Jason Farrell
no flags Details

  None (edit)
Description Jason Farrell 2008-01-17 18:33:52 EST
Description of problem:
xchat as of xchat-2.8.4-10.fc8 crashes when the transparent background is
enabled. It had been working fine for many versions previous.

Version-Release number of selected component (if applicable):

How reproducible:
in kde & gnome. no compiz.

Steps to Reproduce:
1. Choose Settings > Preferences, and enable the 'Transparent Background' checkbox.
2. Click OK.
Actual results:
xchat will crash, and continue to crash upon startup, until "text_transparent"
in ~/.xchat/xchat.conf is reset to 0.

Expected results:
transparent bg showing through as always.

Additional info:
[foobar@nano ~]$ xchat

Gdk-ERROR **: The program 'xchat' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
  (Details: serial 42289 error_code 4 request_code 54 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
51787039-0432-9541-4de8a05a-79d5540b is dumped

Would appear to be related to changes here:
* Thu Dec 20 2007 Adam Jackson <ajax@redhat.com> 1:2.8.4-9
- xchat-2.8.4-shm-pixmaps.patch: MIT-SHM pixmaps are optional, and when
  using EXA they are not available.  Check that the server supports them
  before trying to create them so we don't crash.
Comment 1 Kevin Kofler 2008-01-17 18:41:35 EST
Ajax, it looks like your patch caused this regression. Any idea what's 
happening here?
Comment 2 Kevin Kofler 2008-01-17 18:49:16 EST
I unpushed this update for now, I'll push one with only the scrollbfdleak fix 
for now.
Comment 3 Jason Farrell 2008-01-17 19:16:38 EST
Created attachment 292090 [details]
Comment 4 Kevin Kofler 2008-01-18 02:48:50 EST
Sorry, but that backtrace is not usable. As the message says, you have to use 
the --sync option, i.e. "gdb --args xchat --sync".
Comment 5 Jason Farrell 2008-01-18 02:59:50 EST
Created attachment 292112 [details]
backtrace --sync
Comment 6 Adam Jackson 2008-01-18 19:43:23 EST
(In reply to comment #1)
> Ajax, it looks like your patch caused this regression. Any idea what's 
> happening here?

Eek, yeah.  I braino'd that patch.  Fix the declaration "Bool have = FALSE;" to
be "static Bool have = FALSE;" and it should work fine.
Comment 7 Kevin Kofler 2008-01-19 01:10:15 EST
Oh, that was a nasty, easy to overlook bug. Thanks for the fix! I applied it to 
the Rawhide xchat and I'll push new builds to F7/F8 updates-testing shortly.

Marking this CLOSED / RAWHIDE right now because the F7/F8 builds never made it 
beyond testing.

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