|
From: Dennis L. <pla...@in...> - 2005-07-29 21:18:22
|
Hi, just tried to build and run valkyrie with valgrind3 from todays morning (29.07). After beeing confused whats meant by the vg install dir parameter to configure (I have installed the parts of valgrind at different positions) I managed to work with it, but found a few things that make this tool not yet usable to me: - ANSI Color codes are not interpreted (our output is relatively much colored to denoted module in which it is etc.) - ncurses support does not work completely - A strange thing is that SIOCGIFHWADDR ioctl does not work (returns no such device) when run via valkyrie under valgrind3, but with valgrind3 pure it works... thats pretty strange... greets Dennis |
|
From: Cerion Armour-B. <ce...@op...> - 2005-08-01 15:25:23
|
Hi Dennis, On Friday 29 July 2005 23:18, Dennis Lubert wrote: > Hi, > > just tried to build and run valkyrie with valgrind3 from todays morning > (29.07). After beeing confused whats meant by the vg install dir > parameter to configure (I have installed the parts of valgrind at > different positions) I managed to work with it, but found a few things > that make this tool not yet usable to me: > > - ANSI Color codes are not interpreted (our output is relatively much > colored to denoted module in which it is etc.) > - 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... > - A strange thing is that SIOCGIFHWADDR ioctl does not work (returns no > such device) when run via valkyrie under valgrind3, but with valgrind3 > pure it works... thats pretty strange... Really?! Can you supply a test case we can look at? > greets > > Dennis Thanks for your comments, Cerion |
|
From: Dennis L. <pla...@in...> - 2005-08-01 16:33:32
|
Hi At 17:24 01.08.2005, Cerion Armour-Brown wrote: >Hi Dennis, > > > - 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. > > - A strange thing is that SIOCGIFHWADDR ioctl does not work (returns no > > such device) when run via valkyrie under valgrind3, but with valgrind3 > > pure it works... thats pretty strange... >Really?! Can you supply a test case we can look at? 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 ? greets Dennis Carpe quod tibi datum est |
|
From: Julian S. <js...@ac...> - 2005-08-01 16:48:21
|
> >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. Yes, that's maybe a more robust/general solution. > 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. J |
|
From: Dennis L. <pla...@in...> - 2005-08-01 17:16:11
|
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
greets
Dennis
Carpe quod tibi datum est
|
|
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: 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 |