Git Version | Version Git
matttbe, Friday 03 August 2012 à 15:35
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Depuis peu, en cliquant sur logout, j'ai un crash dont voici le backtrace:Thread 15 (Thread 0x7fffc64c9700 (LWP 7369)):
#0 __memmove_ssse3_back ()
at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1562
No locals.
#1 0x00007ffff0337998 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#2 0x00007ffff032a291 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#3 0x00007ffff0331e07 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#4 0x00007ffff0331f31 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#5 0x00007ffff0332924 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#6 0x00007ffff0332f66 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#7 0x00007ffff0331ccd in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#8 0x00007ffff031cc05 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#9 0x00007ffff031df69 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
No symbol table info available.
#10 0x00007ffff5fb925f in ?? ()
from /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2
No symbol table info available.
#11 0x00007ffff5fbc69b in dbus_g_proxy_call ()
from /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2
No symbol table info available.
#12 0x00007ffff654db46 in cairo_dock_dbus_get_property_in_value (
pDbusProxy=pDbusProxy@entry=0x16e8d70,
cInterface=cInterface@entry=0x7fffd7bf4e48 "org.freedesktop.DisplayManager.Seat", cProperty=cProperty@entry=0x7fffd7bf4a83 "HasGuestAccount",
pProperty=pProperty@entry=0x7fffc64c8be0)
at /opt/cairo-dock_bzr/cairo-dock-core/src/gldit/cairo-dock-dbus.c:551
erreur = 0x0
__PRETTY_FUNCTION__ = "cairo_dock_dbus_get_property_in_value"
#13 0x00007ffff654dbc6 in cairo_dock_dbus_get_property_as_boolean (
pDbusProxy=pDbusProxy@entry=0x16e8d70,
cInterface=cInterface@entry=0x7fffd7bf4e48 "org.freedesktop.DisplayManager.Seat", cProperty=cProperty@entry=0x7fffd7bf4a83 "HasGuestAccount")
at /opt/cairo-dock_bzr/cairo-dock-core/src/gldit/cairo-dock-dbus.c:568
v = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0,
v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0,
v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0,
v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0,
v_double = 0, v_pointer = 0x0}}}
#14 0x00007fffd7bf2898 in _cd_logout_check_capabilities_async (
pSharedMemory=0x22c6a70)
at /opt/cairo-dock_bzr/cairo-dock-plug-ins/logout/src/applet-logout.c:119
error = 0x0
pProxy = 0x16e8d70
__PRETTY_FUNCTION__ = "_cd_logout_check_capabilities_async"
seat = <optimized out>
#15 0x00007ffff6556304 in _cairo_dock_threaded_calculation (pTask=0x12bb2e0)
at /opt/cairo-dock_bzr/cairo-dock-core/src/gldit/cairo-dock-task.c:64
No locals.
#16 0x00007ffff7166db5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#17 0x00007ffff79a5e9a in start_thread (arg=0x7fffc64c9700)
at pthread_create.c:308
__res = <optimized out>
pd = 0x7fffc64c9700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {1, 8223762433774843544,
140737488343456, 140736520296896, 12565856, 3,
-8223818361143167336, -8223780280421714280},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0},
data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#18 0x00007ffff5cde4bd in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#19 0x0000000000000000 in ?? ()
No symbol table info available.
Et on peut voir ceci: /opt/cairo-dock_bzr/cairo-dock-plug-ins/logout/src/applet-logout.c:119. Or, voilà ce que l'on a: 112 const gchar *seat = g_getenv ("XDG_SEAT_PATH");
113 if (seat) // else, we could possibly get it by: ck -> GetCurrentSession -> session -> GetSeatId
114 {
115 pProxy = cairo_dock_create_new_system_proxy (
116 "org.freedesktop.DisplayManager",
117 seat,
118 DBUS_INTERFACE_PROPERTIES);
119 pSharedMemory->bHasGuestAccount = cairo_dock_dbus_get_property_as_boolean (pProxy, "org.freedesktop.DisplayManager.Seat", "HasGuestAccount");
120 g_object_unref (pProxy);
121 } Et avec d-feet, pas de problème pour aller chercher cette info (qui retourne '1').
Une idée?
Le truc, c'est qu'il semble qu'il va y avoir des changements avec DBus... => https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1014850 (la mise à jour arrive, je vais tester ) |
matttbe, Friday 03 August 2012 à 15:45
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Idem avec la dernière version, maintenant ça crash dans: dbus_g_proxy_call (pProxy, "CanStop", &error,
G_TYPE_INVALID,
G_TYPE_BOOLEAN, &pSharedMemory->bCanStop,
G_TYPE_INVALID); |
Subscription date : 30 November 2007
Messages : 17118
|
vu que le code n'a pas bougé, il est possible que ce soit une régression ailleurs (vu que tu es sur une version instable d'Ubuntu)
tu as pu regarder si pSharedMemory était correct ? car autrement je ne pense pas que le problème soit dans le dock. |
matttbe, Monday 06 August 2012 à 20:04
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Il y a un nouveau bug sur LP avec backtrace et stacktrace, p-e plus complet
Les appels a DBus sont faits dans un thread mais ça ne devrait pas etre un probleme... et le crash n'est pas a chaque fois sur le meme appel DBus... |
fabounet, Tuesday 07 August 2012 à 17:14
|
|
Subscription date : 30 November 2007
Messages : 17118
|
mais le code de l'applet n'a pas changé ... |
matttbe, Tuesday 07 August 2012 à 18:19
|
|
fabounet, Thursday 09 August 2012 à 18:06
|
|
Subscription date : 30 November 2007
Messages : 17118
|
comme on n'utilise pas libdbus directement, j'espère qu'on est un peu protégé de ce genre de truc ... mais tout de même, c'est un appel Dbus assez simple, je vois pas ce qui peut déconner.
ou alors libupower sème la panique lors d'un précédent appel (on a déjà eu le cas d'un crash du à libupower sous Debian 6, d'ailleurs je sais même pas s'ils l'ont fixé) |
matttbe, Friday 10 August 2012 à 00:27
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Yep, je confirme, sans l'appel à upower, pas de soucis!
EDIT en fait non, c'est juste un appel à DBus en moins et moins de possibilité de crash... |
matttbe, Friday 10 August 2012 à 10:46
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Il semblerait que l'appel à dbus_g_thread_init soit demandé si on utilise D-Bus dans des threads...
@fabounet: Je l'ai donc rajouté dans cairo-dock.c (car il doit être placé avant tout appel D-Bus) mais il y a p-ê une meilleure place? (il n'y a pas moyen de l'activer et puis de le désactiver d'après ce que je vois...)
Sinon, il n'y a que Logout qui utilise des appels à D-Bus dans des threads? Si oui, peut-être qu'il serait préférable de faire ces appels de manière asynchrone qqs secondes après le lancement du dock? Voir peut-être de préparer le menu et de changer la "sensibilité" de ces menus dès que l'on a une réponse via D-Bus? |
Subscription date : 30 November 2007
Messages : 17118
|
tu as réussi à dénicher le coupable !
je verrai si j'ai une meilleure idée où le mettre
sinon, on utilise une task dans logout, car up_client_get_properties_sync est synchrone (il n'y a pas de version asynchrone de cette fonction), et donc bloquante
c'est vraiment nul, la seule solution serait de se passer de cette lib, mais ce serait dommage.
le seul point à voir, c'est si appeler dbus_g_thread_init pénalise les performances des appels Dbus
je suppose que ça ne se voit pas sur une machine récente, et ça doit être difficile à mesurer. |
matttbe, Friday 10 August 2012 à 16:11
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Oui
sinon, on utilise une task dans logout, car up_client_get_properties_sync est synchrone (il n'y a pas de version asynchrone de cette fonction), et donc bloquante
c'est vraiment nul, la seule solution serait de se passer de cette lib, mais ce serait dommage. Yep mais le dock attend (activement mais il n'est pas bloqué) la fin des appels avant d'afficher le menu... Et vu qu'il faut aussi rechercher les info sur les utilisateurs ainsi que les icônes à afficher, ça peut prendre du temps...
le seul point à voir, c'est si appeler dbus_g_thread_init pénalise les performances des appels Dbus
je suppose que ça ne se voit pas sur une machine récente, et ça doit être difficile à mesurer. Yep, je ne vois pas de différence (il n'y a pas énormément d'appels à D-Bus non plus et je suppose qu'il ne fait que patienter les appels sans trop utiliser de ressources). Par contre, est-ce que ça pourrait se ressentir avec les applets third-party? |
fabounet, Tuesday 14 August 2012 à 17:10
|
|
Subscription date : 30 November 2007
Messages : 17118
|
certes le menu n'est affiché qu'une fois qu'on a les infos (logique), mais au moins le dock ne bloque pas (l'animation lors du clic de l'icône notamment, et si les choses tournaient mal, le reste du dock est toujours accessible).
il n'y a pas énormément d'appels à D-Bus non plus
hmmm, il y'en a pas mal tout de même: MP, notification area, compiz/kwin, logout, etc
c'est surtout les 2 premières qui font des appels réguliers, mais comme tu dis il y'a aussi les applets tierces ... donc on devrait pouvoir s'en rendre compte en chargeant un dock bien comme il faut avec tout plein d'applets Dbus |
Git Version | Version Git
|