[gentoo-user] Buffer overflow and nvclock terminates.
Hi folks, While checking some things earlier today I ran into a little issue. It seems glibc, nvclock or something has a issue and I'm not sure which one it would be. System info: r...@smoker / # emerge --info Portage 2.2_rc98 (default/linux/x86/10.0/desktop/kde, gcc-4.4.3, glibc-2.11.2-r0, 2.6.35-gentoo-r4 i686) = System uname: Linux-2.6.35-gentoo-r4-i686-AMD_Athlon-tm-_XP_2500+-with-gentoo-1.12.13 Timestamp of tree: Wed, 20 Oct 2010 22:15:02 + app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.13 sys-apps/sandbox:2.3-r1 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) I shortened that a bit but I think it has all that is needed. If not, let me know. This is the error I get: r...@smoker / # nvclock -i *** buffer overflow detected ***: nvclock terminated === Backtrace: = /lib/libc.so.6(__fortify_fail+0x50)[0xb7589850] /lib/libc.so.6(+0xe18aa)[0xb75878aa] /lib/libc.so.6(+0xe0f78)[0xb7586f78] /lib/libc.so.6(__overflow+0x4a)[0xb751070a] /lib/libc.so.6(_IO_vfprintf+0x50b9)[0xb74e7b39] /lib/libc.so.6(__vsprintf_chk+0xa7)[0xb7587027] /lib/libc.so.6(__sprintf_chk+0x2d)[0xb7586f6d] nvclock[0x8057317] [0x30322e34] === Memory map: 08048000-0806 r-xp 08:16 311032 /usr/bin/nvclock 0806-08061000 r--p 00017000 08:16 311032 /usr/bin/nvclock 08061000-08062000 rw-p 00018000 08:16 311032 /usr/bin/nvclock 082d-082f1000 rw-p 00:00 0 [heap] b72f9000-b7315000 r-xp 08:16 2070143 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b7315000-b7316000 r--p 0001b000 08:16 2070143 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b7316000-b7317000 rw-p 0001c000 08:16 2070143 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b733a000-b734a000 rw-s dc30 00:0d 8375 /dev/nvidia0 b734a000-b744a000 rw-s dc70 00:0d 8375 /dev/nvidia0 b744a000-b747a000 rw-s dc00 00:0d 8375 /dev/nvidia0 b747a000-b747b000 rw-p 00:00 0 b747b000-b747f000 r-xp 08:16 242258 /usr/lib/libXdmcp.so.6.0.0 b747f000-b748 r--p 3000 08:16 242258 /usr/lib/libXdmcp.so.6.0.0 b748-b7481000 rw-p 4000 08:16 242258 /usr/lib/libXdmcp.so.6.0.0 b7481000-b7483000 r-xp 08:16 179499 /usr/lib/libXau.so.6.0.0 b7483000-b7484000 r--p 1000 08:16 179499 /usr/lib/libXau.so.6.0.0 b7484000-b7485000 rw-p 2000 08:16 179499 /usr/lib/libXau.so.6.0.0 b7485000-b7486000 rw-p 00:00 0 b7486000-b7488000 r-xp 08:16 3019384/lib/libdl-2.11.2.so b7488000-b7489000 r--p 1000 08:16 3019384/lib/libdl-2.11.2.so b7489000-b748a000 rw-p 2000 08:16 3019384/lib/libdl-2.11.2.so b748a000-b74a4000 r-xp 08:16 2178229/usr/lib/libxcb.so.1.1.0 b74a4000-b74a5000 r--p 00019000 08:16 2178229/usr/lib/libxcb.so.1.1.0 b74a5000-b74a6000 rw-p 0001a000 08:16 2178229/usr/lib/libxcb.so.1.1.0 b74a6000-b75e6000 r-xp 08:16 3018521/lib/libc-2.11.2.so b75e6000-b75e8000 r--p 0013f000 08:16 3018521/lib/libc-2.11.2.so b75e8000-b75e9000 rw-p 00141000 08:16 3018521/lib/libc-2.11.2.so b75e9000-b75ec000 rw-p 00:00 0 b75ec000-b75fa000 r-xp 08:16 623393 /usr/lib/libXext.so.6.4.0 b75fa000-b75fb000 r--p d000 08:16 623393 /usr/lib/libXext.so.6.4.0 b75fb000-b75fc000 rw-p e000 08:16 623393 /usr/lib/libXext.so.6.4.0 b75fc000-b7718000 r-xp 08:16 2143515/usr/lib/libX11.so.6.3.0 b7718000-b7719000 r--p 0011b000 08:16 2143515/usr/lib/libX11.so.6.3.0 b7719000-b771c000 rw-p 0011c000 08:16 2143515/usr/lib/libX11.so.6.3.0 b7729000-b772b000 rw-s dc68 00:0d 8375 /dev/nvidia0 b772b000-b773b000 rw-s dc61 00:0d 8375 /dev/nvidia0 b773b000-b773d000 rw-s dc601000 00:0d 8375 /dev/nvidia0 b773d000-b773e000 rw-s dc10 00:0d 8375 /dev/nvidia0 b773e000-b773f000 rw-s dc101000 00:0d 8375 /dev/nvidia0 b773f000-b774 rw-p 00:00 0 b774-b7741000 r-xp 00:00 0 [vdso] b7741000-b775d000 r-xp 08:16 3019734/lib/ld-2.11.2.so b775d000-b775e000 r--p 0001b000 08:16 3019734/lib/ld-2.11.2.so b775e000-b775f000 rw-p 0001c000 08:16 3019734/lib/ld-2.11.2.so bf8be000-bf8df000 rw-p 00:00 0 [stack] Aborted r...@smoker / # So, is this nvclock? Is it gcc? Is it glibc? Is it something else? I haven't seen this with any other program so I'm thinking nvidia but I'm using the only version that provides nvclock in the tree. Sort of stuck here. Thoughts? Ideas? Dale :-) :-)
Re: [gentoo-user] Re: nouveau loads but freezes later, nvidia won't load
I've been using the nouveau video driver for a while, but lately video has been freezing with X at 100% CPU and the only way out seems to be ssh'ing in and rebooting. >>> >>> Not that it will help with your bug, but I'm curious to know what video >>> hardware you're using. I had the same problem with my ancient nv34 card, >>> which got fixed a few weeks ago in Linus's git kernel. >> >> I'm not sure of the actual chip, but I get this from lspci -v: >> >> nVidia Corporation C77 [GeForce 8100 / nForce 720a] >> >> It's an onboard chip on my motherboard. Can you tell me in what >> version of the Linux kernel you found the problem to be solved? > > In my particular case it was this commit, but I get the impression that > there > are still unfixed bugs that cause very similar symptoms: > > commit 3ba6462355c1c69dde58739a871d13bbb993e2e3 > Author: Francisco Jerez > Date: Sat Aug 28 17:56:33 2010 +0200 > > drm/nouveau: Take fence spinlock before reading the last sequence. > > It fixes a race between the TTM delayed work queue and the GEM IOCTLs > (fdo bug 29583) uncovered by the BKL removal. > > That patch was made on Aug 28, so Linus probably committed it in early > September, maybe 2.6.36-rc3 or thereabouts. > > If you're serious about testing the nouveau driver I suggest you try the > latest nouveau kernel sources from here: > > git://anongit.freedesktop.org/git/nouveau/linux-2.6 > > I just pulled the latest changes from that repository, approx 40 changesets, > and not one of them applies to my poor old forgotten NV34 chip, so I'm > losing > interest in nouveau at this point. But your hardware is much newer and it > may > be worth your while to test the latest changes. It's certainly easy to do. Thanks a lot Walt. - Grant
[gentoo-user] Re: nouveau loads but freezes later, nvidia won't load
On 10/20/2010 12:56 PM, Grant wrote: I've been using the nouveau video driver for a while, but lately video has been freezing with X at 100% CPU and the only way out seems to be ssh'ing in and rebooting. Not that it will help with your bug, but I'm curious to know what video hardware you're using. I had the same problem with my ancient nv34 card, which got fixed a few weeks ago in Linus's git kernel. I'm not sure of the actual chip, but I get this from lspci -v: nVidia Corporation C77 [GeForce 8100 / nForce 720a] It's an onboard chip on my motherboard. Can you tell me in what version of the Linux kernel you found the problem to be solved? In my particular case it was this commit, but I get the impression that there are still unfixed bugs that cause very similar symptoms: commit 3ba6462355c1c69dde58739a871d13bbb993e2e3 Author: Francisco Jerez Date: Sat Aug 28 17:56:33 2010 +0200 drm/nouveau: Take fence spinlock before reading the last sequence. It fixes a race between the TTM delayed work queue and the GEM IOCTLs (fdo bug 29583) uncovered by the BKL removal. That patch was made on Aug 28, so Linus probably committed it in early September, maybe 2.6.36-rc3 or thereabouts. If you're serious about testing the nouveau driver I suggest you try the latest nouveau kernel sources from here: git://anongit.freedesktop.org/git/nouveau/linux-2.6 I just pulled the latest changes from that repository, approx 40 changesets, and not one of them applies to my poor old forgotten NV34 chip, so I'm losing interest in nouveau at this point. But your hardware is much newer and it may be worth your while to test the latest changes. It's certainly easy to do.
Re: [gentoo-user] Re: nouveau loads but freezes later, nvidia won't load
>> I've been using the nouveau video driver for a while, but lately video >> has been freezing with X at 100% CPU and the only way out seems to be >> ssh'ing in and rebooting. > > Not that it will help with your bug, but I'm curious to know what video > hardware you're using. I had the same problem with my ancient nv34 card, > which got fixed a few weeks ago in Linus's git kernel. I'm not sure of the actual chip, but I get this from lspci -v: nVidia Corporation C77 [GeForce 8100 / nForce 720a] It's an onboard chip on my motherboard. Can you tell me in what version of the Linux kernel you found the problem to be solved? >> I tried to switch to the nvidia driver but X won't load and Xorg.0.log >> says it can't find a CorePointer device... > > Not sure why the nvidia driver would be related to that, unless maybe > you're using a different xorg.conf for nvidia. > > Unless you have some weird pointing devices, you should no longer need > any input section in xorg.conf for either keyboard or mouse -- delete any > references to keyboard or mouse, and install the xf86-input-evdev package. > Your X server should find and use the evdev driver automatically, without > any help from xorg.conf. I removed nouveau support from the kernel and nvidia loads properly. Strange that I get CorePointer messages if nouveau is loaded when nvidia tries to load. Those messages don't appear in the log after removing nouveau and loading nvidia. Weird. You actually solved this for me when you asked about the video chip. When I looked in lspci -v, I noticed that it said the nouveau driver was in use and that is what prompted me to remove it from the kernel. Thanks, Grant
Re: [gentoo-user] Upgrading from FX-5200 to a GeForce 6200 512MB
Paul Hartman wrote: MALLOC_CHECK_=0 nvclock -i It appears that it is more serious than that setting can overcome. Same error as before. I'm running glibc-2.11.2. Anyone having a similar issue with that version? Try to fix one thing and find something else broke. lol Dale :-) :-)
Re: [gentoo-user] Upgrading from FX-5200 to a GeForce 6200 512MB
On Wed, Oct 20, 2010 at 1:25 PM, Dale wrote:
> I appear to have another issue to deal with right now. This is weird. When
> I type in any nvclock command, I get something like this:
>
> r...@smoker / # nvclock -i
> *** buffer overflow detected ***: nvclock terminated
Seems like maybe that is glibc stopping you from running a program
with a (potential) buffer overflow. You can set an environment
variable to make it stop doing that and let you run the program
anyway, assuming you don't want to edit nvclock's source code to fix
the problem. :)
Try:
MALLOC_CHECK_=0 nvclock -i
("man malloc" for more info)
Re: [gentoo-user] Upgrading from FX-5200 to a GeForce 6200 512MB
Paul Hartman wrote: On Tue, Oct 19, 2010 at 11:12 PM, Dale wrote: I'm wondering if the card may be getting hot and slowing down because of that? i replaced the heat sink a good while back and I got more than enough cooling on the case. The heat sink has a fan and maybe it is not turning or something. I did blow out the dust a while back and I do have filters over the intakes to help some. Some Nvidia cards can go into a slow-motion mode when they overheat, I had that happen on mine (it was a 6000 or 7000 series, I think) when the fan died and I didn't realize it. The slowdown was dramatic in those cases. It would usually happen if I was playing a game or a video, suddenly it would go 2 frames per second. I'd stop the game/video, and even things like opening a window were slow. After a minute or two, everything would be back to normal speed. Eventually I learned that the card was protecting itself by switching to an ultra-slow mode to try to fight the overheating. nvidia-settings may be able to show you the temperature and speeds on your card. You might need to add: Option "coolbits" "1" to the device section in your xorg.conf to get it to show you some of those options if they aren't initially visible. I appear to have another issue to deal with right now. This is weird. When I type in any nvclock command, I get something like this: r...@smoker / # nvclock -i *** buffer overflow detected ***: nvclock terminated === Backtrace: = /lib/libc.so.6(__fortify_fail+0x50)[0xb75af850] /lib/libc.so.6(+0xe18aa)[0xb75ad8aa] /lib/libc.so.6(+0xe0f78)[0xb75acf78] /lib/libc.so.6(__overflow+0x4a)[0xb753670a] /lib/libc.so.6(_IO_vfprintf+0x50b9)[0xb750db39] /lib/libc.so.6(__vsprintf_chk+0xa7)[0xb75ad027] /lib/libc.so.6(__sprintf_chk+0x2d)[0xb75acf6d] nvclock[0x8057317] [0x30322e34] === Memory map: 08048000-0806 r-xp 08:16 311032 /usr/bin/nvclock 0806-08061000 r--p 00017000 08:16 311032 /usr/bin/nvclock 08061000-08062000 rw-p 00018000 08:16 311032 /usr/bin/nvclock 09369000-0938a000 rw-p 00:00 0 [heap] b731f000-b733b000 r-xp 08:16 2070143 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b733b000-b733c000 r--p 0001b000 08:16 2070143 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b733c000-b733d000 rw-p 0001c000 08:16 2070143 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b736-b737 rw-s dc30 00:0d 8375 /dev/nvidia0 b737-b747 rw-s dc70 00:0d 8375 /dev/nvidia0 b747-b74a rw-s dc00 00:0d 8375 /dev/nvidia0 b74a-b74a1000 rw-p 00:00 0 b74a1000-b74a5000 r-xp 08:16 242258 /usr/lib/libXdmcp.so.6.0.0 b74a5000-b74a6000 r--p 3000 08:16 242258 /usr/lib/libXdmcp.so.6.0.0 b74a6000-b74a7000 rw-p 4000 08:16 242258 /usr/lib/libXdmcp.so.6.0.0 b74a7000-b74a9000 r-xp 08:16 179499 /usr/lib/libXau.so.6.0.0 b74a9000-b74aa000 r--p 1000 08:16 179499 /usr/lib/libXau.so.6.0.0 b74aa000-b74ab000 rw-p 2000 08:16 179499 /usr/lib/libXau.so.6.0.0 b74ab000-b74ac000 rw-p 00:00 0 b74ac000-b74ae000 r-xp 08:16 3019384/lib/libdl-2.11.2.so b74ae000-b74af000 r--p 1000 08:16 3019384/lib/libdl-2.11.2.so b74af000-b74b rw-p 2000 08:16 3019384/lib/libdl-2.11.2.so b74b-b74ca000 r-xp 08:16 2178229/usr/lib/libxcb.so.1.1.0 b74ca000-b74cb000 r--p 00019000 08:16 2178229/usr/lib/libxcb.so.1.1.0 b74cb000-b74cc000 rw-p 0001a000 08:16 2178229/usr/lib/libxcb.so.1.1.0 b74cc000-b760c000 r-xp 08:16 3018521/lib/libc-2.11.2.so b760c000-b760e000 r--p 0013f000 08:16 3018521/lib/libc-2.11.2.so b760e000-b760f000 rw-p 00141000 08:16 3018521/lib/libc-2.11.2.so b760f000-b7612000 rw-p 00:00 0 b7612000-b762 r-xp 08:16 623393 /usr/lib/libXext.so.6.4.0 b762-b7621000 r--p d000 08:16 623393 /usr/lib/libXext.so.6.4.0 b7621000-b7622000 rw-p e000 08:16 623393 /usr/lib/libXext.so.6.4.0 b7622000-b773e000 r-xp 08:16 2143515/usr/lib/libX11.so.6.3.0 b773e000-b773f000 r--p 0011b000 08:16 2143515/usr/lib/libX11.so.6.3.0 b773f000-b7742000 rw-p 0011c000 08:16 2143515/usr/lib/libX11.so.6.3.0 b774f000-b7751000 rw-s dc68 00:0d 8375 /dev/nvidia0 b7751000-b7761000 rw-s dc61 00:0d 8375 /dev/nvidia0 b7761000-b7763000 rw-s dc601000 00:0d 8375 /dev/nvidia0 b7763000-b7764000 rw-s dc10 00:0d 8375 /dev/nvidia0 b7764000-b7765000 rw-s dc101000 00:0d 8375 /dev/nvidia0 b7765000-b7766000 rw-p 00:00 0 b7766000-b7767000 r-xp 00:00 0 [vdso] b7767000-b7783000 r-xp 08:16 3019734/lib/ld-2.11.2.so b7783000-b7784000 r--p 0001b000 08:16 3019734/lib/ld-2.11.2.so b7784000-b7785000 rw-p 0001c000 08:16 3019734/lib/ld-2.11.2.so bfe28000-bfe49000 rw-p 00:00 0 [stack] Aborted r...@smoker / # I guess I'll have to take the side off the
Re: [gentoo-user] Upgrading from FX-5200 to a GeForce 6200 512MB
On Tue, Oct 19, 2010 at 11:12 PM, Dale wrote: > I'm wondering if the card may be getting hot and slowing down because of > that? i replaced the heat sink a good while back and I got more than enough > cooling on the case. The heat sink has a fan and maybe it is not turning or > something. I did blow out the dust a while back and I do have filters over > the intakes to help some. Some Nvidia cards can go into a slow-motion mode when they overheat, I had that happen on mine (it was a 6000 or 7000 series, I think) when the fan died and I didn't realize it. The slowdown was dramatic in those cases. It would usually happen if I was playing a game or a video, suddenly it would go 2 frames per second. I'd stop the game/video, and even things like opening a window were slow. After a minute or two, everything would be back to normal speed. Eventually I learned that the card was protecting itself by switching to an ultra-slow mode to try to fight the overheating. nvidia-settings may be able to show you the temperature and speeds on your card. You might need to add: Option "coolbits" "1" to the device section in your xorg.conf to get it to show you some of those options if they aren't initially visible.
Re: [gentoo-user] Which Comes First, the Unmask or the Mask?
On 10/20/10 04:06:52, Andy Wilkinson wrote: > I believe I know the answer to the question... the real question is, > how can I work around it? ;) > > I am running the development branch of www-client/chromium (currently > 8.0.552.0). As a result, I like the latest builds to always be > unmasked > when they are available. However, once in a while there is a bad > apple > in the bunch and I'd like to mask that atom specifically. 8.0.552.0 > is > one of those that I would like masked. > > What I'd like to do is: > > /etc/portage/package.unmask: > www-client/chromium > > /etc/portage/package.mask: > =www-client/chromium-8.0.552.0 > > This case shows that, in fact, the mask comes first, as the atom in > question is definitely unmasked in that scenario. I have tried > putting > either line into /etc/portage/profile/package.mask or .unmask, to no > effect. > > I know I could do this by putting noninclusive comparative statements > in > .unmask, ala: > > >www-client/chromium-8.0.552.0 > > But this seems somewhat clumsy to me. Does anyone know a trick to do > what I'm looking for? > I usually comment out the line in package.unmask if I want the mask to be effective. A line in /etc/portage/package.unmask overrules a line in /etc/portage/package.mask . Helmut.
Re: [gentoo-user] gcc upgrade: Active gcc profile is invalid!
+1 2010/10/20 Neil Bothwick > On Tue, 19 Oct 2010 20:57:18 +0200, Jarry wrote: > > > I just think it is somehow time-consuming, emerging gcc two times. > > Especially when I have to repeat it with my 12 gentoo servers. > > Sequentially, unfortunatally, as they share the same hardware... > > Why not use --buildpkg the first time and --usepkg the other 11 times? > > > -- > Neil Bothwick > > deja vous - the act of forgetting someone's name /again/ despite being > introduced to them several times. > -- Jian Li
