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
(5) |
|
2
(2) |
3
(15) |
4
(3) |
5
|
6
(11) |
7
(4) |
8
|
|
9
(3) |
10
(6) |
11
(4) |
12
(5) |
13
(7) |
14
(37) |
15
(8) |
|
16
(1) |
17
(19) |
18
(20) |
19
(20) |
20
(15) |
21
(13) |
22
|
|
23
|
24
(20) |
25
(6) |
26
(2) |
27
(4) |
28
(6) |
29
|
|
30
(5) |
|
|
|
|
|
|
|
From: <ar...@de...> - 2003-11-18 01:41:08
|
I've added a patch that solves this problem in former versions. Please, please upgrade. # apt-get update # apt-get install valgrind Per von Zweigbergk <pvz@e.kth.se> writes: > Hi. > > I'm running valgrind, as packaged with Debian/unstable > (valgrind-20031012). I'm getting the error message "unhandled > instruction bytes: 0xF 0xAE 0xF8 0xF" while trying to run tvtime (with > wine loading code disabled) through Valgrind. > > I managed to solve this problem by disabling the hand-coded MMX stuff > we were doing (after checking the FAQ). Again, I'm not familiar with > this particular code, but the FAQ said to inform you anyway, so here I > am. :-) > > The log: > > pvz@tanya:~/src/tvtime-0.9.11/src$ valgrind --skin=addrcheck -v ./tvtime > ==12575== Addrcheck, a fine-grained address checker for x86-linux. > ==12575== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==12575== Using valgrind-20031012, a program supervision framework for > x86-linux. > ==12575== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==12575== Command line: > ==12575== ./tvtime > ==12575== Startup, with flags: > ==12575== --suppressions=/usr/lib/valgrind/default.supp > ==12575== -v > ==12575== Reading syms from /home/pvz/src/tvtime-0.9.11/src/tvtime > ==12575== Reading syms from /lib/ld-2.3.2.so > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/lib/valgrind/vgskin_addrcheck.so > ==12575== Reading syms from /usr/lib/valgrind/valgrind.so > ==12575== Reading syms from /usr/lib/libSDL-1.2.so.0.0.6 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/lib/libfreetype.so.6.3.4 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/lib/libpng12.so.0.1.2.5 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/X11R6/lib/libSM.so.6.0 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/X11R6/lib/libICE.so.6.3 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/X11R6/lib/libX11.so.6.2 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/X11R6/lib/libXext.so.6.4 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/X11R6/lib/libXtst.so.6.1 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/lib/libxml2.so.2.5.11 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/lib/libz.so.1.1.4 > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /lib/libdl-2.3.2.so > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /lib/libm-2.3.2.so > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading syms from /usr/lib/valgrind/libpthread.so > ==12575== Reading syms from /lib/libc-2.3.2.so > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > ==12575== Reading suppressions file: /usr/lib/valgrind/default.supp > ==12575== Estimated CPU clock rate is 1208 MHz > ==12575== REPLACING libc(__errno_location) with libpthread(__errno_location) > ==12575== REPLACING libc(__h_errno_location) with > libpthread(__h_errno_location) > ==12575== REPLACING libc(__res_state) with libpthread(__res_state) > ==12575== > ==12575== TRANSLATE: 0x405A5FC0 redirected to 0x4056B14E > Kör tvtime 0.9.11. > ==12575== Reading syms from /usr/lib/gconv/ISO8859-1.so > ==12575== object doesn't have a symbol table > ==12575== object doesn't have any debug info > rtctimer: Cannot set periodic interval: Åtkomst nekas > > Kunde inte få en upplösning på 1024 Hz från din RTC-enhet. Tillgång > till hög upplösning är nödvändigt för mjuk videouppspelning. Kör > tvtime som root, sätt tvtime som SUID-root, eller ändra den maximala > tillåtna RTC-upplösningen för användarprocesser genom att köra > följande kommando som root: > sysctl -w dev.rtc.max-user-freq=1024 > Se vår hjälpsida: http://tvtime.net/ för mer information. > > Läser inställningar från /usr/local/etc/tvtime/tvtime.xml > Läser inställningar från /home/pvz/.tvtime/tvtime.xml > disInstr: unhandled instruction bytes: 0xF 0xAE 0xF8 0xF > Otillåten instruktion > pvz@tanya:~/src/tvtime-0.9.11/src$ > > > > > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Andres Roldan Fluidsignal Group <ar...@fl...> The Debian Project <ar...@de...> GIGAX <ar...@gi...> GPG Key-ID 0xB29396EB Home Page http://people.fluidsignal.com/~aroldan |
|
From: Dirk M. <dm...@gm...> - 2003-11-18 01:40:02
|
On Monday 17 November 2003 18:45, Nicholas Nethercote wrote: > Try the patch below; I've tested it minimally. IMHO we should commit this to CVS. |
|
From: <ar...@de...> - 2003-11-18 01:39:35
|
Upgrade to the new valgrind version (1:2.0.0-3) of debian. Thanks. Per von Zweigbergk <pvz@e.kth.se> writes: > Hi. > > Trying to get valgrind to attach to GDB at run-time -- which > fails. I'm suspecting i need to specify the string "gdb" somewhere for > it to find gdb -- since runnin 'gdb -nw /proc/13594/exe 13594' does > what I want it to. > > > Log follows: > > pvz@tanya:~/src/tvtime-0.9.11/src$ valgrind --skin=memcheck > --gdb-attach=yes ./tvtime > ==13594== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==13594== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==13594== Using valgrind-20031012, a program supervision framework for > x86-linux. > ==13594== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==13594== Estimated CPU clock rate is 1207 MHz > ==13594== For more details, rerun with: -v > ==13594== > Kör tvtime 0.9.11. > ==13594== Conditional jump or move depends on uninitialised value(s) > ==13594== at 0x40008ABA: _dl_relocate_object_internal (in > /lib/ld-2.3.2.so) > ==13594== by 0x406B1CF0: (within /lib/libc-2.3.2.so) > ==13594== by 0x4000B115: _dl_catch_error_internal (in /lib/ld-2.3.2.so) > ==13594== by 0x406B1F5B: _dl_open (in /lib/libc-2.3.2.so) > ==13594== > ==13594== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y > ==13594== starting GDB with cmd: -nw /proc/13594/exe 13594 > /bin/sh: line 1: -nw: command not found > ==13594== > ==13594== GDB has detached. Valgrind regains control. We continue. > ==13594== > ==13594== Conditional jump or move depends on uninitialised value(s) > ==13594== at 0x40008B05: _dl_relocate_object_internal (in > /lib/ld-2.3.2.so) > ==13594== by 0x406B1CF0: (within /lib/libc-2.3.2.so) > ==13594== by 0x4000B115: _dl_catch_error_internal (in /lib/ld-2.3.2.so) > ==13594== by 0x406B1F5B: _dl_open (in /lib/libc-2.3.2.so) > ==13594== > ==13594== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- > > > > > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Andres Roldan Fluidsignal Group <ar...@fl...> The Debian Project <ar...@de...> GIGAX <ar...@gi...> GPG Key-ID 0xB29396EB Home Page http://people.fluidsignal.com/~aroldan |
|
From: Dirk M. <dm...@gm...> - 2003-11-18 01:38:13
|
On Tuesday 18 November 2003 01:43, Per von Zweigbergk wrote: > Trying to get valgrind to attach to GDB at run-time -- which fails. I'm > suspecting i need to specify the string "gdb" somewhere for it to find > gdb -- since runnin 'gdb -nw /proc/13594/exe 13594' does what I want it to. apparently the package was miscompiled, report to the debian maintainer. it uses the path it found during ./configure. |
|
From: Dirk M. <dm...@gm...> - 2003-11-18 01:37:00
|
On Tuesday 18 November 2003 01:31, Per von Zweigbergk wrote: > 0xF 0xAE 0xF8 0xF SFENCE if I decode that correctly. Use valgrind 2.0. |
|
From: Jeremy F. <je...@go...> - 2003-11-18 01:05:20
|
On Mon, 2003-11-17 at 16:48, Tyler Nielsen wrote: > disInstr: unhandled instruction bytes: 0xF 0xD 0x8A 0x80 > Illegal instruction > > I'm not to good at this, but I think it's the prefetchw command. Any > idea how difficult this is to implement? prefetchw - that's an AMD 3dnow! instruction right? I think it's a bug in your distro if it's using 3dnow instructions on a CPU which doesn't claim to support them (unless, of course, we are claiming to do so accidentally). What's your CPU? J |
|
From: Dan K. <da...@ke...> - 2003-11-18 00:54:08
|
Per von Zweigbergk wrote: > Hi. > > Trying to get valgrind to attach to GDB at run-time -- which fails. I'm > suspecting i need to specify the string "gdb" somewhere for it to find > gdb -- since runnin 'gdb -nw /proc/13594/exe 13594' does what I want it to. > ... > ==13594== starting GDB with cmd: -nw /proc/13594/exe 13594 > /bin/sh: line 1: -nw: command not found FWIW, here are the hoops I had to jump through to get valgrind to let me launch gdb when valgrinding openoffice: http://kegel.com/openoffice/#valgrind.gdb Hopefully you won't have to do all that junk, but maybe it'll give you an idea. - Dan --- snip --- You can have valgrind launch gdb when it runs into an error; then you can do all the backtracing and printing of variabls you like. To do this, add the option --gdb-attach=yes. This doesn't work quite right, since OpenOffice appears to close stdin. Here's one way to work around that: 1. Create a little script named ~/rungdb containing #!/bin/sh XAUTHORITY=~/.Xauthority DISPLAY=127.0.0.1:0.0 /usr/X11R6/bin/xterm -e gdb "$@" Be sure to chmod +x ~/rungdb. The script is started without the normal environment variables, so you need to explicitly set any that are needed. The above is for Red Hat Linux 8.0. If the crash you're seeing happens to happen while the X display lock is held, you'll probably want to set DISPLAY to some other host's X display... that actually happened to me once. Then run OpenOffice with the command #!/bin/sh bin=/opt/OpenOffice.org1.1.0/program LD_LIBRARY_PATH=$bin valgrind -v --skin=addrcheck \ --gdb-attach=yes --gdb-command=~/rungdb \ $bin/soffice.bin That will pop up an xterm with a gdb inside it every time you say 'yes' when valgrind asks whether to start gdb. Note that all you can do in that gdb is get a backtrace; you can't continue the program. You must quit gdb before valgrind will continue. --- snip --- |
|
From: Tyler N. <tyl...@co...> - 2003-11-18 00:48:24
|
Trying to get valgrind to work on a new system. I am getting this as the output for ls (and several other programs) ==20208== Command line: ==20208== ls ==20208== Startup, with flags: ==20208== --suppressions=/usr/lib/valgrind/default.supp ==20208== -v ==20208== Reading syms from /bin/ls ==20208== object doesn't have a symbol table ==20208== object doesn't have any debug info ==20208== Reading syms from /lib/ld-2.3.2.so ==20208== object doesn't have any debug info ==20208== Reading syms from /usr/lib/valgrind/vgskin_memcheck.so ==20208== object doesn't have any debug info ==20208== Reading syms from /usr/lib/valgrind/valgrind.so ==20208== object doesn't have any debug info ==20208== Reading syms from /usr/lib/valgrind/libpthread.so ==20208== object doesn't have any debug info ==20208== Reading syms from /lib/librt-2.3.2.so ==20208== object doesn't have any debug info ==20208== Reading syms from /lib/libc-2.3.2.so ==20208== object doesn't have any debug info ==20208== Reading suppressions file: /usr/lib/valgrind/default.supp ==20208== Estimated CPU clock rate is 2121 MHz ==20208== REPLACING libc(__GI___errno_location) with libpthread(__errno_location) ==20208== REPLACING libc(__GI___h_errno_location) with libpthread(__h_errno_location) ==20208== REPLACING libc(__GI___res_state) with libpthread(__res_state) ==20208== ==20208== TRANSLATE: 0x402A1980 redirected to 0x4023B13A disInstr: unhandled instruction bytes: 0xF 0xD 0x8A 0x80 Illegal instruction I'm not to good at this, but I think it's the prefetchw command. Any idea how difficult this is to implement? Tyler Nielsen |
|
From: Per v. Z.
|
Hi. Trying to get valgrind to attach to GDB at run-time -- which fails. I'm=20 suspecting i need to specify the string "gdb" somewhere for it to find=20 gdb -- since runnin 'gdb -nw /proc/13594/exe 13594' does what I want it t= o. Log follows: pvz@tanya:~/src/tvtime-0.9.11/src$ valgrind --skin=3Dmemcheck=20 --gdb-attach=3Dyes ./tvtime =3D=3D13594=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for = x86-linux. =3D=3D13594=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian Sewar= d. =3D=3D13594=3D=3D Using valgrind-20031012, a program supervision framewor= k for=20 x86-linux. =3D=3D13594=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian Sewar= d. =3D=3D13594=3D=3D Estimated CPU clock rate is 1207 MHz =3D=3D13594=3D=3D For more details, rerun with: -v =3D=3D13594=3D=3D K=F6r tvtime 0.9.11. =3D=3D13594=3D=3D Conditional jump or move depends on uninitialised value= (s) =3D=3D13594=3D=3D at 0x40008ABA: _dl_relocate_object_internal (in=20 /lib/ld-2.3.2.so) =3D=3D13594=3D=3D by 0x406B1CF0: (within /lib/libc-2.3.2.so) =3D=3D13594=3D=3D by 0x4000B115: _dl_catch_error_internal (in /lib/ld-= 2.3.2.so) =3D=3D13594=3D=3D by 0x406B1F5B: _dl_open (in /lib/libc-2.3.2.so) =3D=3D13594=3D=3D =3D=3D13594=3D=3D ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y =3D=3D13594=3D=3D starting GDB with cmd: -nw /proc/13594/exe 13594 /bin/sh: line 1: -nw: command not found =3D=3D13594=3D=3D =3D=3D13594=3D=3D GDB has detached. Valgrind regains control. We contin= ue. =3D=3D13594=3D=3D =3D=3D13594=3D=3D Conditional jump or move depends on uninitialised value= (s) =3D=3D13594=3D=3D at 0x40008B05: _dl_relocate_object_internal (in=20 /lib/ld-2.3.2.so) =3D=3D13594=3D=3D by 0x406B1CF0: (within /lib/libc-2.3.2.so) =3D=3D13594=3D=3D by 0x4000B115: _dl_catch_error_internal (in /lib/ld-= 2.3.2.so) =3D=3D13594=3D=3D by 0x406B1F5B: _dl_open (in /lib/libc-2.3.2.so) =3D=3D13594=3D=3D =3D=3D13594=3D=3D ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- |
|
From: Per v. Z.
|
Hi.
I'm running valgrind, as packaged with Debian/unstable=20
(valgrind-20031012). I'm getting the error message "unhandled=20
instruction bytes: 0xF 0xAE 0xF8 0xF" while trying to run tvtime (with=20
wine loading code disabled) through Valgrind.
I managed to solve this problem by disabling the hand-coded MMX stuff we=20
were doing (after checking the FAQ). Again, I'm not familiar with this=20
particular code, but the FAQ said to inform you anyway, so here I am. :-)
The log:
pvz@tanya:~/src/tvtime-0.9.11/src$ valgrind --skin=3Daddrcheck -v ./tvtim=
e
=3D=3D12575=3D=3D Addrcheck, a fine-grained address checker for x86-linux.
=3D=3D12575=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian Sewar=
d.
=3D=3D12575=3D=3D Using valgrind-20031012, a program supervision framewor=
k for=20
x86-linux.
=3D=3D12575=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian Sewar=
d.
=3D=3D12575=3D=3D Command line:
=3D=3D12575=3D=3D ./tvtime
=3D=3D12575=3D=3D Startup, with flags:
=3D=3D12575=3D=3D --suppressions=3D/usr/lib/valgrind/default.supp
=3D=3D12575=3D=3D -v
=3D=3D12575=3D=3D Reading syms from /home/pvz/src/tvtime-0.9.11/src/tvtim=
e
=3D=3D12575=3D=3D Reading syms from /lib/ld-2.3.2.so
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/lib/valgrind/vgskin_addrcheck.so
=3D=3D12575=3D=3D Reading syms from /usr/lib/valgrind/valgrind.so
=3D=3D12575=3D=3D Reading syms from /usr/lib/libSDL-1.2.so.0.0.6
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/lib/libfreetype.so.6.3.4
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/lib/libpng12.so.0.1.2.5
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/X11R6/lib/libSM.so.6.0
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/X11R6/lib/libICE.so.6.3
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/X11R6/lib/libX11.so.6.2
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/X11R6/lib/libXext.so.6.4
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/X11R6/lib/libXtst.so.6.1
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/lib/libxml2.so.2.5.11
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/lib/libz.so.1.1.4
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /lib/libdl-2.3.2.so
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /lib/libm-2.3.2.so
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading syms from /usr/lib/valgrind/libpthread.so
=3D=3D12575=3D=3D Reading syms from /lib/libc-2.3.2.so
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
=3D=3D12575=3D=3D Reading suppressions file: /usr/lib/valgrind/default.su=
pp
=3D=3D12575=3D=3D Estimated CPU clock rate is 1208 MHz
=3D=3D12575=3D=3D REPLACING libc(__errno_location) with libpthread(__errn=
o_location)
=3D=3D12575=3D=3D REPLACING libc(__h_errno_location) with=20
libpthread(__h_errno_location)
=3D=3D12575=3D=3D REPLACING libc(__res_state) with libpthread(__res_state=
)
=3D=3D12575=3D=3D
=3D=3D12575=3D=3D TRANSLATE: 0x405A5FC0 redirected to 0x4056B14E
K=F6r tvtime 0.9.11.
=3D=3D12575=3D=3D Reading syms from /usr/lib/gconv/ISO8859-1.so
=3D=3D12575=3D=3D object doesn't have a symbol table
=3D=3D12575=3D=3D object doesn't have any debug info
rtctimer: Cannot set periodic interval: =C5tkomst nekas
Kunde inte f=E5 en uppl=F6sning p=E5 1024 Hz fr=E5n din RTC-enhet. Ti=
llg=E5ng
till h=F6g uppl=F6sning =E4r n=F6dv=E4ndigt f=F6r mjuk videouppspelni=
ng. K=F6r
tvtime som root, s=E4tt tvtime som SUID-root, eller =E4ndra den maxim=
ala
till=E5tna RTC-uppl=F6sningen f=F6r anv=E4ndarprocesser genom att k=F6=
ra
f=F6ljande kommando som root:
sysctl -w dev.rtc.max-user-freq=3D1024
Se v=E5r hj=E4lpsida: http://tvtime.net/ f=F6r mer information.
L=E4ser inst=E4llningar fr=E5n /usr/local/etc/tvtime/tvtime.xml
L=E4ser inst=E4llningar fr=E5n /home/pvz/.tvtime/tvtime.xml
disInstr: unhandled instruction bytes: 0xF 0xAE 0xF8 0xF
Otill=E5ten instruktion
pvz@tanya:~/src/tvtime-0.9.11/src$
|
|
From: Tom H. <th...@cy...> - 2003-11-18 00:10:42
|
In message <106...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> There's the kernel mechanism for setting up a thread-local storage area,
> using the set_thread_area syscall. The argument to this is a segment
> descriptor, like the one used for set_ldt. This segment descriptor is
> assigned to one of the 3 TLS entries in the GDT. On thread context
> switch, the kernel reassigns the GDT entries to the thread's TLS
> segment. The thread itself assigns that descriptor to one of its
> segment registers, and uses %seg:0 as the pointer to its TLS area.
>
> This is easy for us to implement, since Julian has already done the hard
> work. We can store a per-thread "GDT" containing only these entries as
> part of each Thread structure. In VG_(do_useg)() we just look for the
> GDT (vs LDT) bit in the segment selector and do the appropriate thing.
Indeed, and that's the bit that I have working.
> All this is to support the new TLS extensions to the ABI. These are
> described in detail in http://people.redhat.com/drepper/tls.pdf. I've
> read this once, but I still don't understand the details.
I did look at it a while ago, but I seem to recall finding it
similarly difficult to grasp fully at first reading.
> The essential point is that ELF files can now have a PT_TLS segment
> which is used as a prototype segment for thread-local variables. When a
> new thread is created, it effectively gets a new copy of the contents of
> the PT_TLS segment attached to its own thread area (pointed to via
> %gs). This is does lazily, so only the TLS segments which the thread
> actually uses are copied for it.
There can actually be mutiple TLS segments in the ELF file - there
are typically .tdata and .tbss from what I can see.
In fact only the base executable seems to use direct %gs references. For
example, when xxx is a thread local variables, this code:
xxx++;
is compiled to the following code in the object file:
10: 8d 04 1d 00 00 00 00 lea 0x0(,%ebx,1),%eax
17: e8 fc ff ff ff call 18 <thread_main+0x18>
1c: ff 00 incl (%eax)
but when linked into an executable the linker turns that into:
8048540: 65 a1 00 00 00 00 mov %gs:0x0,%eax
8048546: 81 e8 04 00 00 00 sub $0x4,%eax
804854c: ff 00 incl (%eax)
in a shared object the linker leaves it more or less alone, other
than applying relocations:
8c4: 8d 04 1d 2c 00 00 00 lea 0x2c(,%ebx,1),%eax
8cb: e8 f8 fe ff ff call 7c8 <_init+0x88>
8d0: ff 00 incl (%eax)
The function being called is ___tls_get_addr and the lea is setting
up some sort of index into the TLS segment.
> This means that there's cooperation between the dynamic linker and
> libpthread. Since we control the one but not the other, we need to make
> our libpthread compatible with the dynamic linker's TLS implementation.
> The ABI documents some of this, but unfortunately it only documents the
> compiler interface to this goo, but not the internal interfaces between
> libpthread and the ld.so. The easy part of this is making sure that new
> threads get their own new TLS areas (which the glibc libpthread does by
> passing CLONE_SETTLS to clone(), which is the equivalent of doing
> set_thread_area() in the new thread). Trickier is getting the details
> of all the other structures right. And since they're internal to glibc,
> there's no certainty they won't change from release to release...
Even the cloning is hard because although we have the pointer to
the thread area for the original thread we have no idea how big
that area is because ld.so seems to set it up with a size of -1 so
the area is effectively unlimited.
In fact I believe the address passed to the kernel as the thread
area pointer is a pointer to the thread descriptor structure, with
the TLS data for the main executable just below it so that negative
offsets from %gs will find it. Other TLS data is found from the
thread descriptor somehow by the __tls_get_addr function.
Trying to emulate the whole thing would be horrible, but given
the incestuous links between ld.so, libc and libpthread it's hard
to see how else it can be done. It would also be a maintenance
nightmare of course, as you say.
> BTW, this is completely independent of NPTL. The TLS stuff is an
> extension to the ABI which is also supported by the pre-NPTL threads
> library (though I'm not sure how they make do without the
> set_thread_area syscall).
I don't think they do make do without it, which is why valgrind
falls over if you try and load any program or library with a TLS
section in the ELF file. Setting LD_ASSUME_KERNEL causes ld.so to
use a glibc built without using TLS segments.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 22:15:38
|
On Mon, 17 Nov 2003, Per von Zweigbergk wrote: > When running tvtime under Valgrind, I get an error message about > OVERLAPPING EXE SEGMENTS (full error message text below.) The same error > message occurs with --skin=memcheck. > > OVERLAPPING EXE SEGMENTS > new: start 0x10000000, size 4096 > old: start 0x10000000, size 131072 The problem is that your program is mapping two executable segments to the same address. Valgrind's handling of text segment loading is fairly simplistic, and falls over if anything tricky like this happens; we haven't bothered being more clever because in practice tricky cases happen extremely rarely. AFAIK this is the first time anyone has reported the problem. 0x10000000 is a pretty strange address for normal Linux boxes, I assume your program is deliberately mapping things there, eg. with MAP_FIXED? dlopen() doesn't tend to put segments at that address. Maybe the segments are executable but not actually text? Maybe your program does some JIT compiling? It would help if you could explain exactly why your program is mapping two segments to the same address, and whether the segments contain code, and any other relevant info. Thanks. N |
|
From: Per v. Z.
|
I'm trying to debug a program called tvtime, to find what I suspect to=20
be a hard-to-find heap corruption bug. (The bug "disappears" if i add a=20
call to puts). After searching around a bit for some suitable programs=20
to debug these kinds of problems, i found Valgrind.
I have never used a tool like this before. I initially tried to run=20
electric-fence, but it used so much memory that it ran out of memory on=20
my computer. Hearing that the addrcheck skin to valgrind is a=20
light-weight checker light enough to run an entire KDE session under=20
made it seem to be exactly what I wanted. I'm running valgrind, as=20
packaged with Debian/unstable (valgrind-20031012).
When running tvtime under Valgrind, I get an error message about=20
OVERLAPPING EXE SEGMENTS (full error message text below.) The same error=20
message occurs with --skin=3Dmemcheck.
I have read the FAQ on the web page, and not found any problem similar=20
to this. I also ran a Google search for "OVERLAPPING EXE SEGMENTS" which=20
turned up exactly 0 refults.
How should I proceed?
pvz@tanya:~/src/tvtime-0.9.11/src$ valgrind -v --skin=3Daddrcheck ./tvtim=
e
=3D=3D8726=3D=3D Addrcheck, a fine-grained address checker for x86-linux.
=3D=3D8726=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
=3D=3D8726=3D=3D Using valgrind-20031012, a program supervision framework=
for=20
x86-linux.
=3D=3D8726=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
=3D=3D8726=3D=3D Command line:
=3D=3D8726=3D=3D ./tvtime
=3D=3D8726=3D=3D Startup, with flags:
=3D=3D8726=3D=3D --suppressions=3D/usr/lib/valgrind/default.supp
=3D=3D8726=3D=3D -v
=3D=3D8726=3D=3D Reading syms from /home/pvz/src/tvtime-0.9.11/src/tvtime
=3D=3D8726=3D=3D Reading syms from /lib/ld-2.3.2.so
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/lib/valgrind/vgskin_addrcheck.so
=3D=3D8726=3D=3D Reading syms from /usr/lib/valgrind/valgrind.so
=3D=3D8726=3D=3D Reading syms from /usr/lib/libSDL-1.2.so.0.0.6
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/lib/libfreetype.so.6.3.4
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/lib/libpng12.so.0.1.2.5
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/X11R6/lib/libSM.so.6.0
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/X11R6/lib/libICE.so.6.3
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/X11R6/lib/libX11.so.6.2
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/X11R6/lib/libXext.so.6.4
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/X11R6/lib/libXtst.so.6.1
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/lib/libxml2.so.2.5.11
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/lib/libz.so.1.1.4
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /lib/libdl-2.3.2.so
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /lib/libm-2.3.2.so
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading syms from /usr/lib/valgrind/libpthread.so
=3D=3D8726=3D=3D Reading syms from /lib/libc-2.3.2.so
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
=3D=3D8726=3D=3D Reading suppressions file: /usr/lib/valgrind/default.sup=
p
=3D=3D8726=3D=3D Estimated CPU clock rate is 1203 MHz
=3D=3D8726=3D=3D REPLACING libc(__errno_location) with libpthread(__errno=
_location)
=3D=3D8726=3D=3D REPLACING libc(__h_errno_location) with=20
libpthread(__h_errno_location)
=3D=3D8726=3D=3D REPLACING libc(__res_state) with libpthread(__res_state)
=3D=3D8726=3D=3D
=3D=3D8726=3D=3D TRANSLATE: 0x405A5FC0 redirected to 0x4056B14E
K=F6r tvtime 0.9.11.
=3D=3D8726=3D=3D Reading syms from /usr/lib/gconv/ISO8859-1.so
=3D=3D8726=3D=3D object doesn't have a symbol table
=3D=3D8726=3D=3D object doesn't have any debug info
rtctimer: Cannot set periodic interval: =C5tkomst nekas
Kunde inte f=E5 en uppl=F6sning p=E5 1024 Hz fr=E5n din RTC-enhet. Ti=
llg=E5ng
till h=F6g uppl=F6sning =E4r n=F6dv=E4ndigt f=F6r mjuk videouppspelni=
ng. K=F6r
tvtime som root, s=E4tt tvtime som SUID-root, eller =E4ndra den maxim=
ala
till=E5tna RTC-uppl=F6sningen f=F6r anv=E4ndarprocesser genom att k=F6=
ra
f=F6ljande kommando som root:
sysctl -w dev.rtc.max-user-freq=3D1024
Se v=E5r hj=E4lpsida: http://tvtime.net/ f=F6r mer information.
L=E4ser inst=E4llningar fr=E5n /usr/local/etc/tvtime/tvtime.xml
L=E4ser inst=E4llningar fr=E5n /home/pvz/.tvtime/tvtime.xml
OVERLAPPING EXE SEGMENTS
new: start 0x10000000, size 4096
old: start 0x10000000, size 131072
valgrind: vg_memory.c:94 (add_exe_segment_to_list): Assertion `!=20
overlap' failed.
sched status:
Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0=
x0
=3D=3D8726=3D=3D at 0x4066482D: mmap (in /lib/libc-2.3.2.so)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: js...@ac...
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
pvz@tanya:~/src/tvtime-0.9.11/src$
|
|
From: Jesse Y. <yu...@ii...> - 2003-11-17 20:06:42
|
Hello,
I'm using latest CVS from the KDE repository and I've been running into
the following errors. I believe this happened after an update to glibc. It
was a minor update in that I turned on NPTL support but was more or less
already running 2.3.2. Could this be what's causing the following errors?
GLIBC 2.3.2 ...
Hope it's nothing too big :-/
-Jesse
-----------------------------------
vg_scheduler.c: In function `release_one_thread_waiting_on_mutex':
vg_scheduler.c:1986: error: union has no member named `__m_owner'
vg_scheduler.c:1991: error: union has no member named `__m_count'
vg_scheduler.c:1992: error: union has no member named `__m_owner'
vg_scheduler.c:1998: error: union has no member named `__m_owner'
vg_scheduler.c:1998: error: `_pthread_descr' undeclared (first use in this
function)
vg_scheduler.c:1998: error: (Each undeclared identifier is reported only once
vg_scheduler.c:1998: error: for each function it appears in.)
vg_scheduler.c:1998: error: syntax error before "i"
vg_scheduler.c: In function `do_pthread_mutex_lock':
vg_scheduler.c:2042: error: union has no member named `__m_kind'
vg_scheduler.c:2052: error: union has no member named `__m_count'
vg_scheduler.c:2061: error: union has no member named `__m_count'
vg_scheduler.c:2063: error: union has no member named `__m_owner'
vg_scheduler.c:2066: error: union has no member named `__m_owner'
vg_scheduler.c:2068: error: union has no member named `__m_kind'
vg_scheduler.c:2070: error: union has no member named `__m_count'
vg_scheduler.c:2074: error: union has no member named `__m_count'
vg_scheduler.c:2107: error: union has no member named `__m_owner'
vg_scheduler.c:2112: error: union has no member named `__m_count'
vg_scheduler.c:2113: error: union has no member named `__m_owner'
vg_scheduler.c:2113: error: `_pthread_descr' undeclared (first use in this
function)
[snip...]
|
|
From: Jim M. <ji...@me...> - 2003-11-17 19:08:56
|
Nicholas Nethercote <nj...@ca...> wrote:
...
> @@ -1102,7 +1102,7 @@ static void process_cmd_line_options ( v
> /* So far we should be still attached to stderr, so we can show on
> the terminal any problems to do with processing command line
> opts. */
> - vg_assert(VG_(clo_logfile_fd) == 2 /* stderr */);
> + vg_assert(VG_(clo_logfile_fd) == 1 /* stderr */);
> vg_assert(VG_(logging_to_filedes) == True);
>
> switch (VG_(clo_log_to)) {
You probably already know, and simply prefer to use the hard-coded
literal file numbers, but just in case, ...
it'd make the code a tiny bit more readable to use
STDOUT_FILENO and STDERR_FILENO in place of 1 and 2 respectively.
Then you could get rid of the `/* stderr */' comment that should
(with the above change) read `/* stdout */'.
|
|
From: <ar...@de...> - 2003-11-17 18:37:51
|
Worked fine. Thanks :)
Nicholas Nethercote <nj...@ca...> writes:
> On Mon, 17 Nov 2003, Andrés Roldán wrote:
>
>> > valgrind --help 2>&1 | more
>>
>> I know. I'm maintaining valgrind for Debian and there is a rule on
>> Debian that says that every large --help message should be on STDOUT
>> instead of STDERR.
>
> Oh, right, sorry.
>
> Try the patch below; I've tested it minimally.
>
> N
>
>
>
> RCS file: /home/kde/valgrind/coregrind/vg_main.c,v
> retrieving revision 1.115
> diff -u -3 -p -r1.115 vg_main.c
> --- coregrind/vg_main.c 29 Sep 2003 10:56:24 -0000 1.115
> +++ coregrind/vg_main.c 17 Nov 2003 17:44:48 -0000
> @@ -527,7 +527,7 @@ Bool VG_(clo_trace_children) = False;
>
> /* See big comment in vg_include.h for meaning of these three. */
> VgLogTo VG_(clo_log_to) = VgLogTo_Fd;
> -Int VG_(clo_logfile_fd) = 2;
> +Int VG_(clo_logfile_fd) = 1;
> Char* VG_(clo_logfile_name) = NULL;
>
> Int VG_(clo_input_fd) = 0; /* stdin */
> @@ -725,7 +725,7 @@ static void process_cmd_line_options ( v
>
> # define ISSPACE(cc) ((cc) == ' ' || (cc) == '\t' || (cc) == '\n')
>
> - eventually_logfile_fd = VG_(clo_logfile_fd);
> + eventually_logfile_fd = 2;
>
> /* Once logging is started, we can safely send messages pertaining
> to failures in initialisation. */
> @@ -1102,7 +1102,7 @@ static void process_cmd_line_options ( v
> /* So far we should be still attached to stderr, so we can show on
> the terminal any problems to do with processing command line
> opts. */
> - vg_assert(VG_(clo_logfile_fd) == 2 /* stderr */);
> + vg_assert(VG_(clo_logfile_fd) == 1 /* stderr */);
> vg_assert(VG_(logging_to_filedes) == True);
>
> switch (VG_(clo_log_to)) {
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
--
Andres Roldan
Fluidsignal Group <ar...@fl...>
The Debian Project <ar...@de...>
GIGAX <ar...@gi...>
GPG Key-ID 0xB29396EB
Home Page http://people.fluidsignal.com/~aroldan
|
|
From: Olly B. <ol...@su...> - 2003-11-17 17:57:20
|
On Mon, Nov 17, 2003 at 12:41:25PM -0500, Andr?s Rold?n wrote:
> I'm maintaining valgrind for Debian and there is a rule on
> Debian that says that every large --help message should be on STDOUT
> instead of STDERR.
It's a sensible rule, and most Linux programs do send help output to
stdout rather than stderr so valgrind is out of line with convention
here. Perhaps valgrind should by change to use stdout?
Cheers,
Olly
|
|
From: Avery P. <ape...@ni...> - 2003-11-17 17:56:01
|
On Mon, Nov 17, 2003 at 10:37:43AM +0000, Nicholas Nethercote wrote: > Warning: ignored attempt to set SIGKILL handler in sigaction(); > the SIGKILL signal is uncatchable > > > Also, for programs that set the sighandler in a loop - apparently > > include ls on some systems - I bet they're usually *disabling* a special > > handler, ie. 'sa' is NULL in the code fragment below. It would probably > > give fewer spurious warnings if we just didn't print a warning when > > sa==NULL. > > No. Valgrind doesn't print the warning when sa==NULL. In that case, I think the warning is valid, and there's no question about removing it - people should really only set signal handlers on signals they understand, not try to foolishly catch every single one as if they knew what to do when they got them. Have fun, Avery |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 17:46:19
|
On Mon, 17 Nov 2003, Andr=E9s Rold=E1n wrote:
> > valgrind --help 2>&1 | more
>
> I know. I'm maintaining valgrind for Debian and there is a rule on
> Debian that says that every large --help message should be on STDOUT
> instead of STDERR.
Oh, right, sorry.
Try the patch below; I've tested it minimally.
N
RCS file: /home/kde/valgrind/coregrind/vg_main.c,v
retrieving revision 1.115
diff -u -3 -p -r1.115 vg_main.c
--- coregrind/vg_main.c 29 Sep 2003 10:56:24 -0000 1.115
+++ coregrind/vg_main.c 17 Nov 2003 17:44:48 -0000
@@ -527,7 +527,7 @@ Bool VG_(clo_trace_children) =3D False;
/* See big comment in vg_include.h for meaning of these three. */
VgLogTo VG_(clo_log_to) =3D VgLogTo_Fd;
-Int VG_(clo_logfile_fd) =3D 2;
+Int VG_(clo_logfile_fd) =3D 1;
Char* VG_(clo_logfile_name) =3D NULL;
Int VG_(clo_input_fd) =3D 0; /* stdin */
@@ -725,7 +725,7 @@ static void process_cmd_line_options ( v
# define ISSPACE(cc) ((cc) =3D=3D ' ' || (cc) =3D=3D '\t' || (cc) =
=3D=3D '\n')
- eventually_logfile_fd =3D VG_(clo_logfile_fd);
+ eventually_logfile_fd =3D 2;
/* Once logging is started, we can safely send messages pertaining
to failures in initialisation. */
@@ -1102,7 +1102,7 @@ static void process_cmd_line_options ( v
/* So far we should be still attached to stderr, so we can show on
the terminal any problems to do with processing command line
opts. */
- vg_assert(VG_(clo_logfile_fd) =3D=3D 2 /* stderr */);
+ vg_assert(VG_(clo_logfile_fd) =3D=3D 1 /* stderr */);
vg_assert(VG_(logging_to_filedes) =3D=3D True);
switch (VG_(clo_log_to)) {
|
|
From: <ar...@de...> - 2003-11-17 17:27:45
|
Nicholas Nethercote <nj...@ca...> writes: > On Mon, 17 Nov 2003, Andrés Roldán wrote: > >> I'm interested in showing the valgrind --help output to STDOUT >> instead of STDERR to pipe it to a pager or something. Can anybody >> tell me what do I need to change? >> >> I used to use an ugly hack of dup2() calls but I think there is >> a better (and prettier) way to do that. > > valgrind --help 2>&1 | more I know. I'm maintaining valgrind for Debian and there is a rule on Debian that says that every large --help message should be on STDOUT instead of STDERR. I'm not asking to include this feature to the main valgring source :) Thanks. > > N -- Andres Roldan Fluidsignal Group <ar...@fl...> The Debian Project <ar...@de...> GIGAX <ar...@gi...> GPG Key-ID 0xB29396EB Home Page http://people.fluidsignal.com/~aroldan |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 17:24:54
|
On Mon, 17 Nov 2003, Andr=E9s Rold=E1n wrote: > I'm interested in showing the valgrind --help output to STDOUT > instead of STDERR to pipe it to a pager or something. Can anybody > tell me what do I need to change? > > I used to use an ugly hack of dup2() calls but I think there is > a better (and prettier) way to do that. valgrind --help 2>&1 | more N |
|
From: <ar...@de...> - 2003-11-17 17:00:14
|
Hi all. I'm interested in showing the valgrind --help output to STDOUT instead of STDERR to pipe it to a pager or something. Can anybody tell me what do I need to change? I used to use an ugly hack of dup2() calls but I think there is a better (and prettier) way to do that. Thanks in advance. -- Andres Roldan Fluidsignal Group <ar...@fl...> The Debian Project <ar...@de...> GIGAX <ar...@gi...> GPG Key-ID 0xB29396EB Home Page http://people.fluidsignal.com/~aroldan |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 14:39:53
|
On Mon, 17 Nov 2003, Massimo Narizzano wrote: > I have runned valgrind on my code and I have obtained a couple of > error before a segmentation fault. > Everything works fine except the fact that valgrind shows me > that there are some errors in my code but not which line they are. > It may be the case that the error line is too long and it is not > shown entirely. > Does exist an option that say how to increment the lenght of the error > lines? No option, but you can change the value of M_VG_ERRTXT (in coregrind/vg_include.h) and recompile. We should handle that better. > You can also find in attach an example of how the lines are cutted. > __________________________________________________ > =6336== Conditional jump or move depends on uninitialised value(s) > ==6336== at 0x805616B: > ConstraintPropagation<ComposeData<Typelist<AtomsData, > Typelist<ConstraintsData<WatchThreeLiteralsSupport>, > Typelist<LookAheadData, Typelist<AssignmentsData, > Typelist<ConflictsData, Typelist<SolutionsData, > Typelist<ConstraintsToBeLearnedData, > Typelist<ComposeData<Typelist<BacktrackingStatisticsData, > Typelist<LearningStatisticsData, NullType> > >, > Typelist<ElementsData<StdAllocator>, NullType> > > > > > > > > >, > QbfSolver::Dispatcher_, > WatchThreeLiteralsSupport>::outOfLevelExistSimplificatio Wow, you really like templates, huh? :) N |
|
From: Massimo N. <mo...@di...> - 2003-11-17 14:23:41
|
Dear all, I have runned valgrind on my code and I have obtained a couple of error before a segmentation fault. Everything works fine except the fact that valgrind shows me that there are some errors in my code but not which line they are. It may be the case that the error line is too long and it is not shown entirely. Does exist an option that say how to increment the lenght of the error lines? You can also find in attach an example of how the lines are cutted. Thank you in advance Massimo __________________________________________________ =6336== Conditional jump or move depends on uninitialised value(s) ==6336== at 0x805616B: ConstraintPropagation<ComposeData<Typelist<AtomsData, Typelist<ConstraintsData<WatchThreeLiteralsSupport>, Typelist<LookAheadData, Typelist<AssignmentsData, Typelist<ConflictsData, Typelist<SolutionsData, Typelist<ConstraintsToBeLearnedData, Typelist<ComposeData<Typelist<BacktrackingStatisticsData, Typelist<LearningStatisticsData, NullType> > >, Typelist<ElementsData<StdAllocator>, NullType> > > > > > > > > >, QbfSolver::Dispatcher_, WatchThreeLiteralsSupport>::outOfLevelExistSimplificatio (the line is cutted as shown) |
|
From: Jim M. <ji...@me...> - 2003-11-17 13:58:31
|
I had to make some changes to valgrind so that it could be used to
run the `make check' tests in the GNU coreutils package.
Note that to get the test scripts to run the tools via valgrind,
I tweak every Makefile.am under the coreutils/tests/ hierarchy in
order to run each program via its own wrapper script.
Minimal instructions are in coreutils' README-valgrind in CVS.
ChangeLog entries and diffs are below.
Obviously, only the changes to vg_syscalls.c are intended to be
directly useful to you. The others are mainly for your reference.
Is there some other way to suppress the
"discard syms in %s due to munmap()" warnings?
I confess that I may not have read the documentation carefully enough.
BTW, valgrind detected a free-mem-read bug in csplit. Thanks!
Jim
P.S., I did register with KDE bugzilla and then tried to report
via that, but when I hit the `commit' button, it failed. Sigh.
I reported _that_ to the indicated address.
I'm using Debian unstable, linux-2.4.22, libc-2.3.2,
and valgrind-2.0.0 compiled from sources.
FYI, when running the test suite, each of the 90 programs in the
coreutils is invoked through its own wrapper script that exec's valgrind.
Here's the wrapper for `cat' as an example:
$ cat src/vg/cat
#!/bin/sh
export PATH=/work/fetish/cu/src:...
exec /p/bin/valgrind --suppressions=/tmp/cu-vg --gen-suppressions=yes --quiet --num-callers=9 cat "$@"
=========================================================
2003-11-17 Jim Meyering <ji...@me...>
* coregrind/vg_syscalls.c (perform_assumed_nonblocking_syscall)
[case __NR_clock_gettime]: Check for `res == 0', not `res > 0'.
[case __NR_statfs64] (syscall 268): Handle new syscall.
[case __NR_utimes] (syscall 271): Likewise.
* coregrind/vg_main.c (process_cmd_line_options): Raise the upper
bound on the number of command line arguments to 1500.
Coreutils runs a test case that uses over 1300. This might
deserve an option.
* coregrind/vg_symtab2.c: #if-0'out the code that produces
diagnostics like these. Using --quiet doesn't suppress them, and the
extra output (albeit on stderr) induces many unwarranted failures
in the coreutils test suite.
==10629== discard syms in /lib/libnss_compat-2.3.2.so due to munmap()
==10629== discard syms in /lib/libnss_nis-2.3.2.so due to munmap()
==10629== discard syms in /lib/libnsl-2.3.2.so due to munmap()
==10629== discard syms in /lib/libnss_files-2.3.2.so due to munmap()
[case __NR_utimes] (syscall 271): Likewise.
* coregrind/vg_unsafe.h: Include kernel definition of
`struct list_head', to avoid this sort of compile error:
In file included from /usr/include/linux/timer.h:5,
from /usr/include/linux/isdn/fsm.h:15,
from /usr/include/linux/isdn.h:17,
from vg_unsafe.h:53,
from vg_signals.c:34:
/usr/include/linux/list.h:576:2: warning: #warning "don't include kernel headers in userspace"
In file included from /usr/include/linux/isdn/fsm.h:15,
from /usr/include/linux/isdn.h:17,
from vg_unsafe.h:53,
from vg_signals.c:34:
/usr/include/linux/timer.h:11: error: field `entry' has incomplete type
make[3]: *** [vg_signals.o] Error 1
diff -F '^[_a-zA-Z$]' -ur -x config.status -x config.log -x configure -x Makefile -x '*.Po' valgrind-2.0.0/coregrind/vg_syscalls.c valgrind-2.0.0-my/coregrind/vg_syscalls.c
--- valgrind-2.0.0/coregrind/vg_syscalls.c 2003-11-03 20:15:04.000000000 +0100
+++ valgrind-2.0.0-my/coregrind/vg_syscalls.c 2003-11-17 13:52:56.000000000 +0100
@@ -492,7 +492,7 @@ void VG_(perform_assumed_nonblocking_sys
SYSCALL_TRACK( pre_mem_write, tid, "clock_gettime(tp)",
arg2, sizeof(struct timespec) );
KERNEL_DO_SYSCALL(tid,res);
- if (!VG_(is_kerror)(res) && res > 0)
+ if (!VG_(is_kerror)(res) && res == 0)
VG_TRACK( post_mem_write, arg2, sizeof(struct timespec) );
break;
# endif
@@ -2961,6 +2961,29 @@ void VG_(perform_assumed_nonblocking_sys
KERNEL_DO_SYSCALL(tid,res);
break;
+# if defined(__NR_statfs64)
+ case __NR_statfs64: /* syscall 268 */
+ /* int statfs64(const char *path, struct statfs64 *buf); */
+ MAYBE_PRINTF("statfs64 ( %s, %p )\n", arg1,arg2);
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, "statfs64(path)", arg1 );
+ KERNEL_DO_SYSCALL(tid,res);
+ if (!VG_(is_kerror)(res) && res == 0)
+ VG_TRACK( post_mem_write,arg2, sizeof(struct statfs) );
+ break;
+# endif
+
+# if defined(__NR_utimes)
+ case __NR_utimes: /* syscall 271 */
+ /* int utimes(const char *filename, struct timeval *tvp); */
+ MAYBE_PRINTF("utimes ( %p, %p )\n", arg1,arg2);
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, "utimes(filename)", arg1 );
+ if (arg2 != (UInt)NULL)
+ SYSCALL_TRACK( pre_mem_read, tid, "utimes(tvp)", arg2,
+ sizeof(struct timeval) );
+ KERNEL_DO_SYSCALL(tid,res);
+ break;
+# endif
+
# if defined(__NR_setuid32)
case __NR_setuid32: /* syscall 213 */
# endif
diff -F '^[_a-zA-Z$]' -ur -x config.status -x config.log -x configure -x Makefile -x '*.Po' valgrind-2.0.0/coregrind/vg_main.c valgrind-2.0.0-my/coregrind/vg_main.c
--- valgrind-2.0.0/coregrind/vg_main.c 2003-10-05 02:02:43.000000000 +0200
+++ valgrind-2.0.0-my/coregrind/vg_main.c 2003-11-17 13:44:05.000000000 +0100
@@ -874,7 +874,7 @@ static void process_cmd_line_options ( v
if (*sp == VG_(client_argc))
break;
VG_(client_argc)++;
- if (++ctr >= 1000)
+ if (++ctr >= 1500)
args_grok_error(
"suspiciously many (1000) argv[] entries; giving up");
}
diff -F '^[_a-zA-Z$]' -ur -x config.status -x config.log -x configure -x Makefile -x '*.Po' valgrind-2.0.0/coregrind/vg_symtab2.c valgrind-2.0.0-my/coregrind/vg_symtab2.c
--- valgrind-2.0.0/coregrind/vg_symtab2.c 2003-10-29 23:52:46.000000000 +0100
+++ valgrind-2.0.0-my/coregrind/vg_symtab2.c 2003-11-17 13:44:07.000000000 +0100
@@ -2299,9 +2299,11 @@ void VG_(unload_symbols) ( Addr start, U
if (curr == NULL)
return;
+#if 0
VG_(message)(Vg_UserMsg,
"discard syms in %s due to munmap()",
curr->filename ? curr->filename : (UChar*)"???");
+#endif
vg_assert(prev == NULL || prev->next == curr);
diff -F '^[_a-zA-Z$]' -ur -x config.status -x config.log -x configure -x Makefile -x '*.Po' valgrind-2.0.0/coregrind/vg_unsafe.h valgrind-2.0.0-my/coregrind/vg_unsafe.h
--- valgrind-2.0.0/coregrind/vg_unsafe.h 2003-11-05 00:18:40.000000000 +0100
+++ valgrind-2.0.0-my/coregrind/vg_unsafe.h 2003-11-17 13:44:12.000000000 +0100
@@ -50,6 +50,9 @@
#include <linux/msg.h> /* for struct msgbuf */
#include <linux/sem.h> /* for struct sembuf */
+struct list_head {
+ struct list_head *next, *prev;
+};
#include <linux/isdn.h> /* for ISDN ioctls */
#include <scsi/sg.h> /* for the SG_* ioctls */
#include <sched.h> /* for struct sched_param */
|