awesome | 18 Apr 20:57 2014

[awesome bugs] #1259 - Random Cairo assert

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1259 - Random Cairo assert
User who did this - Emmanuel Lepage Vallee (Elv13)

----------
It make the problem worst. Awesome now crash almost everytime I unfocus soemthing... Same backtrace

awesome: cairo-surface.c:905: cairo_surface_reference: Assertion
`((*&(&surface->ref_count)->ref_count) > 0)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff489d0d9 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff489d0d9 in raise () from /lib64/libc.so.6
#1  0x00007ffff489e438 in abort () from /lib64/libc.so.6
#2  0x00007ffff4896276 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff4896322 in __assert_fail () from /lib64/libc.so.6
#4  0x00007ffff571b558 in *INT_cairo_surface_reference (surface=0x852ce0) at cairo-surface.c:905
#5  0x00007ffff5794c91 in INT_cairo_surface_reference (surface=surface <at> entry=0x852ce0) at cairo-surface.c:900
#6  0x00007ffff5773068 in _cairo_pattern_init_for_surface (surface=0x852ce0, pattern=0xace4c0) at cairo-pattern.c:555
#7  INT_cairo_pattern_create_for_surface (surface=0x852ce0) at cairo-pattern.c:748
#8  0x00007ffff2b6ae5c in ffi_call_unix64 () from /usr/lib64/libffi.so.6
#9  0x00007ffff2b69fb8 in ffi_call () from /usr/lib64/libffi.so.6
#10 0x00007fffe65098bd in callable_call (L=0x40000378) at callable.c:883
#11 0x00007ffff4e5cc8b in lj_BC_FUNCC () from /usr/lib64/libluajit-5.1.so.2
#12 0x00007ffff4e70690 in lua_pcall () from /usr/lib64/libluajit-5.1.so.2
#13 0x000000000042779a in luaA_dofunction (nret=0, nargs=1, L=0x40000378) at /home/kde-devel/kde/src/awesome/common/lualib.h:75
(Continue reading)

awesome | 18 Apr 11:23 2014

[awesome bugs] #1259 - Random Cairo assert

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1259 - Random Cairo assert
User who did this - Uli Schlachter (psychon)

----------
You have a bad timing. I recently rewrote quite some code for client icons and thus thought the bug must have
been in there. However, that code isn't in master and I was just confused...

If you want to try something random, edit objects/client.c, function luaA_client_get_icon and replace
lua_pushlightuserdata(L, cairo_surface_reference(c->icon)); with lua_pushlightuserdata(L, draw_dup_image_surface(c->icon));.
That way the C code creates a copy of the client's icon and returns that to lua instead of just getting another
reference to the already-used surface.

This should help with "The only logic here is that blind is so much of a hack that it prevent Lua for GC-ing icon
surfaces, so the problem is somewhere else, but cannot happen due to Blind keeping its caches.".
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1259#comment4014

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 18 Apr 08:02 2014

[awesome bugs] #1259 - Random Cairo assert

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1259 - Random Cairo assert
User who did this - Emmanuel Lepage Vallee (Elv13)

----------
Yep, I confirm it is related to the client icons...

The problem is that the _less_ code I have, the _more_ problems occur, this doesn't make any sense...

The problem is related to me removing the old "blind" module (the one with tons of cairo code to draw
awful.widgets from scratch). If I remove the module, I have the problem. If I restore it, it is  "fixed" and
my awesome works again... If I simply remove the code using the c.icon (and display no icons), the assert
happen again. This is totally illogical. The only logic here is that blind is so much of a hack that it
prevent Lua for GC-ing icon surfaces, so the problem is somewhere else, but cannot happen due to Blind
keeping its caches. I tried disabling other usage of c.icon in my config, but couldn't pin point the
"faulty" one.
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1259#comment4013

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 18 Apr 06:28 2014

[awesome bugs] #1259 - Random Cairo assert

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1259 - Random Cairo assert
User who did this - Emmanuel Lepage Vallee (Elv13)

----------
None of the 2 had the fix, the Ubuntu one was a year old, the Gentoo one a month old. I am in the process of trying
to isolate the problem, but I have a (very, very) high number of surfaces at any given time, so isolating one
is nearly impossible. I think I am closing in, but I experience a lot of false positive.
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1259#comment4012

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 17 Apr 19:52 2014

[awesome bugs] #1255 - Tasklist "update_function" not working

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1255 - Tasklist "update_function" not working
User who did this - Emmanuel Pelletier (Leimi)

----------
Oh man - sorry for opening an issue for this. I was stuck on this for litteraly hours and didn't even check if
"awful.widget.common" actually existed by default when requiring just "awful".

So yeah, the problem was just a missing require. Weird thing is I actually didn't get any error for this
particular thing (I usually get some) so I really thought all the requires were good.

Anyway, thanks a lot, I can now do what I want!
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1255#comment4011

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 17 Apr 09:02 2014

[awesome bugs] #1259 - Random Cairo assert

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1259 - Random Cairo assert
User who did this - Uli Schlachter (psychon)

----------
Uhm. Shit.

Which LGI version are you using exactly on both boxes?

The backtrace says that this happens somewhere in the client "unfocus" signal. You are calling
cairo_pattern_create_for_surface() / cairo.Pattern.create_for_surface() for a surface with
reference count 0 aka "a surface for which the last reference was already dropped and which thus was
already destroyed". This should be impossible to do through lua.

Sadly LGI doesn't wrap cairo_surface_get_reference_count(). This would help in debugging.

So... awesome itself calls create_for_surface() in gears.color (when loading PNG files), in
gears.wallpaper and in wibox.widget.background. This could be gears.color.create_png_pattern(),
but the other two places are highly unlikely. Dunno how often your code uses this function.

I hope this information helps you figure out where exactly this happens / which surface does this / coming up
with a minimal reproducing example.

Oh, one more idea before I am out of ideas: Since this is the client "unfocus" signal, I would take a closer
look at my code handling c.icon.
----------

(Continue reading)

awesome | 17 Apr 07:16 2014

[awesome bugs] #1259 - Random Cairo assert

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1259 - Random Cairo assert
User who did this - Emmanuel Lepage Vallee (Elv13)

----------
Little more details, moving the mouse in circle long enough triggers it. I tried both and older version of my
config and an older version of awesome, I can reproduce with both, so I guess there really is something wrong...
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1259#comment4009

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 17 Apr 06:27 2014

[awesome bugs] #1259 - Random Cairo assert

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Emmanuel Lepage Vallee (Elv13) 

Attached to Project - awesome
Summary - Random Cairo assert
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Low
Priority - Normal
Reported Version - git/master
Due in Version - Undecided
Due Date - Undecided
Details - I got this on my work laptop (Ubuntu 13.10, Awesome 3.5.5 from .deb, lua-5.1 (no JIT), stock LGI)
and managed to reproduce it on my desktop (Gentoo, Awesome git-master, LGI-jit master, Luajit)

awesome: cairo-surface.c:905: cairo_surface_reference: Assertion
`((*&(&surface->ref_count)->ref_count) > 0)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff489d0d9 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff489d0d9 in raise () from /lib64/libc.so.6
#1  0x00007ffff489e438 in abort () from /lib64/libc.so.6
#2  0x00007ffff4896276 in __assert_fail_base () from /lib64/libc.so.6
(Continue reading)

awesome | 14 Apr 21:36 2014

[awesome bugs] #1257 - Follow XDG icon theme specification

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1257 - Follow XDG icon theme specification
User who did this - Harvey Mittens (Harvey)

----------
Well It seems to me that we could use Gio GIcon objects to find the correct icon in the theme repository for the
user, then return the full icon path to gears.surface for rendering
this way we don't need Gtk and we also don't have to do the nasty for loop searching to find matching icons by
name alone. Gio GIcon and GThemedIcon are all in glib not Gtk

----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1257#comment4008

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 14 Apr 10:07 2014

[awesome bugs] #1233 - Some signal for titlebar sizes

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1233 - Some signal for titlebar sizes
User who did this - Uli Schlachter (psychon)

----------
This signal would (likely) also need to be handled in awful.client.shape.
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1233#comment4007

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 14 Apr 10:06 2014

[awesome bugs] #1051 - (Properly) re-add window shapes

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#1051 - (Properly) re-add window shapes
User who did this - Uli Schlachter (psychon)

Reason for closing: Fixed
Additional comments about closing: commit e998e3fe207e22050087ba93821294f80d3a52e2
Author: Uli Schlachter <psychon <at> znc.in>
Date:   Mon Apr 14 10:04:56 2014 +0200

    awful.client.shape: Import client shape handling (FS#1051)

    This new awful module reacts to shapes that a client sets on itself and sets the
    shape of awesome's frame window to match. This way, xeyes really gets
    transparent parts again.

    Signed-off-by: Uli Schlachter <psychon <at> znc.in>

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1051

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.


Gmane