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
(21) |
2
(16) |
3
(3) |
4
(8) |
5
(9) |
6
(9) |
|
7
(14) |
8
(16) |
9
(21) |
10
(39) |
11
(29) |
12
(23) |
13
(9) |
|
14
(5) |
15
(8) |
16
(17) |
17
(30) |
18
(8) |
19
(35) |
20
(2) |
|
21
|
22
(2) |
23
(8) |
24
(15) |
25
(6) |
26
(20) |
27
(4) |
|
28
(1) |
29
(4) |
30
(8) |
31
(19) |
|
|
|
|
From: Robert W. <rj...@du...> - 2005-08-02 18:22:08
|
> Yeh, but then you have a dependency on gigabytes of extra Gnome/KDE/ > whatever gunk. Yeah - I was hoping there was a simple terminal emulator Qt widget, but it doesn't look like such a beast exists. Pulling in KDE or Gnome would not be fun. > It's a lot of development and maintenance effort to > duplicate functionality which already exists anyway. I'm with Nick > on this one. Well, another thought (just flogging a dead horse here) would be to use "xterm -e <stub> -into <windowid>" and have <stub> be a simple pipe program that hands stdin, stdout and stderr back and forth between Valkyrie and the terminal emulator. <windowid> would be the chunk of space in Valkyrie that's set aside for the display. Regards, Robert. |
|
From: Oswald B. <os...@kd...> - 2005-08-02 18:18:20
|
On Tue, Aug 02, 2005 at 07:09:09PM +0100, Julian Seward wrote: > It's a lot of development and maintenance effort to > duplicate functionality which already exists anyway. > it should be a simple matter to start a random terminal emulator, find out which tty it created and redirect the client to it. after all, ddd manages to do so ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Julian S. <js...@ac...> - 2005-08-02 18:09:17
|
> > I think the latter. I expect that if you try to provide a built-in > > terminal it will take a lot of development effort, you'll never get it to > > work exactly the way the normal terminals work, and both you and users > > will get frustrated... > > Really? Gnome comes with a terminal widget. I'm guessing Qt (or KDE, > probably) comes with one, too. Yeh, but then you have a dependency on gigabytes of extra Gnome/KDE/ whatever gunk. It's a lot of development and maintenance effort to duplicate functionality which already exists anyway. I'm with Nick on this one. J |
|
From: Dennis L. <pla...@in...> - 2005-08-02 17:25:39
|
At 18:03 02.08.2005, Cerion Armour-Brown wrote: >On Monday 01 August 2005 18:33, Dennis Lubert wrote: > >Been having a look at this. I see it's rather more useful than I realised - >indeed, some programs won't work at all without a pty (e.g. ssh), even if we >supported stdin (not quite there)... > >We're wondering whether to go the route of providing a terminal within the >GUI, or to simply use the same terminal that Valkyrie was started in. > >This becomes a broader question: >Should Valkyrie just be a nice 'display tool' of Valgrind's output, or should >it become a full-blown debugging interface? Or somewhere in between? > >Myself, I still use emacs over kdevelop... >But what would you (and others out there?) actually prefer? > >Cheers, >Cerion Ok, lets try it from this point: I currently use vim as my editor, make & gcc to compile, and manually run valgrind 2 or 3 (having both installed and working) from time to time on the programs. Some are interactive ncurses programs, so I dump the stuff into files. Then I compare the -v summary part, look what errors have disappeared, what have been added and go on. If valkyrie should really be able to help me then I should be able to compare, run it with the executable as command line, so for me it would be best if I/O would then happen in the terminal where it was started. Valkyrie shouldn't become a full blown debugging interface, but it would be nice if I can instruct it to properly start ddd to debug stuff in case of errors, or to intelligently compare errors (Like, on different runs there may be different addresses, or slightly different line numbers, but all come from the same source, edited in between). At least for me, this would be the way valkyrie could be of most help for me. greets Dennis Carpe quod tibi datum est |
|
From: Robert W. <rj...@du...> - 2005-08-02 16:36:31
|
> > We're wondering whether to go the route of providing a terminal within = the > > GUI, or to simply use the same terminal that Valkyrie was started in. >=20 > I think the latter. I expect that if you try to provide a built-in=20 > terminal it will take a lot of development effort, you'll never get it to= =20 > work exactly the way the normal terminals work, and both you and users=20 > will get frustrated... Really? Gnome comes with a terminal widget. I'm guessing Qt (or KDE, probably) comes with one, too. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@cs...> - 2005-08-02 16:32:35
|
On Tue, 2 Aug 2005, Cerion Armour-Brown wrote: > We're wondering whether to go the route of providing a terminal within the > GUI, or to simply use the same terminal that Valkyrie was started in. I think the latter. I expect that if you try to provide a built-in terminal it will take a lot of development effort, you'll never get it to work exactly the way the normal terminals work, and both you and users will get frustrated... N |
|
From: Cerion Armour-B. <ce...@op...> - 2005-08-02 16:03:24
|
On Monday 01 August 2005 18:33, Dennis Lubert wrote: > > > - ncurses support does not work completely > > > >The stdout/stderr output panes give plain text only. They're envisaged use > > is as debugging aids, not as interactive shells. Perhaps one day, if > > there's enough people wanting this... > > Maybe lots of people just dont use the program because they see they cannot > use it ;) > As a workaround, maybe it can be set so the output of the program can be > redirected to the console the program is started in, so ncurses and ansi > color programs would work as expected. Been having a look at this. I see it's rather more useful than I realised - indeed, some programs won't work at all without a pty (e.g. ssh), even if we supported stdin (not quite there)... We're wondering whether to go the route of providing a terminal within the GUI, or to simply use the same terminal that Valkyrie was started in. This becomes a broader question: Should Valkyrie just be a nice 'display tool' of Valgrind's output, or should it become a full-blown debugging interface? Or somewhere in between? Myself, I still use emacs over kdevelop... But what would you (and others out there?) actually prefer? Cheers, Cerion |
|
From: Duncan S. <bal...@fr...> - 2005-08-02 14:22:58
|
> Can you try r4305 and see if that helps? Yes, it seems to do the job. Thanks a lot, Duncan. |
|
From: Nicholas N. <nj...@cs...> - 2005-08-02 13:54:10
|
On Tue, 2 Aug 2005, Yeshurun, Meir wrote: > My program has a child process that produces the common invalid free > error because of libc_freeres(). Are you using --libc-freeres=yes? > Can this cause the child process to return a failure exit status (even > if it returns a success exit status when the program is not run under > Valgrind)? Valgrind does not itself change the exit code of a program, so this is unlikely. N |
|
From: Julian S. <js...@ac...> - 2005-08-02 13:36:16
|
On Tuesday 02 August 2005 08:37, Duncan Sands wrote: > Hi Julian, > > > Anyway: Duncan: I just committed my hacky fix (r4303). Can you > > update and check it? Big sigh (horrible hack) Can you try r4305 and see if that helps? J |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-02 12:27:45
|
Hi, =20 My program has a child process that produces the common invalid free error because of libc_freeres(). =20 Can this cause the child process to return a failure exit status (even if it returns a success exit status when the program is not run under Valgrind)? =20 Thanks, =20 Meir =20 |
|
From: Julian S. <js...@ac...> - 2005-08-02 07:58:05
|
> > Anyway: Duncan: I just committed my hacky fix (r4303). Can you > > update and check it? > > while it fixes the test program I sent you, it fails badly on the > monster program: with smc-check=stack, it fails to spot smc on the > stack of the environment task (i.e. the process running the program, > rather than a thread created later). It also fails the single-threaded regression test on my amd64 machine under obscure circumstances. I'll have a look shortly. J |
|
From: Duncan S. <bal...@fr...> - 2005-08-02 07:37:56
|
Hi Julian, > Anyway: Duncan: I just committed my hacky fix (r4303). Can you > update and check it? while it fixes the test program I sent you, it fails badly on the monster program: with smc-check=stack, it fails to spot smc on the stack of the environment task (i.e. the process running the program, rather than a thread created later). I'll try to cook up a small test case. It's a bit strange because (1) single threaded programs seem to be OK; and (2) when I tweaked my multithreaded test program to also do trampolines on the environment task's stack, it went fine. Ciao, Duncan. |
|
From: Julian S. <js...@ac...> - 2005-08-01 23:28:51
|
> > It's used in the leak checker when deciding which segments should serve > > as roots. > > Also a bug then presumably if only the first thread has it set... Yup. Anyway: Duncan: I just committed my hacky fix (r4303). Can you update and check it? J |
|
From: Nicholas N. <nj...@cs...> - 2005-08-01 23:27:08
|
On Tue, 2 Aug 2005, Tom Hughes wrote: >> It's used in the leak checker when deciding which segments should serve as >> roots. > > Also a bug then presumably if only the first thread has it set... yep N |
|
From: Tom H. <to...@co...> - 2005-08-01 23:16:09
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Mon, 1 Aug 2005, Julian Seward wrote:
>
> > It does however beg the question of what SF_STACK is really for.
>
> It's used in the leak checker when deciding which segments should serve as
> roots.
Also a bug then presumably if only the first thread has it set...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-01 23:15:36
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>
> > Only the main stack is ever automatically extended. I believe that
> > is true for both linuxthreads and NPTL threads.
> >
> > You should be looking at the SF_STACK flag I think.
>
> Alas .. only the main stack is marked SF_STACK, afaics. In order
> that V could know that the thread stacks are really stacks, it
> would have to be able to differentiate the mmap that creates
> them from arbitrary other anonymous mmaps that happen, and I don't
> think those stack-creating mmaps have any special flags that would
> distinguish them. So I don't think this _could_ work. It does
> however beg the question of what SF_STACK is really for.
Hmm. You're right... I could have sworn they all had SF_STACK set. In
fact in 2.2.0 they did, but it got lost with the threading changes.
The problem is that it is libpthread that allocates the stack now. We
could set SF_STACK on the segment if do_clone manages to find it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-01 22:43:01
|
On Mon, 1 Aug 2005, Julian Seward wrote: > It does however beg the question of what SF_STACK is really for. It's used in the leak checker when deciding which segments should serve as roots. N ps: http://en.wikipedia.org/wiki/Begging_the_question |
|
From: Julian S. <js...@ac...> - 2005-08-01 22:28:09
|
> Only the main stack is ever automatically extended. I believe that > is true for both linuxthreads and NPTL threads. > > You should be looking at the SF_STACK flag I think. Alas .. only the main stack is marked SF_STACK, afaics. In order that V could know that the thread stacks are really stacks, it would have to be able to differentiate the mmap that creates them from arbitrary other anonymous mmaps that happen, and I don't think those stack-creating mmaps have any special flags that would distinguish them. So I don't think this _could_ work. It does however beg the question of what SF_STACK is really for. J |
|
From: Dennis L. <pla...@in...> - 2005-08-01 21:04:41
|
At 22:43 01.08.2005, Dirk Mueller wrote: >On Monday 01 August 2005 14:45, Dennis Lubert wrote: > > > Looks like the SIOCGIFNAME bug mentioned a while ago on the list (and fixed > > in 3.x then) isnt yet fixed in this... > >you know which change in particular is responsible for this? there is no hit >for SIOCGIFNAME anywhere inside the valgrind-2.4 tree. coregrind/vg_syscalls.c l. 3044 ff. There is some integer parameter to the ioctl which is the index of the interface, which is misinterpreted by valgrind as an address thus causing a false "inaccesible memory passed to ioctl" error by valgrind. (It was on the list just a while ago and fixed in 3.x tree) greets Dennis Carpe quod tibi datum est |
|
From: Dennis L. <pla...@in...> - 2005-08-01 21:00:14
|
At 22:31 01.08.2005, Cerion Armour-Brown wrote: >On Monday 01 August 2005 19:16, Dennis Lubert wrote: > > > things like getopt etc. seem to rely on tokens seperatable by whitespace > > beeing in a distinc argv entry > > > >Absolutely right. Fixed. >Can you confirm this fixes your ioctl problem? confirmed, works now. Looking forward for any kind of support for ncurses etc. like doing output on the usual terminal... greets Dennis Carpe quod tibi datum est |
|
From: Dirk M. <dm...@gm...> - 2005-08-01 20:44:36
|
On Monday 01 August 2005 14:45, Dennis Lubert wrote: > Looks like the SIOCGIFNAME bug mentioned a while ago on the list (and fixed > in 3.x then) isnt yet fixed in this... you know which change in particular is responsible for this? there is no hit for SIOCGIFNAME anywhere inside the valgrind-2.4 tree. |
|
From: Cerion Armour-B. <ce...@op...> - 2005-08-01 20:31:41
|
On Monday 01 August 2005 19:16, Dennis Lubert wrote:
> At 18:48 01.08.2005, Julian Seward wrote:
> > > The real problem here was not the ioctl, but the argument passing to
> > > the program. valkyrie passes the whole "Binary flags" option as *one*
> > > parameter to the program (one argv entry) which confuses
> > > getopt/getopt_long, so I got " eth1" instead of "eth1" which of cause
> > > confuses the ioctl, since there really is no such device... maybe this
> > > should be fixed to pass them the same way the shell does ?
> >
> >I can half-see what you are saying, but it would help a lot if
> >you could send a specific example of what flag(s) it is that
> >Valkyrie is passing incorrectly to Valgrind.
>
> I dont know how it is passing things to valgrind, but consider this little
> program :
>
>
> #include <iostream>
>
> using namespace std;
>
> int main ( int argc, char* argv[] )
> {
> cout << argc << " Arguments" << endl;
> char** arg = & argv[0];
> while( *arg )
> {
> cout << "\"" << *arg << "\"" << endl;
> arg++;
> }
> }
>
> Running standalon or with valgrind : ./argtest -i eth1
> =output=
> 3 Arguments
> "./argtest"
> "-i"
> "eth1"
>
> but from within valkyrie (Setting the Binary flags option)
> =output=
> 2 Arguments
> "/home/plasmahh/argtest"
> "-i eth1"
>
> things like getopt etc. seem to rely on tokens seperatable by whitespace
> beeing in a distinc argv entry
>
Absolutely right. Fixed.
Can you confirm this fixes your ioctl problem?
Thanks,
Cerion.
|
|
From: Tom H. <to...@co...> - 2005-08-01 17:39:01
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> The cause of this is that with --smc-check=stack (the default)
> V does self-checking translations for code taken from segments
> which have the SF_GROWDOWN flag set. Unfortunately that appears
> to be only the initial thread at least on NPTL, and not the child
> stack threads. (Tom/Jeremy, is that indeed the case with NPTL?)
Only the main stack is ever automatically extended. I believe that
is true for both linuxthreads and NPTL threads.
You should be looking at the SF_STACK flag I think.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-08-01 17:21:37
|
On Monday 01 August 2005 15:46, Duncan Sands wrote: > > > I've noticed that I need to use smc-check=all, rather than > > > smc-check=stack, when running a multithreaded program that > > > uses trampolines. Presumably valgrind hasn't understood > > > that the new thread's stack is a stack. Is this the > > > intended behaviour? > > > > No, certainly not. It sounds like a bug in the is-this-a-stack? > > department. Can you send a binary I can try? The cause of this is that with --smc-check=stack (the default) V does self-checking translations for code taken from segments which have the SF_GROWDOWN flag set. Unfortunately that appears to be only the initial thread at least on NPTL, and not the child stack threads. (Tom/Jeremy, is that indeed the case with NPTL?) My proposed fix (which I just tried and it works) is to instead do a self-checking translation if the segment from which the translation is to be taken is the same one into which the requesting thread's simulated stack pointer points. If you see what I mean. Does anyone see anything that could go disastrously wrong as a result? J |