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
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 20:11:02
|
On Wed, 16 Apr 2003, Philippe Elie wrote: > > This works, but it would be better if the GDB variable was put into a .h > > file, so it's available everywhere -- that's better than having to feed it > > in to every file that needs it with -D. This could be done by introducing > > eg. vg_skin.h.in, but that would be a pain, especially just for one > > variable. > > Yes, it's a better way but the trivial: [snip] > Not very elegant but the only way I found Hmm, pretty ugly... if that's the only way to do it, I can live with passing in the option using -D :) Thanks very much. N |
|
From: Philippe E. <ph...@wa...> - 2003-04-16 16:55:26
|
Nicholas Nethercote wrote: > On Thu, 20 Mar 2003, Ruben Garcia wrote: > > >>In valgrind 1.0.4 (dont know if this is fixed in development) >>the location of gdb is hardcoded in vg_main.c as /usr/bin/gdb. >> >>Gdb sources, on the other hand, install by default in /usr/local/bin/gdb. >>Surely a patch to the ./configure to check where gdb is installed cannot >>be difficult. > > > I have this working, but I'm not certain if I've done it the best way. > > Here's what I did: > > - added this to configure.in: > > AC_PATH_PROG(GDB, gdb) > > - added this to coregrind/Makefile.am: > > vg_main.o: CFLAGS += -DWHERE_IS_GDB=@GDB@ > > - changed coregrind/vg_main.c to use WHERE_IS_GDB for the path. > > This works, but it would be better if the GDB variable was put into a .h > file, so it's available everywhere -- that's better than having to feed it > in to every file that needs it with -D. This could be done by introducing > eg. vg_skin.h.in, but that would be a pain, especially just for one > variable. > > I tried various ways to get the WHERE_IS_GDB variable put into config.h, > but didn't manage... this would be a better solution. Does anyone know > how to do this? Yes, it's a better way but the trivial: AC_PATH_PROG(GDB, gdb) AC_DEFINE(GDB_PATH, @GDB@, "gdb path") AC_SUBST(GDB) doesn't work cause configure don't do subsititution in config.h.in when creating config.h, I don't think there is any way to put it in config.h.in. I work around by doing: ** configure.in: AC_PATH(GDB_PATH, gdb) AC_SUBST(GDB_PATH) AC_OUTPUT( .... \ path-1.h) AX_COPY_IF_CHANGE(path-1.h, path.h) $ cat path-1.h.in #define GDB_PATH @GDB_PATH@ $ cat copyifchange.m4 dnl AX_COPY_IF_CHANGE(source, dest) dnl copy source to dest if they don't compare equally or if dest doesn't exist AC_DEFUN(AX_COPY_IF_CHANGE, [ if test -r $2; then if cmp $1 $2 > /dev/null; then echo $2 is unchanged else cp -f $1 $2 fi else cp -f $1 $2 fi ]) I use path-1.h and copyifchange to avoid spurious recompilation when you configure and nothing change in path-1.h. (configure take care to not change time stamp of config.h if unnecessary but doesn't do the same thing for other .in translation) Not very elegant but the only way I found The only required file in cvs/tarball is path-1.h.in regards, Phil |
|
From: Sebastian <sc...@nb...> - 2003-04-16 14:45:27
|
Hi, On Tue, Apr 15, 2003 at 03:04:20PM -0400, Maarten Ballintijn wrote: > It might be stating the obvious ... but it is always a GoodIdea(tm) to > check the return values of system calls. Args, yes, that was it. Thanks ! (I introduced the bug in two steps: First I thought read() will never fail on reading data from /dev/urandom. But then, to reproduce bug cases more exactly, I added an option to override using /dev/urandom but a fixed random data file instead. Guess what, there was more random data required than those file could provide and read() bumped against its file end). A good reason to think twice about "simply modding" existing features. Thanks to the other poster, too. > Cheers, > Maarten. ciao, Sebastian -- -. sc...@nb... -. + http://segfault.net/~scut/ `--------------------. -' segfault.net/~scut/pgp `' 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07 `- 4 BLU-82/MOAB articles offered, payment due. hi echelon! -----------------' |
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 09:59:01
|
On Thu, 20 Mar 2003, Ruben Garcia wrote:
> In valgrind 1.0.4 (dont know if this is fixed in development)
> the location of gdb is hardcoded in vg_main.c as /usr/bin/gdb.
>
> Gdb sources, on the other hand, install by default in /usr/local/bin/gdb.
> Surely a patch to the ./configure to check where gdb is installed cannot
> be difficult.
I have this working, but I'm not certain if I've done it the best way.
Here's what I did:
- added this to configure.in:
AC_PATH_PROG(GDB, gdb)
- added this to coregrind/Makefile.am:
vg_main.o: CFLAGS += -DWHERE_IS_GDB=@GDB@
- changed coregrind/vg_main.c to use WHERE_IS_GDB for the path.
This works, but it would be better if the GDB variable was put into a .h
file, so it's available everywhere -- that's better than having to feed it
in to every file that needs it with -D. This could be done by introducing
eg. vg_skin.h.in, but that would be a pain, especially just for one
variable.
I tried various ways to get the WHERE_IS_GDB variable put into config.h,
but didn't manage... this would be a better solution. Does anyone know
how to do this?
Thanks very much.
N
|
|
From: Josef W. <Jos...@gm...> - 2003-04-16 08:58:01
|
On Wednesday 16 April 2003 08:21, Biswapesh Chattopadhyay wrote: > Hi > > Is there any reason why the calltree skin > (http://kcachegrind.sourceforge.net/) is not included by default with > valgrind ? Seems darn useful to me :-) There are various reasons for external skins: * No synchronized release cycle necessary. The skin interface version is independent from Valgrind version. Thus, my current calltree skin should work even with V 3.0 if there's no major change in the skin interface. * Check if all requirements for external skins are met with a Valgrind release. If there's no external skin, we can't find problems. * Any addition to V core maps directly to more maintance work for core developers. I'm quite happy with the current situation. Regarding the second item, I still have some issues: * V should install vg_skin.h (and all its dependents) together with valgrind.h. This at least would make it possible to adjust compilation of an external skin to various V skin interface versions. At the moment, I ship my own vg_skin.h (a copy). Thus I have to ship 2 packages, one for interface 1.2 (used till Valgrind 1.9.5) and one for interface 2.0 (current CVS), if I want to support both. * How to integrate external skin documentation into V documentation? Has anyone an idea for this? Perhaps an index update script to be run at skin installation? We could use the valgrind script itself for this: "valgrind --update-docindex". This should search for all <prefix>/share/doc/valgrind/*_main.html and generate a start page. Josef > > Thanks in advance, and regards, |
|
From: Josef W. <Jos...@gm...> - 2003-04-16 08:35:49
|
On Wednesday 16 April 2003 08:31, Biswapesh Chattopadhyay wrote: > Hi > > I'm getting the following error with CVS valgrind + cachegrind skin ( > alias cachegrind='valgrind --skin=cachegrind --num-callers=25 > --logfile-fd=6' > /opt/gnome2.2/bin/valgrind > > ------------------------------------ > ==6863== error: can't open cache simulation output file > `cachegrind.out.6863' > ==6863== ... so simulation results will be missing. > ------------------------------------ > > A 0 byte file cachegrind.out.6863 is created. There is sufficient space > in the harddisk : > > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda2 37334192 15213876 20223844 43% / > > Can someone give me a clue ? Does your program change its cwd (current working directory) while running? I thought that on dump time, cachegrind will check for existence of an empty cachegrind.out it generates at startup. If it doesn't find it because of a change of the cwd, you will see the error, as the dump is always created in the cwd. To work around this, I made the "--base=" option to specify a prefix for dump files. Use an absolute path in the prefix. Nick, we should add a implementation of getcwd() to V, and use absolute file paths. But this still doesn't work with chroot() programs :-( Another option: --dumpfile-fd=... Josef > > Thanks in adavnce. |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 08:23:03
|
I just did: calltree ./SciTE ~/GNOME2.2/src/anjuta/src/aneditor.cxx It just creates some 0 byte cachegrind.out.* files :-( No warnings about unable to write this time though. Any clues ? On Wed, 2003-04-16 at 13:38, Nicholas Nethercote wrote: > On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > > > I'm getting the following error with CVS valgrind + cachegrind skin ( > > alias cachegrind='valgrind --skin=cachegrind --num-callers=25 > > --logfile-fd=6' > > /opt/gnome2.2/bin/valgrind > > > > ------------------------------------ > > ==6863== error: can't open cache simulation output file > > `cachegrind.out.6863' > > ==6863== ... so simulation results will be missing. > > ------------------------------------ > > > > A 0 byte file cachegrind.out.6863 is created. There is sufficient space > > in the harddisk : > > > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/hda2 37334192 15213876 20223844 43% / > > Is file descriptor 6 legitimate? Does it work if you let Valgrind's > output go to stderr as usual? > > N -- Biswa. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:23:01
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > The thing is that I compiled valgrind CVS HEAD from source and then I > compiled the latest version of calltree from source, so I'm a mystified > as to why it did not catch this at compile time. Because the latest version of calltree is not quite up-to-date. > The error goes away if I specify the 1_9_5 branch of valgrind during > checkout and then recompile both in that order. Good. N |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 08:19:03
|
The thing is that I compiled valgrind CVS HEAD from source and then I compiled the latest version of calltree from source, so I'm a mystified as to why it did not catch this at compile time. The error goes away if I specify the 1_9_5 branch of valgrind during checkout and then recompile both in that order. On Wed, 2003-04-16 at 13:43, Nicholas Nethercote wrote: > On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > > > ------------------------------------ > > Error: > > Skin and core interface versions do not match. > > Interface version used by core is: 2.0 > > Interface version used by skin is: 1.2 > > The major version numbers must match. > > You need to at least recompile, and possibly update, > > your skin to work with this version of Valgrind. > > Aborting, sorry. > > ------------------------------------- > > > > What gives ? > > Let me guess: you're using the CVS head with the calltree patch. The > core/skin interface changed recently, and now the core you are using > doesn't match the skin any more. If you recompile the skin it will > hopefully work, although depending on how up-to-date your core version is, > it may complain about a missing function when trying to print the command > line usage message. I think Josef F has a fix for Calltree for that. > > I tried to make the error message pretty clear... could I make it more > informative? > > N -- Biswa. |
|
From: Luke H.
|
>No, you can't disable it. The only reason we ship our own is that
>V can't simulate some important things in the real pthread library.
>All in all it's a gain pain in various parts of the body for us to
>have our own pthreads library, and believe me, we wouldn't do so if
>we could run the real one.
Understood. Do you have any suggestions about how I might debug this
RPC server which appears to be unvalgrindable?
Before receiving an RPC, the main thread has the following stack:
(gdb) bt
#0 0x40192fb2 in vgPlain_do_syscall () from /usr/local/lib/valgrind/valgrind.so
#1 0x4052a3d2 in recvmsg (fd=9, message=0x496e784c, flags=0) at libc_jacket.c:221
#2 0x45fbed05 in RPC_SOCKET_RECVMSG (sock=9, iovp=0x496e7974, iovlen=1, addrp=0x0, ccp=0x496e797c,
serrp=0x496e7970) at ../../../ncklib/include/comsoc_bsd.h:339
#3 0x45fbe791 in receive_packet (assoc=0x417993b8, fragbuf_p=0x496e7ba4, ovf_fragbuf_p=0x496e7ba0,
st=0x496e7b98) at cnrcvr.c:1281
#4 0x45fbcded in receive_dispatch (assoc=0x417993b8) at cnrcvr.c:508
#5 0x45fbc4c6 in rpc__cn_network_receiver (assoc=0x417993b8) at cnrcvr.c:274
#6 0x4053358c in thread_wrapper (info=0x4179950c) at vg_libpthread.c:671
#7 0x4016ce88 in do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2152
After:
(gdb) bt
#0 vg_do_syscall2 (syscallno=1079222716, arg1=1077504048, arg2=0) at vg_mylibc.c:76
#1 0x00000004 in ?? ()
#2 0x4017f9e2 in vgPlain_main () at vg_main.c:1442
Setting a breakpoint on siglongjmp() crashes valgrind.
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:13:29
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > ------------------------------------ > Error: > Skin and core interface versions do not match. > Interface version used by core is: 2.0 > Interface version used by skin is: 1.2 > The major version numbers must match. > You need to at least recompile, and possibly update, > your skin to work with this version of Valgrind. > Aborting, sorry. > ------------------------------------- > > What gives ? Let me guess: you're using the CVS head with the calltree patch. The core/skin interface changed recently, and now the core you are using doesn't match the skin any more. If you recompile the skin it will hopefully work, although depending on how up-to-date your core version is, it may complain about a missing function when trying to print the command line usage message. I think Josef F has a fix for Calltree for that. I tried to make the error message pretty clear... could I make it more informative? N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:08:56
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > I'm getting the following error with CVS valgrind + cachegrind skin ( > alias cachegrind='valgrind --skin=cachegrind --num-callers=25 > --logfile-fd=6' > /opt/gnome2.2/bin/valgrind > > ------------------------------------ > ==6863== error: can't open cache simulation output file > `cachegrind.out.6863' > ==6863== ... so simulation results will be missing. > ------------------------------------ > > A 0 byte file cachegrind.out.6863 is created. There is sufficient space > in the harddisk : > > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda2 37334192 15213876 20223844 43% / Is file descriptor 6 legitimate? Does it work if you let Valgrind's output go to stderr as usual? N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:05:47
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > Is there any reason why the calltree skin > (http://kcachegrind.sourceforge.net/) is not included by default with > valgrind ? Seems darn useful to me :-) We had to draw the line somewhere w.r.t the number of skins to include in the default distribution. It's kind of arbitrary. N |
|
From: Julian S. <js...@ac...> - 2003-04-16 07:58:57
|
> All in all it's a gain pain in various parts of the body for us to
^
t
Duh.
J
|
|
From: Julian S. <js...@ac...> - 2003-04-16 07:54:27
|
No, you can't disable it. The only reason we ship our own is that V can't simulate some important things in the real pthread library. All in all it's a gain pain in various parts of the body for us to have our own pthreads library, and believe me, we wouldn't do so if we could run the real one. J On Wednesday 16 April 2003 8:32 am, Luke Howard wrote: > I'm trying to debug a problem with a DCE RPC server, which uses exception > handling implemented on top of pthread cancels and > sigsetjmp()/siglongjmp(). > > This appears to cause problems with valgrind after the first client > request: > > ==29326== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup > handlers are ignored) > > After which the call stack is trashed and the server is catatonic. In > attempting to find the bug I'm looking for, I'm wondering whether it > is possible to disable valgrind's interposing pthread library. > > -- Luke |
|
From: Luke H.
|
I'm trying to debug a problem with a DCE RPC server, which uses exception handling implemented on top of pthread cancels and sigsetjmp()/siglongjmp(). This appears to cause problems with valgrind after the first client request: ==29326== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup handlers are ignored) After which the call stack is trashed and the server is catatonic. In attempting to find the bug I'm looking for, I'm wondering whether it is possible to disable valgrind's interposing pthread library. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 06:55:48
|
gives: ------------------------------------ Error: Skin and core interface versions do not match. Interface version used by core is: 2.0 Interface version used by skin is: 1.2 The major version numbers must match. You need to at least recompile, and possibly update, your skin to work with this version of Valgrind. Aborting, sorry. ------------------------------------- What gives ? -- Biswa. |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 06:23:30
|
Hi
I'm getting the following error with CVS valgrind + cachegrind skin (
alias cachegrind='valgrind --skin=cachegrind --num-callers=25
--logfile-fd=6'
/opt/gnome2.2/bin/valgrind
------------------------------------
==6863== error: can't open cache simulation output file
`cachegrind.out.6863'
==6863== ... so simulation results will be missing.
------------------------------------
A 0 byte file cachegrind.out.6863 is created. There is sufficient space
in the harddisk :
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 37334192 15213876 20223844 43% /
Can someone give me a clue ?
Thanks in adavnce.
--
Biswa.
|
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 06:15:10
|
Hi Is there any reason why the calltree skin (http://kcachegrind.sourceforge.net/) is not included by default with valgrind ? Seems darn useful to me :-) Thanks in advance, and regards, -- Biswa. |