Re: [9fans] debugging p9p threads question

Re: [9fans] debugging p9p threads question

[YAMANASHI Takeshi]

> interesting, that's the answer in the supercomputing world too. 

Interesting.  I'm tutoring high school students in a
programming contest right now.  They are writing their codes
with emacs/vi and running their MPI jobs on Origin 2k.

One of the contestants told me .NET was a far better interface
for programming, which included everything like editor,
compiler, debugger, online manuals and what not.

Actually, he even showed me debugging fruently on .NET.
I rather felt old then...
# no flame intended
-- 

Re: [9fans] debugging p9p threads question

[Skip Tavakkolian]

>> interesting, that's the answer in the supercomputing world too. 
> 
> Interesting.  I'm tutoring high school students in a
> programming contest right now.  They are writing their codes
> with emacs/vi and running their MPI jobs on Origin 2k.
> 
> One of the contestants told me .NET was a far better interface
> for programming, which included everything like editor,
> compiler, debugger, online manuals and what not.
> 
> Actually, he even showed me debugging fruently on .NET.
> I rather felt old then...
> # no flame intended
> -- 

It has been my experience that IDE's (including things like Eclipse)
add as many problems as they "solve" with their interfaces.  Also,
they're not universal; e.g.  try to do Windows driver debugging with
Visual Studio.  Guess what works?  printing to the console.

Acid is about the best idea I've seen.

Re: [9fans] debugging p9p threads question

[LiteStar numnums]

When I first started learning how to program, I had a Windblows box
and some generic C environment that included a 'RAD'. About a month
later, having made absolutely no progress with this 'RAD' thingie, a
family friend gave me Slackware 3.x and showed me some of the basics.
I wasted a month as an 11 year old attempting to use this asinine
'RAD', with its poor layout, awful design and features, whilst the
really useful toolset was sitting on the stupid Slackware CD. I've not
even heard the acronym 'RAD' as of late, but the new IDE's seem to be
just as awful as that one, but with better documentation of useless
features... ;-)
Meh, now I'll just go serialize some objects to XML...
 -- Stefan
On 8/2/05, Skip Tavakkolian <9nut@9netics.com> wrote:
> >> interesting, that's the answer in the supercomputing world too.
> >
> > Interesting.  I'm tutoring high school students in a
> > programming contest right now.  They are writing their codes
> > with emacs/vi and running their MPI jobs on Origin 2k.
> >
> > One of the contestants told me .NET was a far better interface
> > for programming, which included everything like editor,
> > compiler, debugger, online manuals and what not.
> >
> > Actually, he even showed me debugging fruently on .NET.
> > I rather felt old then...
> > # no flame intended
> > --
> 
> It has been my experience that IDE's (including things like Eclipse)
> add as many problems as they "solve" with their interfaces.  Also,
> they're not universal; e.g.  try to do Windows driver debugging with
> Visual Studio.  Guess what works?  printing to the console.
> 
> Acid is about the best idea I've seen.
> 
> 


-- 
The subject of this essay (the Myth of Sisyphus) is precisely
this relationship between the absurd and suicide, the exact
degree to which suicide is a solution to the absurd. The 
principle can be established that for a man who does not cheat,
what he believes to be true must determine his action.
Belief in the absurdity of existence must then dictate his
conduct. It is legitimate to wonder, clearly and without
false pathos, whether a conclusion of this importance
requires forsaking as rapidly possiblean imcompre-
hensible condition. I am speaking, of course, of men
inclined to be in harmony with themselves.
  << Albert Camus>>

Re: [9fans] debugging p9p threads question

[Tim Newsham]

> they're not universal; e.g.  try to do Windows driver debugging with
> Visual Studio.  Guess what works?  printing to the console.

Also windbg.  So much for the IDE.

> Acid is about the best idea I've seen.

I'm a bit fond of using /proc for debugging.  The fact that all you need 
to debug the kernel is provide a /proc shim is pretty nifty.  Its so 
obvious -- provide a single uniform interface for doing a task and reuse 
it where ever needed.  Why doesn't everyone do it?

Tim Newsham
http://www.lava.net/~newsham/

[9fans] debugging p9p threads question

[Ronald G. Minnich]

I'm hacking on sshnet and have truncated it and ported it to linux, but it 
is not quite baked. One odd thing I've seen: I've truncated the last bit 
of it to this:

void
threadmain(int argc, char **argv)
{
        char *user, *service;
/*
        fmtinstall('B', mpfmt);
        fmtinstall('H', encodefmt);
*/
        service = nil;
        user = nil;
        ARGBEGIN{
        case 'B':       /* undocumented, debugging */
                doabort = 1;
                break;
        case 'D':       /* undocumented, debugging */
                debuglevel = strtol(EARGF(usage()), nil, 0);
                break;
        case '9':       /* undocumented, debugging */
                chatty9p++;
                break;
        case 's':
                service = EARGF(usage());
                break;
        default:
                usage();
        }ARGEND

        if(argc)
                usage();
//      sshmsgchan = chancreate(sizeof(Msg*), 16);
        fsreqchan = chancreate(sizeof(Req*), 0);
        fsreqwaitchan = chancreate(sizeof(void*), 0);
        fsclunkchan = chancreate(sizeof(Fid*), 0);
        fsclunkwaitchan = chancreate(sizeof(void*), 0);

        proccreate(fsnetproc, nil, 8192);

        threadpostmountsrv(&fs, service, nil, MREPL|MCREATE);
        fprint(2, "threadpostmountsrv RETURNS!~!!!!!!\n");
        threadexitsall(0);
}

If I run this program, the fsnetproc will get a SIGUSR1, but not long 
after, will get a SIGUSR2; in fact, it gets the SIGUSR2 after the first 
time the server sends it a send and the does a recv. If I do this:

.
.
.
        
        proccreate(fsnetproc, nil, 8192);
        
        threadpostmountsrv(&fs, service, nil, MREPL|MCREATE);
        fprint(2, "threadpostmountsrv RETURNS!~!!!!!!\n");
	while(1)
		yield();
        threadexitsall(0);
}


Then the program will run, just fine.

Any idea what I could have done to break things? I have also done this to 
fsnetproc:

void
fsnetproc(void*v)
{
        ulong path;
        Alt a[4];
        Fid *fid;
        Req *r;

        threadsetname("fsthread");

        a[0].op = CHANRCV;
        a[0].c = fsclunkchan;
        a[0].v = &fid;
        a[1].op = CHANRCV;
        a[1].c = fsreqchan;
        a[1].v = &r;
#ifdef NO
        a[2].op = CHANRCV;
        a[2].c = sshmsgchan;
        a[2].v = &m;
        a[3].op = CHANEND;
#endif

        for(;;){
.
.
.


So I don't think the unitialized sshmsgchan should be a problem. 

I'm actually more interested in this question: how do you go about 
debugging this sort of problem? What's your favorite way to see what's 
going on? strace is pretty good, but not perfect. Do you use acid, or ...

thanks

ron

Re: [9fans] debugging p9p threads question

[Russ Cox]

Print statements.

Your call to threadexitsall(0) at the end of
threadmain is wrong.  It should be threadexits().
Threadexitsall makes all the procs exit, which
is not what you want.  Calling threadexits will
cause the threadmain thread to exit, and since
that is the only thread in the main proc, the 
main proc will exit, leaving the rest in the background.

Russ

Re: [9fans] debugging p9p threads question

[Ronald G. Minnich]

On Tue, 2 Aug 2005, Russ Cox wrote:

> Print statements.

interesting, that's the answer in the supercomputing world too. 

Geez, why are we spending all this money on debuggers :-)

on the 65K CPU blue gene box, I've been told that "debugging with over 512 
CPUs is ... printf". 


> Your call to threadexitsall(0) at the end of
> threadmain is wrong.  It should be threadexits().

Thanks. I did a stupid thing, changing the exits(0) from the plan 9 
version to this threadexitsall(0)! oops.

ron

Re: [9fans] debugging p9p threads question

[Charles Forsyth]

>>Geez, why are we spending all this money on debuggers :-)

it must surely be less than what is spent on xml, one way or another...

Re: [9fans] debugging p9p threads question

[Uriel]

The most effective debugging tool is still careful thought, coupled with
judiciously placed print statements.

    -- Brian W. Kernighan, in the paper Unix for Beginners (1979)

On Tue, Aug 02, 2005 at 05:00:18PM -0600, Ronald G. Minnich wrote:
> 
> 
> On Tue, 2 Aug 2005, Russ Cox wrote:
> 
> > Print statements.
> 
> interesting, that's the answer in the supercomputing world too. 
> 
> Geez, why are we spending all this money on debuggers :-)
> 
> on the 65K CPU blue gene box, I've been told that "debugging with over 512 
> CPUs is ... printf". 
> 
> 
> > Your call to threadexitsall(0) at the end of
> > threadmain is wrong.  It should be threadexits().
> 
> Thanks. I did a stupid thing, changing the exits(0) from the plan 9 
> version to this threadexitsall(0)! oops.
> 
> ron

Re: [9fans] debugging p9p threads question

[Russ Cox]

> The most effective debugging tool is still careful thought, coupled with
> judiciously placed print statements.
> 
>     -- Brian W. Kernighan, in the paper Unix for Beginners (1979)

And a lot of times you don't need the print statements.

Russ

Re: [9fans] debugging p9p threads question

[Ronald G. Minnich]

yeah, I did find my problem and it is an odd one. It seems that some bits 
of my server are "escaping" from out under strace. I can see the spawned 
thread in 'ps', and I can see its child in ps. What I can not see is that 
same proc in the strace output (yes, I am doing strace -f). This is an odd 
one -- I've never seen it and have no idea how it could happen. It's not a 
truncated strace output issue. The process is just no longer under the 
control/purview of strace. 

Ah, well, bigger fish to fry for now ...

ron

Re: [9fans] debugging p9p threads question

[Harri Haataja]

On Wed, Aug 03, 2005 at 08:20:08AM +0100, Uriel wrote:
> 
> The most effective debugging tool is still careful thought, coupled with
> judiciously placed print statements.
> 
>     -- Brian W. Kernighan, in the paper Unix for Beginners (1979)

At http://www.haskell.org/hawiki/QuotesPage:

seen on news://comp.lang.functional

> By the way seriously: how do you debug Haskell programs?

Mostly seriously: I don't. If the programme doesn't work the
way I intended it, I rewrite bits in a simpler fashion until
I understand it well enough and it works. For the sort of
programme you were asking for, breaking things up until they
are small enough that one can understand the individual
parts completely (as I did in the solution I posted) and
then composing them together really is the best approach.

If you need to debug a programme that simple, what it's
telling you is that you've written it the wrong way!

--
Jón Fairbairn


-- 
For indoor or outdoor use only
		-- Warning on a Xmas lights set

Re: [9fans] debugging p9p threads question

[Gorka guardiola]

On 8/6/05, Harri Haataja <harriha@mail.student.oulu.fi> wrote:
> 
> If you need to debug a programme that simple, what it's
> telling you is that you've written it the wrong way!
> 

This is not completely realistic. There are sometimes interactions
with libraries,
compilers... Simple programs have to be debug on occasions. I adhere with the
print+thought, more than with the allways rewrite (though on some
occassions that
is the way...). I also love dumping the stack with acid now and then.
It is invaluable
for finding faster deadlocks or lost pointers. 
-- 
- curiosity sKilled the cat