You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(4) |
2
|
3
(5) |
4
(7) |
5
(15) |
6
(11) |
|
7
(11) |
8
(3) |
9
(29) |
10
(2) |
11
(14) |
12
(10) |
13
(2) |
|
14
(4) |
15
(9) |
16
(4) |
17
|
18
|
19
|
20
|
|
21
|
22
|
23
(2) |
24
(14) |
25
(11) |
26
(3) |
27
(1) |
|
28
(4) |
29
(21) |
30
(12) |
|
|
|
|
|
From: Matthew T. <mat...@sy...> - 2003-09-11 17:35:06
|
Hello, I am investigating using valgrind for tracking MMIO access. Is it possible to configure valgrind to display reads and writes to memory locations if they can be determined? For example, debugging a XFree86 driver by looking at what what is written to different parts of memory. Obviously with instrumentation this would appear to be possible, but I am wondering if there is a valgrind skin that allows you to do something like... valgrind --skin=memwatch --region=000a0000-000c0000 X And consequently understand all the reads and writes (and possibly execution) of data and code in the BIOS. Looking forward to replies (and am more than willing to be a guinea pig!). Regards, Matthew |
|
From: <mat...@sy...> - 2003-09-11 17:31:08
|
Hello, I am investigating using valgrind for tracking MMIO access. Is it possible to configure valgrind to display reads and writes to memory locations if they can be determined? For example, debugging a XFree86 driver by looking at what what is written to different parts of memory. Obviously with instrumentation this would appear to be possible, but I am wondering if there is a valgrind skin that allows you to do something like... valgrind --skin=memwatch --region=000a0000-000c0000 X And consequently understand all the reads and writes (and possibly execution) of data and code in the BIOS. Looking forward to replies (and am more than willing to be a guinea pig!). Regards, Matthew |
|
From: Ashley P. <as...@pi...> - 2003-09-11 15:49:01
|
On Thu, 2003-09-11 at 16:02, Dirk Mueller wrote: > On Wednesday 10 September 2003 19:49, Kevin Olson wrote: > > > Is there any information on using VALGRIND with MPI programs ? > > Is there any problem when using VALGRIND with MPI applications? I've done it for simple applications. There are some cosmetic problems to do with the way MPI works. Normally with the stdout and std from all processes are sent to the same place so it can be difficult reading the output. This is a generic MPI problem though. luckily using the --logfile= option to valgrind automatically prepends the pid though so it's easy to use this to sanitise the output. Ashley, |
|
From: <ar...@de...> - 2003-09-11 15:47:59
|
Hi
I have several requests from users with a strange error whis is not
reproducible all the times. It seems to happen when network connections
are attempted. This error has been reproducible with packages such as
iptstate, nget and squid. The error is as follows:
==12707== Invalid read of size 1
==12707== at 0x403E159C: _dl_close (in /lib/libc-2.3.1.so)
==12707== by 0x403E2011: (within /lib/libc-2.3.1.so)
==12707== by 0x40009446: _dl_catch_error_internal (in
/lib/ld-2.3.1.so)
==12707== by 0x403E1F55: (within /lib/libc-2.3.1.so)
==12707== Address 0x1E7 is not stack'd, malloc'd or free'd
zsh: 12707 segmentation fault valgrind /usr/bin/iptstate
Any input would be appreciated.
--
Documentation is like sex: when it is good, it is very, very good; and
when it is bad, it is better than nothing.
-- Dick Brandon
|
|
From: Dirk M. <dm...@gm...> - 2003-09-11 15:38:43
|
On Thursday 11 September 2003 17:08, Paul A. Clarke wrote: > I had been running with 0.9.6, and just upgraded to 1.0.4. upgrading from a stone-age version to an obsolete one? Please try a current version first. |
|
From: Paul A. C. <pa...@us...> - 2003-09-11 15:31:45
|
Wait, nevermind. I'm an idiot. (I confused the versions, thinking 1.9.6 was really 0.9.6, and 1.0.4 was "obviously" an upgrade to it. I've since really upgraded to 20030725, and things work.) Sorry for the multiple intrusions. Regards, Paul Clarke On Thu, 2003-09-11 at 10:08, Paul A. Clarke wrote: > I had been running with 0.9.6, and just upgraded to 1.0.4. Now, > Valgrind faults immediately. Not being a Valgrind developer, this is > the best info I could extract for now: > > $ valgrind blah > Segmentation fault (core dumped) > $ gdb blah core > ... > Core was generated by `blah'. > Program terminated with signal 11, Segmentation fault. > ... > #0 process_cmd_line_options () at vg_main.c:642 > 642 } > (gdb) bt > #0 process_cmd_line_options () at vg_main.c:642 > #1 0x00000000 in ?? () > > Let me know if I can provide more/better info. > Regards, > PC |
|
From: Paul A. C. <pa...@us...> - 2003-09-11 15:08:57
|
I had been running with 0.9.6, and just upgraded to 1.0.4. Now, Valgrind faults immediately. Not being a Valgrind developer, this is the best info I could extract for now: $ valgrind blah Segmentation fault (core dumped) $ gdb blah core ... Core was generated by `blah'. Program terminated with signal 11, Segmentation fault. ... #0 process_cmd_line_options () at vg_main.c:642 642 } (gdb) bt #0 process_cmd_line_options () at vg_main.c:642 #1 0x00000000 in ?? () Let me know if I can provide more/better info. Regards, PC |
|
From: Dirk M. <dm...@gm...> - 2003-09-11 15:02:27
|
On Wednesday 10 September 2003 19:49, Kevin Olson wrote: > Is there any information on using VALGRIND with MPI programs ? Is there any problem when using VALGRIND with MPI applications? |
|
From: Brian H. <bhh...@ma...> - 2003-09-11 14:59:14
|
Trying to use valgrind on a product I support and it's not working - I
don't get any of the ==pid== output at all. One of my commands works,
one doesn't. I've been able to see the following difference - ldd under
valgrind does NOT show the valgrind library for the one that fails.
what's it mean? Do I need to build my code differently?
valgrind does NOT work on this one:
pdoslinux:~ # valgrind pdoswhoami
AOSUT0413E Unable to determine the ID of the invoker: 0x35a62780:
AOSSS1920E invalid parameter value (pd / oss)
pdoslinux:~ # valgrind ldd /opt/pdos/bin/pdoswhoami
==2646== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==2646== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==2646== Using valgrind-20030725, a program supervision framework for
x86-linux.
==2646== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==2646== Estimated CPU clock rate is 399 MHz
==2646== For more details, rerun with: -v
==2646==
libpthread.so.0 => /lib/libpthread.so.0 (0x40019000)
libosseal.so => /usr/lib/libosseal.so (0x4002e000)
libkosseal.so => /usr/lib/libkosseal.so (0x40095000)
libpdsvcutl.so => /usr/lib/libpdsvcutl.so (0x40098000)
libc.so.6 => /lib/libc.so.6 (0x400f5000)
libpdadminapi.so => /usr/lib/libpdadminapi.so (0x40214000)
libpdz.5.1.so => /usr/lib/libpdz.5.1.so (0x402c1000)
libmsg22.so => /usr/lib/libmsg22.so (0x4034c000)
libamserutl.so => /usr/lib/libamserutl.so (0x40367000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4041a000)
libm.so.6 => /lib/libm.so.6 (0x404ce000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x404f1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libdl.so.2 => /lib/libdl.so.2 (0x404f9000)
libgsk7km.so => /usr/lib/libgsk7km.so (0x404fd000)
libpdmgrapi.so => /usr/lib/libpdmgrapi.so (0x4059e000)
libpdauthzn.so => /usr/lib/libpdauthzn.so (0x40664000)
libpdmts.so => /usr/lib/libpdmts.so (0x406dc000)
liburaf.so => /usr/lib/liburaf.so (0x40753000)
libpdcore.so => /usr/lib/libpdcore.so (0x40780000)
libpdutil.so => /usr/lib/libpdutil.so (0x407d3000)
libgsk7cms.so => /usr/lib/libgsk7cms.so (0x407ef000)
libpdira.so => /usr/lib/libpdira.so (0x40975000)
libpdauthn.so => /usr/lib/libpdauthn.so (0x409c4000)
libgsomgmt.so => /usr/lib/libgsomgmt.so (0x409cf000)
libamaudutl.so => /usr/lib/libamaudutl.so (0x409ed000)
libamxalan-c.so => /usr/lib/libamxalan-c.so (0x40a20000)
libamxerces-c.so => /usr/lib/libamxerces-c.so (0x40d95000)
libgsk7ssl.so => /usr/lib/libgsk7ssl.so (0x4102c000)
libgsk7sys.so => /usr/lib/libgsk7sys.so (0x410a6000)
==2646==
==2646== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2646== malloc/free: in use at exit: 22967 bytes in 763 blocks.
==2646== malloc/free: 2905 allocs, 2142 frees, 89416 bytes allocated.
==2646== For a detailed leak analysis, rerun with: --leak-check=yes
==2646== For counts of detected errors, rerun with: -v
but does work here:
pdoslinux:~ # valgrind pdosversion
==2640== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==2640== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==2640== Using valgrind-20030725, a program supervision framework for
x86-linux.
==2640== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==2640== Estimated CPU clock rate is 398 MHz
==2640== For more details, rerun with: -v
==2640==
pdosversion 5.1.0.0 (030904a)
libosseald 5.1.0.0 (030904a)
libosseal 5.1.0.0 (030904a)
libkosseal 5.1.0.0 (030904a)
liblpm 5.1.0.0 (030904a)
==2640== Conditional jump or move depends on uninitialised value(s)
==2640== at 0x40008691: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2640== by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2640== by 0x405500C0: dl_open_worker (in /lib/libc.so.6)
==2640== by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==2640==
==2640== Conditional jump or move depends on uninitialised value(s)
==2640== at 0x40008695: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2640== by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2640== by 0x405500C0: dl_open_worker (in /lib/libc.so.6)
==2640== by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
LRD_AuditInput 5.1.0.0 (030904a)
==2640==
==2640== Conditional jump or move depends on uninitialised value(s)
==2640== at 0x400086FA: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2640== by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2640== by 0x405500C0: dl_open_worker (in /lib/libc.so.6)
==2640== by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==2640==
==2640== Conditional jump or move depends on uninitialised value(s)
==2640== at 0x4000872F: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2640== by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2640== by 0x405500C0: dl_open_worker (in /lib/libc.so.6)
==2640== by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
LRD_EmailOutput 5.1.0.0 (030904a)
LRD_FileOutput 5.1.0.0 (030904a)
LRD_NetOutput 5.1.0.0 (030904a)
==2640==
==2640== ERROR SUMMARY: 10 errors from 4 contexts (suppressed: 1 from 1)
==2640== malloc/free: in use at exit: 14412 bytes in 113 blocks.
==2640== malloc/free: 279 allocs, 166 frees, 56361 bytes allocated.
==2640== For a detailed leak analysis, rerun with: --leak-check=yes
==2640== For counts of detected errors, rerun with: -v
pdoslinux:~ # valgrind ldd /opt/pdos/bin/pdosversion
==2641== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==2641== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==2641== Using valgrind-20030725, a program supervision framework for
x86-linux.
==2641== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==2641== Estimated CPU clock rate is 399 MHz
==2641== For more details, rerun with: -v
==2641==
/usr/local/lib/valgrind/valgrinq.so =>
/usr/local/lib/valgrind/valgrinq.so (0x40014000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4001b000)
libosseal.so => /usr/lib/libosseal.so (0x40030000)
libosseald.so => /usr/lib/libosseald.so (0x40097000)
libkosseal.so => /usr/lib/libkosseal.so (0x400c1000)
liblpm.so => /usr/lib/liblpm.so (0x400c5000)
libpdsvcutl.so => /usr/lib/libpdsvcutl.so (0x40104000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40161000)
libm.so.6 => /lib/libm.so.6 (0x40215000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40238000)
libc.so.6 => /lib/libc.so.6 (0x40240000)
libdl.so.2 => /lib/libdl.so.2 (0x4035e000)
libpdadminapi.so => /usr/lib/libpdadminapi.so (0x40361000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4040f000)
libpdz.5.1.so => /usr/lib/libpdz.5.1.so (0x40440000)
libmsg22.so => /usr/lib/libmsg22.so (0x404cb000)
libamserutl.so => /usr/lib/libamserutl.so (0x404e6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libgsk7km.so => /usr/lib/libgsk7km.so (0x40599000)
libpdmgrapi.so => /usr/lib/libpdmgrapi.so (0x4063a000)
libpdauthzn.so => /usr/lib/libpdauthzn.so (0x40700000)
libpdmts.so => /usr/lib/libpdmts.so (0x40779000)
liburaf.so => /usr/lib/liburaf.so (0x407f0000)
libpdcore.so => /usr/lib/libpdcore.so (0x4081d000)
libpdutil.so => /usr/lib/libpdutil.so (0x40870000)
libgsk7cms.so => /usr/lib/libgsk7cms.so (0x4088b000)
libpdira.so => /usr/lib/libpdira.so (0x40a11000)
libpdauthn.so => /usr/lib/libpdauthn.so (0x40a60000)
libgsomgmt.so => /usr/lib/libgsomgmt.so (0x40a6c000)
libamaudutl.so => /usr/lib/libamaudutl.so (0x40a8a000)
libamxalan-c.so => /usr/lib/libamxalan-c.so (0x40abd000)
libamxerces-c.so => /usr/lib/libamxerces-c.so (0x40e32000)
libgsk7ssl.so => /usr/lib/libgsk7ssl.so (0x410c8000)
libgsk7sys.so => /usr/lib/libgsk7sys.so (0x41142000)
==2641==
==2641== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2641== malloc/free: in use at exit: 22970 bytes in 763 blocks.
==2641== malloc/free: 2905 allocs, 2142 frees, 89510 bytes allocated.
==2641== For a detailed leak analysis, rerun with: --leak-check=yes
==2641== For counts of detected errors, rerun with: -v
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-11 12:02:31
|
Hi, > I'm using the closed source ATI drivers for my Radeon 9000 and I want to > use > valgrind. But apparently there are similar problems as with Valgrind and > nVidia > cards. Does anyone know if there is a similar solution too? What sort of problems? It seems there are two sort of problems with nVidia drivers: * They use MMX/SSE instructions which are not supported by valgrind. This can be disabled by setting __GL_FORCE_GENERIC_CPU. Maybe ATI support a similar environment variable. Do they have some sort of mailing list you could ask to? Otherwise you'll have to revert to some other driver to run valgrind. On the other hand other drivers such as the XFree86 Matrox driver also contains MMX or SSE instructions. This leads me to think that valgrind is most often incompatible with OpenGL programs on Linux, because many OpenGL drivers use MMX instructions that can't be disabled. * They use NPTL on Red Hat 9, which is not supported by valgrind. This seems to be specific to nVidia and shouldn't affect you. Which Linux distribution are you running? -- Dimitri |
|
From: Jorrit T. <Jor...@uz...> - 2003-09-11 11:04:14
|
Hi all, I'm using the closed source ATI drivers for my Radeon 9000 and I want to use valgrind. But apparently there are similar problems as with Valgrind and nVidia cards. Does anyone know if there is a similar solution too? Greetings and thanks in advance, |
|
From: Kevin O. <ol...@bo...> - 2003-09-10 17:49:29
|
Hello, Is there any information on using VALGRIND with MPI programs ? Kevin Olson |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-10 12:33:05
|
Hi, > OK, I understand this is unrelated to __GL_FORCE_GENERIC_CPU and is > a bug in nVidia libraries. /lib/tls/libc.so.6 should have this > additional information: > OS ABI: Linux 2.4.20 > > Is that correct? If so, I'll send a bug report to nVidia. > > By the way, what is the role of these 'tls' subdirectories? Are they > supposed to specifically offer alternatives between NTPL and older > thread mechanisms? OK, I've now read this post: http://www.cs.helsinki.fi/linux/linux-kernel/2003-20/0672.html and it helped me understand the role of the 'tls' subdirectories: It is because you only compiled it with nptl support. In recent (nptl enabled) Redhat glibc's glibc is build two times. 1) without nptl 2) with nptl The version without nptl support is then installed into the 'default' location. The other is installed into /lib/tls/ and /usr/lib/tls/. ld.so is then hacked (maybe in mainline glibc now?) to load the tls enabled versions of the libraries only if the kernel/hardware support it. My understanding was that switching between libraries in /usr/lib/tls/ to /usr/lib/ or from /lib/tls/ to /lib/ was governed by simple rules based only on the location of libraries in either of these directories. In that scenario, library capability masks in specific don't play any role. Now my understanding is that ld.so actually looks into the capability mask inside libraries, in addition to the location of the libraries in tls/ subdirectories. I'm surprized by the lack of information on these new ld.so mechanisms. I wasn't able to find anything substantial in Google or Ulrich Drepper's home page http://people.redhat.com/drepper/. I guess I'll have to look into the ld.so source code. Does anyone have more information on this mechanism or a link that woudl explain it? -- Dimitri |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 16:04:58
|
Hi, > Move the libraries back where they were and try doing "ldconfig -p" > and see what you get. This is what I see for libc: > > audi [~] % ldconfig -p | grep libc.so > libc.so.6 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.4.20) => /lib/tls/libc.so.6 > libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6 > libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6 Ah! We're getting somewhere: # ldconfig -p | grep libGL.so libGL.so.1 (libc6, hwcap: 0x8000000000000000) => /usr/lib/tls/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/libGL.so.1 libGL.so (libc6, hwcap: 0x8000000000000000) => /usr/lib/tls/libGL.so libGL.so (libc6) => /usr/lib/libGL.so # There's no 'OS ABI' information in these libraries. > Note that the TLS library has an OS ABI of 2.4.20 which is why setting > the ABI to 2.4.1 with LD_ASSUME_KERNEL causes the i686 version to be > used. You should see something similar for those libGL instances and > if you don't then it would explain your problem. OK, I understand this is unrelated to __GL_FORCE_GENERIC_CPU and is a bug in nVidia libraries. /lib/tls/libc.so.6 should have this additional information: OS ABI: Linux 2.4.20 Is that correct? If so, I'll send a bug report to nVidia. By the way, what is the role of these 'tls' subdirectories? Are they supposed to specifically offer alternatives between NTPL and older thread mechanisms? -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 14:43:47
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> Is this bug in nVidia libraries? I'd be grateful if someone can
> rapidly explain the problem, so that I can report it to nVidia. From
> what I can understand nVidia libraries aren't properly tagged with
> capability masks, so LD_ASSUME_KERNEL doesn't have the expected
> effect. How to retrieve the capability mask of a library? What should
> the capability mask of /usr/lib/libGL.so and /usr/lib/tls/libGL.so
> look like?
Move the libraries back where they were and try doing "ldconfig -p"
and see what you get. This is what I see for libc:
audi [~] % ldconfig -p | grep libc.so
libc.so.6 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.4.20) => /lib/tls/libc.so.6
libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6
Note that the TLS library has an OS ABI of 2.4.20 which is why setting
the ABI to 2.4.1 with LD_ASSUME_KERNEL causes the i686 version to be
used. You should see something similar for those libGL instances and
if you don't then it would explain your problem.
You can also use objdump to look at the ABI declaration in the
libraries directly:
audi [~] % objdump -j .note.ABI-tag -s /lib/tls/libc.so.6
/lib/tls/libc.so.6: file format elf32-i386
Contents of section .note.ABI-tag:
42000134 04000000 10000000 01000000 474e5500 ............GNU.
42000144 00000000 02000000 04000000 14000000 ................
Here the last three words are 0x2, 0x4 and 0x14, or 2.2.20 in decimal.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 14:02:35
|
Hi, >>These are indeed added by the nVidia driver. But nVidia have always >>replaced the stock libGL with their own libGL. Could this be the >>problem? > > > It is the problem, the question is whether you can work around it. > > I see that you have /usr/lib/libGL.so as well as the TLS variant, so > it maybe that using that would resolve the problem. I would have > expected setting LD_ASSUME_KERNEL to do that though if the libraries > have been built correctly with the right capability masks. OK. I've temporarily moved /usr/lib/tls to /usr/lib/tls- and valgrind now runs on glxgears. There are lots of errors/warnings, but it runs: $ glxgears-valgrind ==5008== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==5008== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==5008== Using valgrind-20030725, a program supervision framework for x86-linux. ==5008== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==5008== Estimated CPU clock rate is 1995 MHz ==5008== For more details, rerun with: -v ==5008== ==5008== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains uninitialised or unaddressable byte(s) ==5008== at 0x402708D8: (within /usr/lib/libGL.so.1.0.4496) ==5008== Address 0xBFFFDF00 is on thread 1's stack ==5008== ==5008== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) [...] ==5008== ERROR SUMMARY: 2195 errors from 103 contexts (suppressed: 0 from 0) ==5008== malloc/free: in use at exit: 2149874 bytes in 418 blocks. ==5008== malloc/free: 1652 allocs, 1234 frees, 3488651 bytes allocated. ==5008== For a detailed leak analysis, rerun with: --leak-check=yes ==5008== For counts of detected errors, rerun with: -v $ Is this bug in nVidia libraries? I'd be grateful if someone can rapidly explain the problem, so that I can report it to nVidia. From what I can understand nVidia libraries aren't properly tagged with capability masks, so LD_ASSUME_KERNEL doesn't have the expected effect. How to retrieve the capability mask of a library? What should the capability mask of /usr/lib/libGL.so and /usr/lib/tls/libGL.so look like? -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 11:58:05
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> These are indeed added by the nVidia driver. But nVidia have always
> replaced the stock libGL with their own libGL. Could this be the
> problem?
It is the problem, the question is whether you can work around it.
I see that you have /usr/lib/libGL.so as well as the TLS variant, so
it maybe that using that would resolve the problem. I would have
expected setting LD_ASSUME_KERNEL to do that though if the libraries
have been built correctly with the right capability masks.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 11:20:12
|
Hi, >>What is the output on your machine? These are the libGL libraries >>available on my machine: >> >> >>$ locate libGL. >>/usr/lib/libGL.so.1.0.4496 >>/usr/lib/tls/libGL.so.1.0.4496 >>/usr/lib/tls/libGL.so.1 >>/usr/lib/tls/libGL.so >>/usr/lib/libGL.so.1 >>/usr/lib/libGL.so > > > I don't seem to have the TLS ones. This is what I have: > > audi [~] % locate libGL. > /usr/lib/libGL.so.1 > /usr/lib/libGL.so > /usr/X11R6/lib/libGL.so.1 > /usr/X11R6/lib/libGL.so.1.2 > /usr/X11R6/lib/libGL.a > /usr/X11R6/lib/libGL.so > > They are from the XFree86-Mesa-libGL-4.3.0-2 rpm. Presumably your > ones have come from some NVidia specific driver or something? I'm > using a Matrox G550 in this machine. These are indeed added by the nVidia driver. But nVidia have always replaced the stock libGL with their own libGL. Could this be the problem? -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 09:37:01
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 9 Sep 2003, Dimitri Papadopoulos-Orfanos wrote:
>
> > $ ldd /bin/ls
> > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000)
> > libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> > $
> > $ setenv LD_ASSUME_KERNEL 2.4.1
> > $
> > $ ldd /bin/ls
> > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000)
> > libc.so.6 => /lib/i686/libc.so.6 (0x40030000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> Um, those outputs aren't identical.
I think he meant identical to what I got.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-09-09 09:33:43
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> What is the output on your machine? These are the libGL libraries
> available on my machine:
>
>
> $ locate libGL.
> /usr/lib/libGL.so.1.0.4496
> /usr/lib/tls/libGL.so.1.0.4496
> /usr/lib/tls/libGL.so.1
> /usr/lib/tls/libGL.so
> /usr/lib/libGL.so.1
> /usr/lib/libGL.so
I don't seem to have the TLS ones. This is what I have:
audi [~] % locate libGL.
/usr/lib/libGL.so.1
/usr/lib/libGL.so
/usr/X11R6/lib/libGL.so.1
/usr/X11R6/lib/libGL.so.1.2
/usr/X11R6/lib/libGL.a
/usr/X11R6/lib/libGL.so
They are from the XFree86-Mesa-libGL-4.3.0-2 rpm. Presumably your
ones have come from some NVidia specific driver or something? I'm
using a Matrox G550 in this machine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 09:32:35
|
>>$ ldd /bin/ls >> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000) >> libc.so.6 => /lib/tls/libc.so.6 (0x42000000) >> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) >>$ >>$ setenv LD_ASSUME_KERNEL 2.4.1 >>$ >>$ ldd /bin/ls >> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000) >> libc.so.6 => /lib/i686/libc.so.6 (0x40030000) >> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > > Um, those outputs aren't identical. I mean they are (almost) identical to Tom's output. -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 09:31:13
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> The interesting thing is that valgrind also fails on a Red Hat 9
> machine with recent updates with a Matrox MGA G400 AGP card. But it
> fails differently:
I see the same with a G550 card.
> ==11019== Address 0xBFFFDDD4 is on thread 1's stack
> disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF
> disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF
These are SSE divide instructions which valgrind presumably doesn't
implement yet.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-09 09:24:39
|
On Tue, 9 Sep 2003, Dimitri Papadopoulos-Orfanos wrote: > > audi [~] % ldd /bin/ls > > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000) > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > audi [~] % LD_ASSUME_KERNEL=2.4.1 ldd /bin/ls > > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000) > > libc.so.6 => /lib/i686/libc.so.6 (0x40031000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > My machine runs Red Hat 9 with recent updates. The output of these same > commands on my machine is identical: > > $ ldd /bin/ls > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000) > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > $ > $ setenv LD_ASSUME_KERNEL 2.4.1 > $ > $ ldd /bin/ls > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000) > libc.so.6 => /lib/i686/libc.so.6 (0x40030000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Um, those outputs aren't identical. N |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 09:10:01
|
Hi, > I'll try different nVidia cards and see if that makes a difference. I've tried many of the following nVidia cards and the error message is always the same: NV25GL [Quadro4 700 XGL] NV15 [GeForce2 GTS/Pro] So this is probably not related to the card model. The interesting thing is that valgrind also fails on a Red Hat 9 machine with recent updates with a Matrox MGA G400 AGP card. But it fails differently: ==11019== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==11019== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==11019== Using valgrind-20030725, a program supervision framework for x86-linux. ==11019== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==11019== Estimated CPU clock rate is 548 MHz ==11019== For more details, rerun with: -v ==11019== ==11019== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==11019== at 0x404C2D24: __GI___ioctl (in /lib/libc-2.3.2.so) ==11019== by 0x417FE093: mgaInitDriver (in /usr/X11R6/lib/modules/dri/mga_dri.so) ==11019== by 0x416BBAC0: __driUtilCreateScreen (in /usr/X11R6/lib/modules/dri/mga_dri.so) ==11019== by 0x417FE884: __driCreateScreen (in /usr/X11R6/lib/modules/dri/mga_dri.so) ==11019== Address 0xBFFFDDD4 is on thread 1's stack disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF At this point the glxgears window hasn't appeared, valgrind has exited, and glxgears cannot be stopped using Ctrl+C or Ctrl+Z, one has to open another console to kill -9 it. -- Dimitri |
|
From: Paul L D. <pld...@pl...> - 2003-09-09 08:54:35
|
On Tue, 9 Sep 2003 00:54:42 -0700 (PDT) Kiran R <not...@ya...> wrote: > Hi All > > I am working on an application which has many modules...We have a build command to do the build > > To compile and generate .o files, we use build command followed by our filenames. > We cannot run it as ./executable-file... Are you trying to test your program in a modular form? If you are, then irrespective, you still need to have an executable in order for valgrind to be used. Regards. -- Paul L Daniels http://www.pldaniels.com Linux/Unix systems Internet Development ICQ#103642862,AOL:pldsoftware,IRC:inflex irc.freenode.net A.B.N. 19 500 721 806 |