Can you provide us with a stack trace?  (See
http://bugzilla.gnome.org/getting-traces.cgi for instructions on how
to do so).

I forgot to mention that I have an SMP system. (kernel
2.4.22-1.2129.nptlsmp)

This is the backtrace generated by Bug-Buddy:

Backtrace was generated from '/home/garnome/GARNOME/bin/gnome-panel'

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1085058400 (LWP 4734)]
0x00424c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

+ Trace 42467

I can't reproduce.
Does it happen with other PNG files? If not, can you attach your PNG
to this bug?
Thanks

Created attachment 22384 [details]
PNG, compression level 6

The PNG's from http://www.libpng.org/pub/png/png-sitemap.html#images
work fine. The attached PNG is made with Gimp 1.2.5 and saved in
1.3.22. I also tried to save it in 1.2.5 (Linux) and 1.3.23 (Win32),
all resulting in the broken behaviour. I tried different compression
levels (0, 1, 6 and 9) and options, and I resized the image to
320x240, but they all let the panel crash.

the 'pngcheck' tool from libpng.org gives no error messages or
warnings on these files. Mozilla also renders the png's without problems.

I also tried to create some other images, convert jpg's and bmp's to
png with The Gimp, but that gave different results. Some were good,
some were bad. I couldn't find a pattern in the behaviour.

I can reproduce the stack trace with the attached image and the given
duplication instructions.  Reopening and adding the STACKTRACE and
bugsquad keywords.

I can recreate this bug on my Gnome 2.5 builded with the breakmygentoo
ebuilds.

Here is my systems information :

Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3,
2.6.0-thebest-te
st11)
=================================================================
System uname: 2.6.0-thebest-test11 i686 AMD Athlon(tm) XP 1800+
Gentoo Base System version 1.4.3.10p1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-mcpu=athlon-xp -O2 -m3dnow -pipe -mmmx -s"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config
/usr/kde/3/share
/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config
/usr/share/texmf/tex/ge
neric/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS="-mcpu=athlon-xp -O2 -m3dnow -pipe -mmmx -s"
DISTDIR="/opt/packages"
FEATURES="sandbox ccache autoaddcvs"
GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo
ftp://gento
o.linux.no/pub/gentoo/ http://gentoo.linux.no/
http://212.219.56.162/sites/www.i
biblio.org/gentoo/ http://212.219.56.152/sites/www.ibiblio.org/gentoo/
http://21
2.219.56.146/sites/www.ibiblio.org/gentoo/
http://212.219.56.131/sites/www.ibibl
io.org/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg libg++ mad
mikmod mpe
g ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib
directfb gtk
html alsa gdbm berkdb slang readline arts tetex aalib bonobo svga
tcltk java gui
le ruby mysql postgres X sdl gpm tcpd pam libwww ssl perl python esd
imlib oggvo
rbis gnome gtk qt kde motif opengl mozilla ldap cdr scanner"

- libpng-1.2.5-r4
- gtk+-2.3.0-r1
- Xfree-4.3.99.901

Gnome 2.5 emerged like this :
USE="doc tiff ipv6" ACCEPT_KEYWORDS="~x86" emerge -v gnome

I'll file the backtrace too so you can compare.

Created attachment 22386 [details]
Gnome-panel stack trace given by bug-buddy

So so so,

It's not the format, it could crash with a JPG file but the bug report
is not really complete because sometimes you can do this without any
crash.

By the way I've push the transparency of the panel at nearly 90% (So
you can just see a small difference between the picture and the
translucent area.
The color of tinting is "black"

I've the last gtk+/glib/pango.

When the panel crashes the transparency is not updated.

More informations :

- I can change the background using the Gnome Desktop Preferences.
- I can change the background using Galeon too (Galeon 1.3.10)

Okay, I've spent quite a while staring at this:

  1) I can't reproduce it
  2) It looks very like an old zvt crasher - bug #75340
  3) It doesn't make any sense - _gdk_x11_copy_to_image does CreateGC,
     CopyArea, Sync, FreeGC and yet we get a BadGC from CopyArea. No matter
     what way I look at it I can't see a reason for the GC to be invalid
  4) I'm leaning towards thinking this is possibly an Xlib/Xserver bug, but
     can't confirm that without more details

So, I'm attaching a test case. You can compile it like so:

  gcc $(pkg-config --cflags --libs gtk+2.0) panel-background-monitor.c -o panel-background-monitor

then just run it and change the desktop background as you were before.

This should blow up in exactly the same way as the panel. If it does, get
a stace trace and then try again to get a stack trace running it with --sync.
Also, once you've confirmed that you can reproduce it with the test case
I'd appreciate it if you could re-compile gtk with this change to gtk+/gdk/gdkimage.c:

diff -u -p -r1.34 gdkimage.c
--- gdkimage.c  6 Mar 2004 03:36:59 -0000       1.34
+++ gdkimage.c  24 Mar 2004 15:49:14 -0000
@@ -282,6 +282,7 @@ scratch_image_info_for_depth (GdkScreen
  
 #undef NO_FLUSH
  
+#define VERBOSE
 #ifdef VERBOSE
 static gint sincelast;
 #endif



Also, if you could tell me what X11 distribution you are using and what version, that'd be very useful too.

Don't worry if you can't do all of the above - any information is useful. Thanks

Created attachment 25918 [details]
test case

If I run the test case through gdb, it does something interesting (details
below) on the first drag & drop, as  opposed to the regular case, where I
typically need to do it a bunch of times before I trigger whatever presumed race
is causing this.  Seems to be pretty independent of the image.  Rebuilding gtk+
is going to be a bit of a PITA, since I'm working from binary rpms for which I
do not have source packages handy.

XFree86-4.3.99.902 (server & libs, same box), i180 driver for the server.

The test program exits rather than crashing, saying:

_XROOTPMAP_ID changed
Successfully obtained the foreign pixmap
The program 'panel-background-monitor' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 93 error_code 9 request_code 55 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.)

Here's a stack trace from running with --sync, having put a breakpoint in
gdk_x_error, as the debug spewage instructed:

Breakpoint 2, 0x40342256 in gdk_x_error ()
   from /opt/gnome/lib/libgdk-x11-2.0.so.0
(gdb) bt

+ Trace 47135

Sorry about the question marks.

Another stack trace, with the GTK+ debuginfo RPM. I need to recompile GTK+ on
this computer with the #define, but I can't right now.

_XROOTPMAP_ID changed
Successfully obtained the foreign pixmap
 
Breakpoint 2, gdk_x_error (display=0xfefad8b0, error=0xfefad8b0)
    at gdkmain-x11.c:503
503       if (error->error_code)
(gdb) bt

+ Trace 49397

And its BadGC you're seeing, not BadDrawable? Strange.

My guess is that BadGC is being incorrectly reported somehow - BadDrawable makes
a lot more sense if you're changing the background image.

We should just trap and ignore this error in get_pixbuf_from_pixmap() I think -
i.e. use gdk_error_trap_push()/pop()

Mark: with your test case, I'm getting a BadDrawable. I had BadGC when testing
with the panel...

Here's the output with the VERBOSE in gdkimage.c:

_XROOTPMAP_ID changed
Successfully obtained the foreign pixmap
flush, 6 puts since last flush
index 0, x 0, y 0 (256 x 64)
index 1, x 256, y 0 (256 x 64)
index 2, x 512, y 0 (256 x 64)
index 3, x 768, y 0 (256 x 64)
index 4, x 1024, y 0 (256 x 64)
index 5, x 1280, y 0 (256 x 64)
flush, 6 puts since last flush
index 0, x 0, y 0 (256 x 64)
index 1, x 256, y 0 (256 x 64)
index 2, x 512, y 0 (256 x 64)
index 3, x 768, y 0 (256 x 64)
index 4, x 1024, y 0 (256 x 64)
index 5, x 1280, y 0 (256 x 64)
flush, 6 puts since last flush
index 0, x 0, y 0 (256 x 64)
index 1, x 256, y 0 (256 x 64)
index 2, x 512, y 0 (256 x 64)
index 3, x 768, y 0 (256 x 64)
index 4, x 1024, y 0 (256 x 64)
index 5, x 1280, y 0 (256 x 64)
flush, 6 puts since last flush
index 0, x 0, y 0 (256 x 64)
index 1, x 256, y 0 (256 x 64)
index 2, x 512, y 0 (256 x 64)
index 3, x 768, y 0 (256 x 64)
index 4, x 1024, y 0 (256 x 64)
index 5, x 1280, y 0 (256 x 64)
flush, 6 puts since last flush
index 0, x 0, y 0 (256 x 64)
index 1, x 256, y 0 (256 x 64)
index 2, x 512, y 0 (256 x 64)
index 3, x 768, y 0 (256 x 64)
index 4, x 1024, y 0 (256 x 64)
index 5, x 1280, y 0 (256 x 64)
flush, 6 puts since last flush
index 0, x 0, y 0 (256 x 64)
index 1, x 256, y 0 (256 x 64)
index 2, x 512, y 0 (256 x 64)
The program 'panel-background-monitor' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 1036 error_code 9 request_code 55 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.)

Created attachment 30694 [details] [review]
possible patch

We could try something like this, but I think we need to handle the error
better - e.g. don't free the previous background until we successfully grab the
new background.

Could you take a look Vincent?

Hrm... It's crashing with this patch too. But a bit less often :-)

In fact, the stack trace is not the same:

+ Trace 49426

FWIW,
i've tried this to consistently get a crash:

- Set panel to complete transparency
- Right click on desktop & change desktop backgrounds rapidly.

*** Bug 157541 has been marked as a duplicate of this bug. ***

Created attachment 34858 [details] [review]
proposed patch

It looks like gdk_pixbuf_get_from_drawable function is the culprit. This patch
just replaces the single call to gdk_pixbuf_get_from_drawable with equivalent
calls to gdk_drawable_get_image and then gdk_pixbuf_get_from_image. This
removes the crash. I similarly replaced gdk_pixbuf_get_from_drawable function
in Mark McLoughlin's testcase program and observed that the crash was gone in
test case program too...

That's interesting. It's probably a bug in gdk_pixbuf_get_from_drawable(), then.
Could you write a small test so we can show this to GTK+ people?

Comment on attachment 34858 [details] [review]
proposed patch

Marking as needs-work since it looks like a GTK+ bug.

Occassionally I can produce a gnome-panel crash (or at least a conflict, as it
says "gnome-panel already running") with the rightclick->'change desktop
background' dialog and then changing *from* a PNG to a JPEG file, contrary to
the bug details at the top.

I couldn't reproduce it when I made the panels opaque, so I thought it was
probably closely related to this bug.

I'm using Debian Testing (Sarge) which has gnome-panel 2.8.2. 

I'll attach the bug-buddy gnome-panel backtrace and the JPEG. The PNG is
generated by the following script:

#!/bin/bash
#xplanet-gnome.sh shell script v0.2
#shows Earth on your Gnome desktop with current lighting conditions,i.e. day and
night
DELAY=30m
PREFIX=/home/pete/multimedia/wallpapers/
OUTPUT=xplanet.png
APPEND=2
GEOMETRY=1024x768
LONGITUDE=0
LATITUDE=35
#default is no projection,i.e. render a globe
#rectangular is the flat world map. also try ancient, azimuthal,  mercator,..
#PROJECTION=rectangular  
#rename background image so Gnome realises image has changed - thx to dmbasso
if [ -e "$PREFIX$OUTPUT" ]; then
   rm "$PREFIX$OUTPUT"
   OUTPUT="$APPEND$OUTPUT"
else
   rm "$PREFIX$APPEND$OUTPUT"
fi
if [ -z $PROJECTION ]; then 
xplanet -num_times 1 -output "$PREFIX$OUTPUT" -geometry $GEOMETRY -longitude
$LONGITUDE -latitude $LATITUDE -label -radius=55 
else
xplanet -num_times 1 -output "$PREFIX$OUTPUT" -geometry $GEOMETRY -longitude
$LONGITUDE -latitude $LATITUDE -projection $PROJECTION -label -radius=55
fi
#update Gnome backgound
gconftool -t str -s /desktop/gnome/background/picture_filename "$PREFIX$OUTPUT"
sleep $DELAY
exec $0

Created attachment 36004 [details]
gnome-panel backtrace

gnome-panel backtrace of changing from PNG to JPEG background whilst panels are
transparent

Couldn't upload the big JPEG, so here's the link:
www.cetis.hvu.nl/~pete/images/mars.jpg

I've this crash with 2.9.90 too. The gdk_pixbuf_get_from_drawable () to
gdk_drawable_get_image ()/gdk_pixbuf_get_from_image () change from 34858 fixes
the issue.

34858? That bug doesn't exist...

Luis: Sebastien was talking about patch 34858 ;-)

Ah, the needs-work because it is a workaround patch? Can we just go around and
commit it, and get on the gtk guys to fix their bug?

Luis: I'll probably go this way. But I'd prefer if the GTK+ bug could be fixed...

What is the gtk bug #, for reference?

Hrm... I don't think I ever opened a bug against GTK+. I did not look a lot at
this bug since I asked Venkatesan if he could write a small testcase. I should
have come back to it sooner :/

Note that this crash doesn't happen when running inside xnest. This is why I
could never reproduce it...

New up to date stack trace:

gdb /gnome/usr/bin/gnome-panel

(gdb) br gdk_x_error
Breakpoint 1 at 0xb7a03d22: file gdkmain-x11.c, line 505.
(gdb) run --sync
Starting program: /gnome/usr/bin/gnome-panel --sync
[Thread debugging using libthread_db enabled]
[New Thread -1223408992 (LWP 28445)]
[New Thread -1231905872 (LWP 28456)]

+ Trace 56264

Here's the X error:

The program 'gnome-panel' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadGC (invalid GC parameter)'.
  (Details: serial 3126 error_code 13 request_code 60 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.)

Created attachment 38081 [details] [review]
Proposed patch

This patch seems to fix the problem.
We now grab the server before doing the work.
The patch also changes the behaviour so that it works on multiple display...

Well, the changes for multiple displays won't change a lot of things because of
this:
  n_screens = gdk_display_get_n_screens (gdk_display_get_default ());
But I don't think it will harm us.

Created attachment 38083 [details] [review]
Updated patch

We need to check if gdk_pixbuf_get_from_drawable() returns NULL too

This should now be fixed in HEAD. I'll release 2.9.92 now so people can test.