Bug#456028: knotes uses a *lot* of memory
Package: knotes
Version: 4:3.5.8-1
Severity: normal
knotes seems to use a lot of memory, memory that is unique to it's
process (not shared).
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
[...]
cw9504 0.1 2.2 249300 94312 ?S12:36 0:21 knotes -session
[...]
[EMAIL PROTECTED]:~$ # see how much of that is private to that process
[EMAIL PROTECTED]:~$ awk '($0 ~ /^Private/) {s+=$2} END{print s}' /proc/$(pidof
knotes)/smaps
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-rc5-cw3 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages knotes depends on:
ii kdelibs4c2a 4:3.5.8.dfsg.1-4 core libraries and binaries for al
ii libc6 2.7-4GNU C Library: Shared libraries
ii libgcc1 1:4.2.2-4GCC support library
ii libkcal2b 4:3.5.8-1KDE calendaring library
ii libkdepim1a 4:3.5.8-1KDE PIM library
ii libqt3-mt 3:3.3.7-9Qt GUI Library (Threaded runtime v
ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3
ii libx11-62:1.0.3-7X11 client-side library
knotes recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318989: xlibmesa-dri: glx applications segfault inside r128_dri.so
> About 2 years ago, you reported a bug to the Debian BTS regarding a > segfault of the r128 DRI driver when requested a large resolution > with big depth. > Did you reproduce this problem recently? If not, I will close this > bug in the next weeks. i dont use the hardware anymore, i think it was still there but harder to trigger fwiw, i think i got a chance to talk to the driver author on irc and it was a known problem that wasn't interesting to fix because the hardware is old and rarely used, but my memory is pretty vague about this please do close the bug by all means or mark it as WONTFIX or whatever, it's not useful chasing this -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318989: xlibmesa-dri: glx applications segfault inside r128_dri.so
On Tue, Jul 19, 2005 at 02:10:36PM +0200, David Mart?nez Moreno wrote:
> So...could you please send a diff between the resulted configuration
> and your working configuration, to know what possible parameters are
> recommended for Radeon users? Come on! :-)
I don't have a Radeon on this machine --- it's some ancient Rage
M3/128 thing ("ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02)"
reported by lspci).
As to why it doesn't crash anymore I'm not so sure, it turns out the
xorg.conf ended up being a verbatim copy of the XF86Config-4 file,
probably as part of the upgrade I had to manually that I didn't
notice.
As to why DRI is working now, I'm using a 16-bit visual not 24 or 32.
I guess I don't have enough video memory or something?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318989: xlibmesa-dri: glx applications segfault inside r128_dri.so
Further information and some more fiddling about: * I am able to get things to crash again using the xorg.conf that resulted from the xf86->org upgrade. Disabling direct rendering stops the crash. * The xorg.conf produced by installing xserver-xorg doesn't not crash as direct rendering does not work. * If I hand-edit the xorg.conf file 'the way I like it' then direct rendering does work again and does *NOT* crash. So there is something that's a little bit finicky here but things do appear to work if poked the right way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318989: xlibmesa-dri: glx applications segfault inside r128_dri.so
On Tue, Jul 19, 2005 at 09:27:30AM +0200, David Mart?nez Moreno wrote: > Excuse me, but I do not understand this. You claim to have > 6.8.2.dfsg.1-3, but your report has XFree86 logs and information. It is xorg stuff: [EMAIL PROTECTED]:~/Desktop$ dpkg --get-selections|grep xserver xserver-common install xserver-xfree86 deinstall xserver-xorginstall (i didn't deinstall'ed xserver-xfree86 but didn't purge it in case i needed to go back) > Maybe there is a problem with the xlibmesa-dri reportbug script. I suspect so, I didn't even think about it and just let it do it's thing. Thinking it might be partly because of the xf86->xorg upgrade process I purged xserver-common xserver-xfree86 xserver-xorg and some other cruft, moved the configuration files out the way and installed xserver-xorg and xlibmesa-dri letting it decide the configuration. DRI is now *not* working at all --- so I can no longer reproduce the crash (ie. no attempt to use direct render is made so things work albeit painfully slowly). > I will take a look this morning, but meanwhile, please supply > /etc/X11/xorg.conf and /var/log/Xorg.0.log. Attached are the files from *before* I reinstalled things above. These show DRI was being enabled then but diff'ing between the two configs I really have no idea why it won't work now or if these are useful given I can't reproduce the problem on a clean(ish) install. xorg.conf.bz2 Description: Binary data Xorg.0.log.bz2 Description: Binary data
Bug#318989: xlibmesa-dri: glx applications segfault inside r128_dri.so
Package: xlibmesa-dri Version: 6.8.2.dfsg.1-3 Severity: normal NOTE: when filing this bug I got: /usr/share/bug/xlibmesa-dri/script: line 47: 11375 Segmentation fault (core dumped) LIBGL_DEBUG=verbose glxinfo 1>&3 2>&1 Spawning emacs... glxinfo and friend crash inside the dri stuff. bt of glxinfo crash: (gdb) bt #0 0xb7b24199 in ?? () from /usr/X11R6/lib/modules/dri/r128_dri.so #1 0xbffd22c8 in ?? () #2 0xb7b2a216 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r128_dri.so #3 0xb7b2a216 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r128_dri.so #4 0xb7b28a53 in __driUtilUpdateDrawableInfo () from /usr/X11R6/lib/modules/dri/r128_dri.so #5 0xb7ef26e9 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 #6 0xb7ef2b81 in glXCreateContext () from /usr/X11R6/lib/libGL.so.1 #7 0x08049934 in ?? () #8 0x0804d008 in ?? () #9 0x080578a0 in ?? () #10 0x in ?? () #11 0x0001 in ?? () #12 0xbffd2404 in ?? () #13 0x in ?? () #14 0x0020 in ?? () #15 0xb7c7b438 in ?? () from /lib/tls/i686/cmov/libc.so.6 #16 0xb7dad000 in ?? () #17 0x in ?? () #18 0x0804d008 in ?? () #19 0x0001 in ?? () #20 0x in ?? () #21 0x in ?? () #22 0x000e in ?? () #23 0x0001 in ?? () #24 0xb7b7e3f0 in ?? () #25 0x0042 in ?? () #26 0xb7dad19c in ?? () #27 0xb7c8594b in ?? () from /lib/tls/i686/cmov/libc.so.6 #28 0x00fd2488 in ?? () #29 0xb7c83e58 in ?? () from /lib/tls/i686/cmov/libc.so.6 #30 0xbffd244c in ?? () #31 0xb7fc6b3c in _dl_unload_cache () from /lib/ld-linux.so.2 #32 0xb7c8d970 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #33 0x08048c41 in ?? () Infirect works: "LIBGL_ALWAYS_INDIRECT=1 glxinfo" is just fine: [EMAIL PROTECTED]:~$ LIBGL_ALWAYS_INDIRECT=1 glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 (1.5 Mesa 6.2.1) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -
Bug#298169: Also not reproducible
On Sat, Mar 05, 2005 at 04:43:49PM +0100, Helge Kreutzmann wrote: > Chris: How did you learn about this problem? Did you fiddle with > mpg321 (rebuilding, patching, ...)? I don't think this is the > problem, but if you reboot into a Debian supplied kernel and > re-install mpg321 (--purge remove then install), is it still suid? I noticed this when the owner of the files created was wrong. I didn't investigate much beyond that to be honest. I did not try purge + reinstall either. I probably should have tried that. Doing that now shows it is installed *without* the suid bit. I'm a bit at a loss to explain why it was like this (I'm pretty sure I would know if I did it) but anyhow, I guess it's a false report so close this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298169: mpg321 is setuid root and can be used to overwrite arbitrary files using -w
Package: mpg321 Version: 0.2.10.3 Severity: critical Tags: security mpg312 is installed setuid root probably to do scheduler magic or whatever (didn't check). Anyhow, this means you can invoke it using "mpg321 -w /etc/passwd foo/mp3" or whatever. For now I would suggest we remove the suid bit (clearly this has issues to, but those are less sever than being able to trash arbitrary files as non-root). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-rc4-cw Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mpg321 depends on: ii libao2 0.8.5-1 Cross Platform Audio Output Librar ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libid3tag0 0.15.1b-4ID3 tag reading library from the M ii libmad0 0.15.1b-1MPEG audio decoder library ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
