Bug#1080518: (no subject)
Hello, Confirmed with firefox 130 on sid. The suggested workaround to disable AVIF support works, images are correctly rendered after a reload. For reference, the setting is image.avif.enabled. I'm wondering if the underlying issue in libyuv could also be the cause of another bug I'm experiencing, where my webcam video in google meet is correctly rendered for me, but other meet participants receive my stream with garbled colors. No idea how to work around this though. Best regards, -- Julien Leproust
Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard
On Fri, 1 Mar 2024 12:48:32 +0100 Julien Leproust wrote: > Hello, > > Same issue for me, same symptoms, I was using lightdm with autologin and > a kodi session, but any other session triggers the same bug. Additional info: I upgraded the mesa packages to the new 24.0.2-1 version, same problem. Upgrade: libglx-mesa0:amd64 (24.0.1-1, 24.0.2-1), libgbm1:amd64 (24.0.1-1, 24.0.2-1), mesa-va-drivers:amd64 (24.0.1-1, 24.0.2-1), libgl1-mesa-dri:amd64 (24.0.1-1, 24.0.2-1), mesa-vulkan-drivers:amd64 (24.0.1-1, 24.0.2-1), libglapi-mesa:amd64 (24.0.1-1, 24.0.2-1), libegl-mesa0:amd64 (24.0.1-1, 24.0.2-1), mesa-vdpau-drivers:amd64 (24.0.1-1, 24.0.2-1) Best regards, -- Julien Leproust
Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard
Hello, Same issue for me, same symptoms, I was using lightdm with autologin and a kodi session, but any other session triggers the same bug. GPU: AMD A10-7800 Radeon R7 APU Here is my stack from Xorg.0.log [ 38.969] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x14d) [0x561b023f0f9d] [ 38.969] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f0190abd510] [ 38.988] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x275d) [0x7f018e1c586d] [ 38.988] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x4841) [0x7f018e1c7951] [ 38.992] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (_ZNSt6vectorIjSaIjEE17_M_default_appendEm+0xa77e6) [0x7f018e6c9476] [ 38.992] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (_ZNSt6vectorIjSaIjEE17_M_default_appendEm+0xa7989) [0x7f018e6c9619] [ 38.993] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x3aba) [0x7f018e1c6bca] [ 38.995] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x137795) [0x7f018e2fa8a5] [ 38.996] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x137b68) [0x7f018e2fac78] [ 38.996] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x138387) [0x7f018e2fb497] [ 38.997] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0xb6dba) [0x7f018e279eca] [ 38.997] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0xb91b8) [0x7f018e27c2c8] [ 38.998] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0xbe181) [0x7f018e281291] [ 38.998] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0xf0208) [0x7f018e2b3318] [ 38.998] (EE) 14: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0xf4aa9) [0x7f018e2b7bb9] [ 39.003] (EE) 15: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (_ZNSt6vectorIjSaIjEE17_M_default_appendEm+0x1cc3e9) [0x7f018e7ee079] [ 39.003] (EE) 16: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (_ZNSt6vectorIjSaIjEE17_M_default_appendEm+0x1d7ee3) [0x7f018e7f9b73] [ 39.009] (EE) 17: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x5c81c7) [0x7f018e079557] [ 39.010] (EE) 18: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x5c1016) [0x7f018e0723a6] [ 39.010] (EE) 19: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x5c19b8) [0x7f018e072d48] [ 39.011] (EE) 20: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x5c9b75) [0x7f018e07af05] [ 39.015] (EE) 21: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0xb82c4) [0x7f018db69654] [ 39.015] (EE) 22: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150) [0x7f0185d7acf0] [ 39.016] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 39.016] (EE) 23: /usr/lib/xorg/modules/drivers/radeon_drv.so (?+0x0) [0x7f018fe7fcdf] [ 39.016] (EE) 24: /usr/lib/xorg/Xorg (BlockHandler+0xad) [0x561b0227fe0d] [ 39.016] (EE) 25: /usr/lib/xorg/Xorg (WaitForSomething+0x153) [0x561b023ea703] [ 39.016] (EE) 26: /usr/lib/xorg/Xorg (SendErrorToClient+0x117) [0x561b0227b097] [ 39.016] (EE) 27: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x561b0227f3bc] [ 39.017] (EE) 28: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f0190aa86ca] [ 39.017] (EE) 29: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f0190aa8785] [ 39.017] (EE) 30: /usr/lib/xorg/Xorg (_start+0x21) [0x561b02268281] [ 39.017] (EE) [ 39.017] (EE) Segmentation fault at address 0x40 Best regards, -- Julien Leproust
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
I tried the fix_db.pl script, there was no output. Here is the only relevant difference: --- debconf.old/config.dat▸-2019-03-10 18:43:37.265483165 +0100 +++ debconf/config.dat▸-2019-03-10 18:43:41.261085496 +0100 @@ -1151,7 +1151,7 @@ Name: libpam-modules/disable-screensaver Template: libpam-modules/disable-screensaver -Owners: libpam-modules +Owners: libpam-modules, libpam-modules:amd64 Name: libpam-runtime/conflicts Template: libpam-runtime/conflicts Other differences are only label translations for libraries/restart-without-asking in templates. -- Julien Leproust
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Indeed, it looks a lot like #923362, though I can't reproduce now by manually running dpkg-reconfigure libpam-runtime. Tell me if I can help debug this, I still have the full apt logs and etckeeper on two machines. Anyway I learnt a lot about pam and systemd :-) Best regards, -- Julien Leproust
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
it.so # and here are more per-package modules (the "Additional" block) session requiredpam_unix.so session optionalpam_systemd.so session optionalpam_cgfs.so -c freezer,memory,name=systemd # end of pam-auth-update config === I can provide the full git and apt logs, but I'd have to edit them before to hide personal information. Thanks anyway. Best regards, -- Julien Leproust
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Hi, I found the issue. When looking for /etc files not belonging to any package, I discovered that /etc/pam.d/common-* files are managed by pam-auth-update. Most pam profiles were enabled, except "Register user sessions in the systemd control group hierarchy", and just enabling it fixed the problem. The systemd user service and logind session are now correctly started and everything works fine (device permissions, pulseaudio, etc). The real issue becomes why this pam profile got disabled in the first place. Thanks everyone for your help. Best regards, -- Julien Leproust
Bug#922647: systemd --user no longer running
On 3/7/19 1:21 AM, Felipe Sateler wrot It is libpam-ck-connector I have no such package, neither installed nor available. -- Julien Leproust
Bug#922647: systemd --user no longer running
Yes, I do have dbus-user-session and dbus-x11 installed: $ apt-cache policy dbus-user-session dbus-x11 dbus-user-session: Installed: 1.12.12-1 Candidate: 1.12.12-1 Version table: 1.13.8-1 1 1 http://ftp.fr.debian.org/debian experimental/main amd64 Packages *** 1.12.12-1 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status dbus-x11: Installed: 1.12.12-1 Candidate: 1.12.12-1 Version table: 1.13.8-1 1 1 http://ftp.fr.debian.org/debian experimental/main amd64 Packages *** 1.12.12-1 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status On the other affected machine, dbus-user-session is installed but dbus-x11 isn't. I have experimental repositories configured but I don't use them currently. On Wed, 6 Mar 2019 19:35:42 -0300 Felipe Sateler wrote:> So, #923881 gives one reason why systemd --user might fail. Is your home directory set to a non-absolute path? No, my home is the standard /home/julien. What could be helpful, is to provide the full journal from around the time you login. There should be something there signalling why your user instance is not starting. ANother thing, easier to test, is to try to launch the user manager: `systemctl start user@$UID` . Does that work? Indeed, this works. I hadn't thought to try this. -- Logs begin at Fri 2019-03-01 10:13:47 CET, end at Thu 2019-03-07 00:44:16 CET. -- Mar 07 00:40:20 treize systemd[1]: Starting User Manager for UID 1000... Mar 07 00:40:20 treize systemd[30137]: pam_unix(systemd-user:session): session opened for user julien by (uid=0) Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic agent and passphrase cache. Mar 07 00:40:20 treize systemd[30137]: Reached target Paths. Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers). Mar 07 00:40:20 treize systemd[30137]: Listening on Sound System. Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG network certificate management daemon. Mar 07 00:40:20 treize systemd[30137]: Starting D-Bus User Message Bus Socket. Mar 07 00:40:20 treize systemd[30137]: Reached target Timers. Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic agent (ssh-agent emulation). Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic agent and passphrase cache (restricted). Mar 07 00:40:20 treize systemd[30137]: Listening on D-Bus User Message Bus Socket. Mar 07 00:40:20 treize systemd[30137]: Reached target Sockets. Mar 07 00:40:20 treize systemd[30137]: Reached target Basic System. Mar 07 00:40:20 treize systemd[30137]: Reached target Default. Mar 07 00:40:20 treize systemd[30137]: Startup finished in 65ms. Mar 07 00:40:20 treize systemd[1]: Started User Manager for UID 1000. This creates /run/user/1000: $ ls -al /run/user/1000 total 0 drwx-- 5 julien julien 120 Mar 7 00:40 ./ drwxr-xr-x 4 root root80 Mar 7 00:40 ../ srw-rw-rw- 1 julien julien 0 Mar 7 00:40 bus= drwx-- 2 julien julien 140 Mar 7 00:40 gnupg/ drwxr-xr-x 2 julien julien 60 Mar 7 00:40 pulse/ drwxr-xr-x 2 julien julien 80 Mar 7 00:40 systemd/ Here is the lightdm journal on one of the machines where it is configured with autologin and kodi-standalone session: -- Subject: A start job for unit lightdm.service has begun execution -- A start job for unit lightdm.service has begun execution. -- Subject: A start job for unit lightdm.service has finished successfully -- A start job for unit lightdm.service has finished successfully. Mar 07 00:50:32 totoro lightdm[1008]: pam_unix(lightdm-autologin:session): session opened for user julien by (uid=0) Mar 07 00:50:32 totoro lightdm[1008]: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files I can paste you the whole boot journal but I don't see anything interesting. dbus-daemon and systemd-user-sessions start successfully. I see no error at all except the lightdm one above. Thanks a lot. -- Julien Leproust
Bug#922647: systemd --user no longer running
Hi, I've been hit by seemingly the same bug on two of my machines. Since about mid-February, I noticed that my two Debian sid desktops no longer produced any sound. On one of them, I use lightdm+mate, on the other I use lightdm+kodi. Both were updated roughly weekly, with only official sid repositories. I quickly found out that the sound was broken because pulseaudio was not starting, having no permission to access the sound devices. In turn, I found that this permission should have been granted through dbus and systemd --user, which were both absent from the process list. Same symptoms for both machine: $ systemctl --user status Failed to read server status: Process org.freedesktop.systemd1 exited with status 1 Last systemd user logs were from a boot mid-january when sound still worked. Absolutely no logs since then, just like for Eduard (I tried all the suggestions above). systemd --user does not start at all from the user session. loginctl shows only the lightdm session, not the real user one: $ loginctl SESSION UID USERSEAT TTY c3 135 lightdm seat0 I have the same systemd error as Eduard when starting it manually: $ systemd --user Trying to run as user instance, but $XDG_RUNTIME_DIR is not set. XDG_RUNTIME_DIR and XDG_SESSION_ID are both unset in my environment. $ env|grep XDG XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_VTNR=7 XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/julien XDG_SESSION_DESKTOP=mate XDG_DATA_DIRS=/usr/share/mate:/usr/local/share/:/usr/share/ XDG_SESSION_TYPE=x11 XDG_CURRENT_DESKTOP=MATE XDG_SEAT=seat0 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 I tried logging in as a brand new user with an empty home directory, the problem is reproduced. I tried replacing lightdm with sddm, and mate-session with cinnamon or gnome, all fail the same way. I tried installing a brand new VM with lightdm and mate-session, everything works fine. I can notice a difference with dbus though. On my broken machine: $ env|grep DBUS DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-UqLtmoksoq,guid=ffcd65719a7135c063ccc9a15c6f26c9 On my working VM: env|grep DBUS DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus I can see a related change in systemd 241: * $DBUS_SESSION_BUS_ADDRESS environment variable is set by pam_systemd again. /run/user/1000 does not exist on my broken machine. On the working machine, XDG_RUNTIME_DIR is /run/user/1000 and exists and is populated. On one of my broken machines, /run/user is empty, and on the other it only contains an entry for the lightdm user: $ ls -al /run/user/135 ls: cannot access '/run/user/135/gvfs': Permission denied total 0 drwx-- 8 lightdm lightdm 180 Feb 26 19:52 ./ drwxr-xr-x 3 rootroot 60 Feb 26 19:52 ../ srw-rw-rw- 1 lightdm lightdm 0 Feb 26 19:52 bus= drwx-- 3 lightdm lightdm 60 Feb 26 19:52 dbus-1/ drwx-- 2 lightdm lightdm 60 Feb 26 19:52 dconf/ drwx-- 2 lightdm lightdm 140 Feb 26 19:52 gnupg/ d? ? ? ? ?? gvfs/ drwxr-xr-x 2 lightdm lightdm 60 Feb 26 19:52 pulse/ drwxr-xr-x 2 lightdm lightdm 80 Feb 26 19:52 systemd/ Is there anything else I can check in this direction? I guess the problem must come from some system configuration on both of my machines, maybe some old file in /etc. debsums -ce shows only modifications to files from completely unrelated packages (libvirt, grub). My next idea would be to try to purge and reinstall most systemd packages, but it will be tricky on a live system. Does anyone have any other idea to test short of reinstalling? Thanks in advance for your help. Best regards -- Julien Leproust
Bug#683394: nautilus: Thumbnails are created, but not displayed (nautilus loops over non-existing files in "~/.thumbnails/fail", causes also high CPU usage)
On Fri, Jan 04, 2013 at 10:58:49AM +0100, Josselin Mouette wrote: > You must have some components of GNOME 3.6 to exhibit this behavior. > Nautilus 3.4 only uses ~/.thumbnails. > > I don’t know about nemo, but if it is not kept in sync with gvfs, it’s > looking for trouble. Nemo is nautilus' clone by the cinnamon project. Packages have been submitted to unstable recently. I have installed both gnome 3.4 and cinnamon 1.6.7. I checked, I don't have a single gnome 3.6 package. I logged in using a brand new user in a gnome classic session, I launched nautilus 3.4.2 with strace, and observed it trying to fetch thumbnails from ~/.cache/thumbnails, and creating them to ~/.thumbnails/normal. ~/.cache/thumbnails doesn't even exist. Could some package from cinnamon change or overwrite some gnome configuration parameter? -- Julien Leproust -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683394: nautilus: Thumbnails are created, but not displayed (nautilus loops over non-existing files in "~/.thumbnails/fail", causes also high CPU usage)
On Thu, Jan 03, 2013 at 01:20:07AM +0100, Josselin Mouette wrote: > I’m not following you. GNOME 3.4 as a whole still uses ~/.thumbnails as > the thumbnail cache directory, not the new location. > > Which component is actually trying to use this new location? I tried both nautilus and nemo. Before the symlink, I witnessed the exact same behaviour as Matteo in the first report (opening ~/.thumbnails/fail/gnome-thumbnail-factory/, ENOENT), in both explorers. After the symlink, stracing both nautilus and nemo shows successful opens of ~/.cache/thumbnails/normal/*. I can help debugging this if you give me pointers. Regards, -- Julien Leproust -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588713: gthumb: Segfault at startup in clutter_init()/cogl_create_context() (again)
Package: gthumb
Version: 3:2.11.4-2+b1
Severity: important
In the same conditions as #573723, I get a segmentation fault at startup.
I assume this appears when reenabling libclutter. The stack is not exactly the
same as in #573723.
Other maybe relevant information: I'm running nvidia driver 195.36.24 with
twinview enabled and DRI broken (disabled), so no hardware opengl:
Xlib: extension "XFree86-DRI" missing on display ":0.0".
libGL error: XF86DRIQueryDirectRenderingCapable faileddisplay: :0 screen: 0
Here is the log and stack trace:
% gdb -args gthumb --clutter-debug=all
GNU gdb (GDB) 7.1-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/gthumb...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/gthumb --clutter-debug=all
[Thread debugging using libthread_db enabled]
ClutterX11-Message: [BACKEND] clutter-backend-x11.c:174: Getting the X screen
Clutter-Message: [BACKEND] ./clutter-backend.c:165: Units per em: 9,66
ClutterX11-Message: [BACKEND] clutter-backend-x11.c:226: X Display
':0.0'[0x8105a00] opened (screen:0, root:429, dpi:86,124503)
Clutter-Message: [BACKEND] ./clutter-stage.c:1004: Creating stage from the
default backend
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:598: Creating stage of type
'ClutterStageGLX'
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:616: GLX stage
created[0x8128000] (dpy:0x8105a00, screen:0, root:429, wrap:0x8127010)
Clutter-Message: [ACTOR] ./clutter-actor.c:1183: Realizing actor 'ClutterStage'
[0x8127010]
Clutter-Message: [ACTOR] ./clutter-actor.c:1183: Realizing actor
'ClutterStageGLX' [0x8128000]
ClutterGLX-Message: [ACTOR] clutter-stage-glx.c:125: Realizing stage
'ClutterStageGLX' [0x8128000]
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:657: Retrieving GL visual
(for onscreen use), dpy: 0x8105a00, xscreen; 0x8110168 (0)
ClutterGLX-Message: [MISC] clutter-stage-glx.c:151: Creating stage X window
Clutter-Message: [LAYOUT] ./clutter-actor.c:4523: Width request for -1,00 px
Clutter-Message: [LAYOUT] ./clutter-actor.c:4594: Width request for 640,00 px
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:657: Retrieving GL visual
(for onscreen use), dpy: 0x8105a00, xscreen; 0x8110168 (0)
ClutterGLX-Message: [GL] clutter-backend-glx.c:374: Creating GL Context
(display: 0x8105a00, onscreen)
ClutterGLX-Message: [GL] clutter-backend-glx.c:400: Setting indirect context
ClutterGLX-Message: [BACKEND] clutter-stage-glx.c:215: Successfully realized
stage
ClutterX11-Message: [BACKEND] clutter-stage-x11.c:365: setting cursor state
('visible') over stage window (58720260)
Clutter-Message: [MULTISTAGE] ./clutter-backend.c:344: Setting the new stage
[0x8127010]
ClutterGLX-Message: [MULTISTAGE] clutter-backend-glx.c:438: Setting context for
stage of type ClutterStageGLX [0x8128000]
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:470: MakeCurrent dpy:
0x8105a00, window: 0x384 (native), context: 0x81260e8
Xlib: extension "XFree86-DRI" missing on display ":0.0".
ClutterX11-Message: [EVENT] clutter-backend-x11.c:235: initialising the event
loop
Clutter-Message: [MISC] ./clutter-feature.c:84: checking features
Clutter-Message: [MISC] ./clutter-feature.c:88: allocating features data
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0xb7ce1ce1 in _cogl_material_flush_base_gl_state (handle=0x812f7d8,
options=0x0) at cogl-material.c:1566
#2 _cogl_material_flush_gl_state (handle=0x812f7d8, options=0x0)
at cogl-material.c:1608
#3 0xb7cec720 in cogl_create_context () at cogl-context.c:173
#4 _cogl_context_get_default () at cogl-context.c:227
#5 0xb7ce49dd in cogl_get_features () at cogl.c:585
#6 0xb7cb1563 in _clutter_feature_init () at ./clutter-feature.c:98
#7 0xb7cb70b3 in clutter_init_real (error=)
at ./clutter-main.c:1267
#8 0xb7cb73d8 in clutter_init (argc=0x0, argv=0x0) at ./clutter-main.c:1676
#9 0xb7d27b46 in gtk_clutter_init (argc=0x0, argv=0x0)
at ./gtk-clutter-util.c:631
#10 0x080db65e in main ()
(gdb)
Thanks a lot.
Best regards,
--
Julien Leproust
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.34-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versi
Bug#573723: gthumb: Segmentation fault at startup in gtk_clutter_init()/cogl_create_context()
On Sat, Mar 13, 2010 at 07:42:53PM +0100, David Paleino wrote:
> Uhm, ok, I actually meant running:
>
> $ gdb gthumb
> ...
> (gdb) run --clutter-debug=all
Hmmm, ok, but I don't see much new information...
% gdb -args /usr/bin/gthumb --clutter-debug=all
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/gthumb...Reading symbols from
/usr/lib/debug/usr/bin/gthumb...done.
(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/gthumb --clutter-debug=all
[Thread debugging using libthread_db enabled]
ClutterX11-Message: [BACKEND] clutter-backend-x11.c:174: Getting the X screen
Clutter-Message: [BACKEND] ./clutter-backend.c:165: Units per em: 9,66
ClutterX11-Message: [BACKEND] clutter-backend-x11.c:226: X Display
':0.0'[0x80fea00] opened (screen:0, root:429, dpi:86,124503)
Clutter-Message: [BACKEND] ./clutter-stage.c:1004: Creating stage from the
default backend
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:598: Creating stage of type
'ClutterStageGLX'
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:616: GLX stage
created[0x8121000] (dpy:0x80fea00, screen:0, root:429, wrap:0x8120010)
Clutter-Message: [ACTOR] ./clutter-actor.c:1183: Realizing actor 'ClutterStage'
[0x8120010]
Clutter-Message: [ACTOR] ./clutter-actor.c:1183: Realizing actor
'ClutterStageGLX' [0x8121000]
ClutterGLX-Message: [ACTOR] clutter-stage-glx.c:125: Realizing stage
'ClutterStageGLX' [0x8121000]
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:657: Retrieving GL visual
(for onscreen use), dpy: 0x80fea00, xscreen; 0x80ff4b0 (0)
ClutterGLX-Message: [MISC] clutter-stage-glx.c:151: Creating stage X window
Clutter-Message: [LAYOUT] ./clutter-actor.c:4523: Width request for -1,00 px
Clutter-Message: [LAYOUT] ./clutter-actor.c:4594: Width request for 640,00 px
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:657: Retrieving GL visual
(for onscreen use), dpy: 0x80fea00, xscreen; 0x80ff4b0 (0)
ClutterGLX-Message: [GL] clutter-backend-glx.c:374: Creating GL Context
(display: 0x80fea00, onscreen)
ClutterGLX-Message: [GL] clutter-backend-glx.c:400: Setting indirect context
ClutterGLX-Message: [BACKEND] clutter-stage-glx.c:215: Successfully realized
stage
ClutterX11-Message: [BACKEND] clutter-stage-x11.c:365: setting cursor state
('visible') over stage window (65011716)
Clutter-Message: [MULTISTAGE] ./clutter-backend.c:344: Setting the new stage
[0x8120010]
ClutterGLX-Message: [MULTISTAGE] clutter-backend-glx.c:438: Setting context for
stage of type ClutterStageGLX [0x8121000]
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:470: MakeCurrent dpy:
0x80fea00, window: 0x3e4 (native), context: 0x811fa88
Xlib: extension "XFree86-DRI" missing on display ":0.0".
ClutterX11-Message: [EVENT] clutter-backend-x11.c:235: initialising the event
loop
Clutter-Message: [MISC] ./clutter-feature.c:84: checking features
Clutter-Message: [MISC] ./clutter-feature.c:88: allocating features data
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0xb7d04130 in cogl_create_context () at cogl-context.c:173
#2 _cogl_context_get_default () at cogl-context.c:227
#3 0xb7d0d5bd in cogl_get_features () at cogl.c:585
#4 0xb7cd3145 in _clutter_feature_init () at ./clutter-feature.c:98
#5 0xb7cd8c82 in clutter_init_real (error=0xb62c) at ./clutter-main.c:1267
#6 0xb7cd8fa8 in clutter_init (argc=0x0, argv=0x0) at ./clutter-main.c:1676
#7 0xb7d49b46 in gtk_clutter_init (argc=0x0, argv=0x0)
at ./gtk-clutter-util.c:631
#8 0x080d4d16 in main (argc=1, argv=0xb714) at main.c:418
(gdb)
I'm going to get sources and compile it, see if I can find more information
on this segfault.
Thanks,
--
Julien Leproust
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573723: gthumb: Segmentation fault at startup in gtk_clutter_init()/cogl_create_context()
Hello David,
Thanks for your answer.
On Sat, Mar 13, 2010 at 03:20:55PM +0100, David Paleino wrote:
> What happens if you start gthumb with --clutter-debug=all ?
Here is the output:
% gthumb --clutter-debug=all
ClutterX11-Message: [BACKEND] clutter-backend-x11.c:174: Getting the X screen
Clutter-Message: [BACKEND] ./clutter-backend.c:165: Units per em: 9,66
ClutterX11-Message: [BACKEND] clutter-backend-x11.c:226: X Display
':0.0'[0x90cda00] opened (screen:0, root:429, dpi:86,124503)
Clutter-Message: [BACKEND] ./clutter-stage.c:1004: Creating stage from the
default backend
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:598: Creating stage of type
'ClutterStageGLX'
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:616: GLX stage
created[0x90f] (dpy:0x90cda00, screen:0, root:429, wrap:0x90ef010)
Clutter-Message: [ACTOR] ./clutter-actor.c:1183: Realizing actor 'ClutterStage'
[0x90ef010]
Clutter-Message: [ACTOR] ./clutter-actor.c:1183: Realizing actor
'ClutterStageGLX' [0x90f]
ClutterGLX-Message: [ACTOR] clutter-stage-glx.c:125: Realizing stage
'ClutterStageGLX' [0x90f]
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:657: Retrieving GL visual
(for onscreen use), dpy: 0x90cda00, xscreen; 0x90ce4b0 (0)
ClutterGLX-Message: [MISC] clutter-stage-glx.c:151: Creating stage X window
Clutter-Message: [LAYOUT] ./clutter-actor.c:4523: Width request for -1,00 px
Clutter-Message: [LAYOUT] ./clutter-actor.c:4594: Width request for 640,00 px
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:657: Retrieving GL visual
(for onscreen use), dpy: 0x90cda00, xscreen; 0x90ce4b0 (0)
ClutterGLX-Message: [GL] clutter-backend-glx.c:374: Creating GL Context
(display: 0x90cda00, onscreen)
ClutterGLX-Message: [GL] clutter-backend-glx.c:400: Setting indirect context
ClutterGLX-Message: [BACKEND] clutter-stage-glx.c:215: Successfully realized
stage
ClutterX11-Message: [BACKEND] clutter-stage-x11.c:365: setting cursor state
('visible') over stage window (65011716)
Clutter-Message: [MULTISTAGE] ./clutter-backend.c:344: Setting the new stage
[0x90ef010]
ClutterGLX-Message: [MULTISTAGE] clutter-backend-glx.c:438: Setting context for
stage of type ClutterStageGLX [0x90f]
ClutterGLX-Message: [BACKEND] clutter-backend-glx.c:470: MakeCurrent dpy:
0x90cda00, window: 0x3e4 (native), context: 0x90eea70
Xlib: extension "XFree86-DRI" missing on display ":0.0".
ClutterX11-Message: [EVENT] clutter-backend-x11.c:235: initialising the event
loop
Clutter-Message: [MISC] ./clutter-feature.c:84: checking features
Clutter-Message: [MISC] ./clutter-feature.c:88: allocating features data
zsh: segmentation fault gthumb --clutter-debug=all
> However, it seems like some symbols re still missing from the trace -- what's
> the output of "ls /usr/lib/debug/usr/lib/libcl*" on your host?
Ok:
% ls /usr/lib/debug/usr/lib/libcl*
/usr/lib/debug/usr/lib/libclutter-glx-1.0.so.0.8.0
/usr/lib/debug/usr/lib/libclutter-gtk-0.10.so.0.0.0
Did I miss a debug package?
> Maybe starting with 2.11.* ?
> AFAIR those were the first releases where I enabled Clutter in the Debian
> package.
That's possible. I've had this bug for some weeks, hadn't enough time to
investigate and hoped it would be automagically solved meanwhile :)
Thank you,
--
Julien Leproust
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573723: gthumb: Segmentation fault at startup in gtk_clutter_init()/cogl_create_context()
Package: gthumb Version: 3:2.11.2.1-1 Severity: important Gthumb fails to start because of a segmentation fault: % gthumb Xlib: extension "XFree86-DRI" missing on display ":0.0". zsh: segmentation fault gthumb I installed gthumb-dbg, libclutter-1.0-dbg and libclutter-gtk-0.10-dbg to get this stack: Xlib: extension "XFree86-DRI" missing on display ":0.0". Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0xb7d04130 in ?? () from /usr/lib/libclutter-glx-1.0.so.0 #2 0xb7d0d5bd in cogl_get_features () from /usr/lib/libclutter-glx-1.0.so.0 #3 0xb7cd3145 in ?? () from /usr/lib/libclutter-glx-1.0.so.0 #4 0xb7cd8c82 in ?? () from /usr/lib/libclutter-glx-1.0.so.0 #5 0xb7155738 in g_option_context_parse () from /lib/libglib-2.0.so.0 #6 0x080d2695 in main () This happens also with gthumb -i. I'm not sure it is a gthumb bug, it could be a clutter bug. I can investigate more if needed, just tell me what to do. Other maybe relevant information: I have an nvidia card with nvidia-glx, version 190.53, and TwinView enabled. I have updated all of my packages today (sid). This bug has been happening on my machine for several weeks already. This bug looks like #573700, but it does not fail with the same message. Thanks! -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gthumb depends on: ii gthumb-data 3:2.11.2.1-1 an image viewer and browser - arch ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-2 The Cairo 2D vector graphics libra ii libclutter-1.0-01.0.8-1 Open GL based interactive canvas l ii libclutter-gtk-0.10-0 0.10.2-1 Open GL based interactive canvas l ii libexiv2-6 0.19-1 EXIF/IPTC metadata manipulation li ii libfontconfig1 2.8.0-2 generic font configuration library ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.4.3-3GCC support library ii libgconf2-4 2.28.0-1 GNOME configuration database syste ii libgl1-mesa-glx [libgl1 7.7-4A free implementation of the OpenG ii libglib2.0-02.22.4-1 The GLib library of C routines ii libgnome-keyring0 2.28.2-1 GNOME keyring services library ii libgstreamer-plugins-ba 0.10.28-1GStreamer libraries from the "base ii libgstreamer0.10-0 0.10.28-1Core GStreamer libraries and eleme ii libgtk2.0-0 2.18.7-1 The GTK+ graphical user interface ii libjpeg62 6b-16.1 The Independent JPEG Group's JPEG ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio ii libsoup-gnome2.4-1 2.29.91-1an HTTP library implementation in ii libsoup2.4-12.29.91-1an HTTP library implementation in ii libstdc++6 4.4.3-3 The GNU Standard C++ Library v3 ii libtiff43.9.2-3+b1 Tag Image File Format (TIFF) libra ii libunique-1.0-0 1.1.6-1 Library for writing single instanc ii libx11-62:1.3.3-2X11 client-side library ii libxcomposite1 1:0.4.1-1X11 Composite extension library ii libxdamage1 1:1.1.2-1X11 damaged region extension libra ii libxext62:1.1.1-3X11 miscellaneous extension librar ii libxfixes3 1:4.0.4-2X11 miscellaneous 'fixes' extensio ii libxml2 2.7.6.dfsg-2+b1 GNOME XML library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gthumb recommends: ii gvfs-bin 1.4.3-2userspace virtual filesystem - bin gthumb suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503992: snort: Segfaults some time after startup, suspect some packet
Package: snort Version: 2.7.0-20 Severity: important Snort segfaults some time after startup, as witnessed by syslog: Oct 30 07:58:30 treize kernel: [2835892.216074] snort[7047]: segfault at c ip b7b66443 sp bf90d57c error 4 in libc-2.7.so[b7af+155000] Oct 30 09:51:54 treize kernel: [2842695.784249] snort[13280]: segfault at 69 ip b7c2c41b sp bfed249c error 4 in libc-2.7.so[b7bb6000+155000] I attached a gdb to my snort instance on eth0 (internet), it segfaulted after about 5 minutes. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7b288c0 (LWP 14885)] 0xb7b9f443 in strlen () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7b9f443 in strlen () from /lib/i686/cmov/libc.so.6 #1 0xb7b6c1ac in vfprintf () from /lib/i686/cmov/libc.so.6 #2 0xb7b903b4 in vsnprintf () from /lib/i686/cmov/libc.so.6 #3 0x08063194 in ?? () #4 0xbfa44213 in ?? () #5 0x0400 in ?? () #6 0x080d0070 in ?? () #7 0xbfa44624 in ?? () #8 0x in ?? () This type of segfaults has seemed to happen quite regularly since october 27th. It looks like it happens more often when processing bittorrent traffic. I upgraded snort on october 23th: [UPGRADE] snort 2.7.0-19 -> 2.7.0-20 [UPGRADE] snort-common 2.7.0-19 -> 2.7.0-20 [UPGRADE] snort-common-libraries 2.7.0-19 -> 2.7.0-20 [UPGRADE] snort-rules-default 2.7.0-19 -> 2.7.0-20 I don't remember this happening before. I have no pcap trace. I can search the logs, but I don't know what to look for. I can investigate more if needed. Thanks a lot for your help. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages snort depends on: ii adduser3.110 add and remove users and groups ii debconf [debconf-2.0] 1.5.24Debian configuration management sy ii libc6 2.7-15GNU C Library: Shared libraries ii libgcrypt111.4.1-1 LGPL Crypto library - runtime libr ii libgnutls262.4.2-1 the GNU TLS library - runtime libr ii libgpg-error0 1.4-2 library for common error values an ii libltdl3 1.5.26-4 A system independent dlopen wrappe ii libpcap0.8 0.9.8-5 system interface for user-level pa ii libpcre3 7.8-2 Perl 5 Compatible Regular Expressi ii libprelude20.9.18.1-1Hybrid Intrusion Detection System ii libtasn1-3 1.5-1 Manage ASN.1 structures (runtime) ii logrotate 3.7.1-5 Log rotation utility ii snort-common 2.7.0-20 flexible Network Intrusion Detecti ii snort-common-libraries 2.7.0-20 flexible Network Intrusion Detecti ii snort-rules-default2.7.0-20 flexible Network Intrusion Detecti ii sysklogd [system-log-d 1.5-5 System Logging Daemon ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages snort recommends: ii iproute 20080725-2 networking and traffic control too Versions of packages snort suggests: pn snort-doc (no description available) -- debconf information: * snort/startup: boot snort/please_restart_manually: * snort/stats_treshold: 1 * snort/address_range: any * snort/options: snort/invalid_interface: * snort/interface: eth0 eth1 * snort/stats_rcpt: root * snort/send_stats: true snort/config_parameters: * snort/config_error: * snort/reverse_order: false * snort/disable_promiscuous: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350278: laptop-mode-tools: error in /usr/sbin/laptop_mode line 1348: settermin: command not found
Package: laptop-mode-tools Version: 1.21-1 Severity: normal Laptop-mode reports an error when terminal control is enabled: # /etc/init.d/laptop-mode restart Restarting laptop mode: enabled, not active. /usr/sbin/laptop_mode: line 1348: settermin: command not found The line 1348 is: settermin -powerdown "$POWERDOWN_MINUTES" Maybe settermin should actually be setterm ? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.13 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) laptop-mode-tools depends on no packages. Versions of packages laptop-mode-tools recommends: ii acpid 1.0.4-5Utilities for using ACPI power man ii hdparm6.3-3 tune hard disk parameters for high ii sdparm0.96-1 Output and modify SCSI device para -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320172: SNMP data gathering with cacti stops functioning since upgrade of snmp from 5.1.2 to 5.2.1.
More info about php-snmp segfault: $ dpkg -l | grep snmp ii libsnmp-base 5.2.1.2-1 ii libsnmp-perl 5.2.1.2-1 ii libsnmp5 5.2.1.2-1 ii libsnmp5-dev 5.2.1.2-1 ii php4-snmp 4.3.10-15 ii snmp 5.2.1.2-1 $ ldd /usr/bin/php libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0x40029000) libzzip-0.so.12 => /usr/lib/libzzip-0.so.12 (0x40056000) libnsl.so.1 => /lib/tls/libnsl.so.1 (0x4005d000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40071000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0x40091000) libpanel.so.5 => /usr/lib/libpanel.so.5 (0x400b9000) libncurses.so.5 => /lib/libncurses.so.5 (0x400bd000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0x400ff000) libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x401d6000) libz.so.1 => /usr/lib/libz.so.1 (0x401e5000) libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0x401f9000) libresolv.so.2 => /lib/tls/libresolv.so.2 (0x4022a000) libm.so.6 => /lib/tls/libm.so.6 (0x4023c000) libdl.so.2 => /lib/tls/libdl.so.2 (0x4025e000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x40262000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x40276000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x402d6000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x402f8000) libc.so.6 => /lib/tls/libc.so.6 (0x402fb000) libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x4043) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) $ ldd /usr/lib/php4/20020429/snmp.so libnetsnmp.so.5 => /usr/lib/libnetsnmp.so.5 (0x40018000) libm.so.6 => /lib/tls/libm.so.6 (0x400b5000) libwrap.so.0 => /lib/libwrap.so.0 (0x400d7000) libc.so.6 => /lib/tls/libc.so.6 (0x400e) libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x40215000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) libnsl.so.1 => /lib/tls/libnsl.so.1 (0x40317000) libdl.so.2 => /lib/tls/libdl.so.2 (0x4032b000) $ ls -l /usr/lib/libnetsnmp.so.5 lrwxrwxrwx 1 root root 19 2005-07-28 09:54 /usr/lib/libnetsnmp.so.5 -> libnetsnmp.so.5.2.1 $ cat test.php $ php test.php Warning: snmpget(): No response from localhost in /home/jl/test.php on line 2 zsh: segmentation fault php test.php (the agent is alive, i get "STRING: Linux 2.6.8-2-k7-smp #1 SMP Thu May 19 18:14:00 JST 2005 i686" with snmp 5.1.2) Tell me if you really want the strace, it is quite big, and i don't see much more interesting information except the open of snmp.so and libnetsnmp.so.5. -- Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320172: SNMP data gathering with cacti stops functioning since upgrade of snmp from 5.1.2 to 5.2.1.
sean finney a écrit : does calling snmpget from the cmdline give a segfault? i'm trying to understand exactly where the problem is... and i'm suspecting that it may not be in cacti but the snmp cmdline utilities, the snmp libraries, or the php snmp support. Indeed, I tested snmpget from command line utility and from php: * CLI snmpget works as well with 5.2.1 as with 5.1.2 * PHP snmpget works with 5.1.2 but segfaults with 5.2.1. I tested with several snmp agents to be sure. I think you're right, SNMP has been updated recently, but not PHP. Maybe the php4-snmp package must be rebuilt. I'll stick with snmp 5.1.2 for now. Thanks! -- Julien
Bug#320172: SNMP data gathering with cacti stops functioning since upgrade of snmp from 5.1.2 to 5.2.1.
Package: cacti Version: 0.8.6f-2 Severity: important cacti versions tested: 0.8.6e-1, 0.8.6f-2 net-snmp versions tested: 5.1.2, 5.2.1 No snmp data source can be updated with snmp 5.2.1, whereas all works well with 5.1.2 (went back to 5.1.2 to test). Here is an excerpt of cacti 0.8.6f-2 log with snmp 5.2.1: 07/27/2005 01:42:36 PM - PHPSVR: Poller[0] DEBUG: SERVER: cmd 07/27/2005 01:42:36 PM - PHPSVR: Poller[0] DEBUG: GETCWD: /usr/share/cacti/site 07/27/2005 01:42:36 PM - PHPSVR: Poller[0] DEBUG: DIRNAM: /usr/share/cacti/site 07/27/2005 01:42:36 PM - PHPSVR: Poller[0] DEBUG: FILENM: /usr/share/cacti/site/script_server.php 07/27/2005 01:42:36 PM - PHPSVR: Poller[0] PHP Script Server has Started - Parent is cmd 07/27/2005 01:42:36 PM - CMDPHP: Poller[0] PHP Script Server Started Properly 07/27/2005 01:42:40 PM - PHPSVR: Poller[0] ERROR: Input Expected, Script Server Terminating I suspected SNMP when I saw a segfault when running cmd.php by hand. I tracked it until I found it in a call to snmpget. The segfault disappears when downgrading snmp packages to 5.1.2. Thanks, -- Julien Leproust -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.8-2-k7-smp Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages cacti depends on: ii apache2-mpm-prefork [apache2 2.0.54-4traditional model for Apache2 ii debconf 1.4.52 Debian configuration management sy ii libapache2-mod-php4 4:4.3.10-15 server-side, HTML-embedded scripti ii libphp-adodb 4.52-1 The 'adodb' database abstraction l ii logrotate3.7-5 Log rotation utility ii mysql-client 4.0.24-10 mysql database client binaries ii php4 4:4.3.10-15 server-side, HTML-embedded scripti ii php4-cli 4:4.3.10-15 command-line interpreter for the p ii php4-mysql 4:4.3.10-15 MySQL module for php4 ii php4-snmp4:4.3.10-15 SNMP module for php4 ii rrdtool 1.0.49-1Time-series data storage and displ ii snmp 5.1.2-6.1 NET SNMP (Simple Network Managemen ii ucf 2.000 Update Configuration File: preserv Versions of packages cacti recommends: ii iputils-ping3:20020927-2 Tools to test the reachability of ii mysql-server4.0.24-10mysql database server binaries -- debconf information: * cacti/username: cacti * cacti/mysql_server: localhost * cacti/webserver: Apache2 cacti/upgrade_warning: * cacti/database: cacti cacti/mismatch: cacti/save_rootpw: true cacti/root_mysql: root * cacti/no_automagic: cacti/purge_db: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
