Notifications pixmaps are broken sometimes

[Roland Hieber]

Apparently, sometimes there is a problem with the pixmaps in notifications. I have enabled notifications for every tweet and message, and with about 75% of the displayed notifications, awesome (which implements the org.freedesktop.Notification service) will not display them and instead shows a red popup message reading:

  Oops, an error happened!
  /usr/share/awesome/lib/naughty.lua:520: string size does not match image size

Some notifications will be rendered as expected though. I have the feeling that it is related to the user avatars, as all the error messages are tweets from the same group of users, and the notifications which are displayed correctly are all messages from a disjoint set of users.

(I have not tested it with notify-osd or any other libnotify server implementation, so this could also be related to awesome. Maybe someone could say if the bug also occurs with other implementations.)

awesome:
  Installed: 3.4.12-2
  Candidate: 3.4.12-2
  Version table:
 *** 3.4.12-2 0
        500 http://debian.tu-bs.de/debian/ wheezy/main amd64 Packages
          1 http://debian.tu-bs.de/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status
polly:
  Installed: 0.93.4-0~401~precise1
  Candidate: 0.93.4-0~401~precise1
  Version table:
 *** 0.93.4-0~401~precise1 0
        500 http://ppa.launchpad.net/conscioususer/polly-daily/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status
python-notify:
  Installed: 0.1.1-3
  Candidate: 0.1.1-3
  Version table:
 *** 0.1.1-3 0
        500 http://debian.tu-bs.de/debian/ wheezy/main amd64 Packages
          1 http://debian.tu-bs.de/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status

[Conscious User (conscioususer)]

Marking as incomplete until someone can confirm the problem is not on awesome. I have never heard about this from users of other notification services.

Roland, maybe you could contact the awesome developers to learn what that line means?

[Roland Hieber (rohieb)]

Okay, today I monitored the DBUS interface with dbus-monitor [0] to get a better understanding what is going on here. According to the specification [1], the image data is sent as a byte array of raw pixel data (no compression, PNG, JPEG, GIF or whatever). In my dbus-monitor output, there were a few notifications with successfully displayed images, and the arrays there look like standard image date with red, green, blue and alpha bytes (see the first log file). However, the other notifications that were not rendered, showed somehow "random" image data, but everytime the same data for a Twitter handle [2]. Also, if you look closely at the icon_data field, the byte counts are wrong: according to the field, the byte array should have 54*54*3 bytes (width*height*bytes per pixel), but in the first two log entries, there is too much data (8854 instead of 8748 bytes, which is not even divisible by 3!)

I tried to understand the code that generates the notifications, but unfortunatenly I was not able to understand it completely, nor do I see where it goes wrong. Perhaps the error is also in the notifcation library.

 0: $ dbus-monitor "sender=:1.122, interface=org.freedesktop.Notifications" # where sender=:1.122 was the Polly instance
 1: http://developer.gnome.org/notification-spec/#icons-and-images-formats
 2: Twitter handles and first line of "random" image data, from the second log file:
    $ grep -B 1 -A 15 'censored' polly-notifications-fail.log | grep -e "^ string " -e '^ ' |grep -v censored
   string "qnavry_obuere"
                  2f 3f 61 30 40 62 32 42 64 32 42 64 30 40 62 2f 3f 61 2f 3f
   string "qnavry_obuere"
                  2f 3f 61 30 40 62 32 42 64 32 42 64 30 40 62 2f 3f 61 2f 3f
   string "qnavry_obuere"
                  2f 3f 61 30 40 62 32 42 64 32 42 64 30 40 62 2f 3f 61 2f 3f
   string "papierschiff_"
                  fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe ff ff ff ff ff
   string "papierschiff_"
                  fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe ff ff ff ff ff
   string "scy"
                  dc 7a 24 dc 7a 20 dc 7a 20 dd 79 21 df 7c 22 e3 80 22 ec 8b
   string "Meeresbraut"
                  1f 20 24 1e 1f 23 1e 1f 23 1e 1e 20 1d 1d 1f 1c 1c 1e 19 19
   string "Meeresbraut"
                  1f 20 24 1e 1f 23 1e 1f 23 1e 1e 20 1d 1d 1f 1c 1c 1e 19 19
   string "larsan"
                  f0 f1 f3 f1 f2 f4 f1 f2 f4 f2 f3 f5 f2 f3 f5 f3 f4 f6 f3 f4
   string "felis_blue"
                  00 02 06 01 00 05 03 00 04 01 01 03 00 02 01 00 03 01 02 01
   string "felis_blue"
                  00 02 06 01 00 05 03 00 04 01 01 03 00 02 01 00 03 01 02 01
   string "Meeresbraut"
                  1f 20 24 1e 1f 23 1e 1f 23 1e 1e 20 1d 1d 1f 1c 1c 1e 19 19
   string "scy"
                  dc 7a 24 dc 7a 20 dc 7a 20 dd 79 21 df 7c 22 e3 80 22 ec 8b
   string "felis_blue"
                  00 02 06 01 00 05 03 00 04 01 01 03 00 02 01 00 03 01 02 01
   string "felis_blue"
                  00 02 06 01 00 05 03 00 04 01 01 03 00 02 01 00 03 01 02 01
   string "papierschiff_"
                  fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe ff ff ff ff ff

[Conscious User (conscioususer)]

Nice investigation! The technicalities here are kinda over my head, but the data seems indeed completely corrupt.

I'm going to shoot in the dark and guess this has something to do with thread-safety. Libnotify is a glib-based library but in the current code I'm calling it directly without using the Gdk lock or inserting it into the main glib thread. I'm not sure I'm allowed to do that.

The next version of Polly throw notifications from the main thread, so it will be interesting to see if the issue remains.

[Conscious User (conscioususer)]

I forgot a "will" before the "throw" in the last sentence. Just to be clear, the next version is not ready yet.