[M3devel] pthreads issues [was: Re: strange errors... ]
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Mon Jul 23 09:29:41 CEST 2007
Hi,
Actually the existing directories on m3-sys after
execution of scripts/do-cm3-std.sh buildship:
m3linker
m3front
cm3
On the
These packages are not listed when that script inits
I guess these packages are not necessary when
boostrapping cm3 without steps.
Executing scripts/do-cm3-core.sh realclean does that
cleans.
Thanks
--- "Daniel Alejandro Benavides D."
<dabenavidesd at yahoo.es> wrote:
> Hi:
> What I have saw of the two step boostrapping process
> is that cm3 executable looks in its own directory
> for
> cm3.cfg, so I have made a copy from
> /usr/local/cm3/bin
> to /usr/local/cm3/pkg/cm3/LINUXLIBC6
>
> Another thing is that do-cm3-std.sh realclean,
> doesnt
> clean some m3core parts, some yes.
>
>
> Thanks
>
> --- Mika Nystrom <mika at async.caltech.edu> wrote:
>
> >
> > Tony Hosking writes:
> > ...
> > >> but after recompiling a second time, it no
> longer
> > seems to do that.
> > >> By the way, I am somewhat suspicious that this
> > Juno crash has
> > >> something to do with threading: if you look
> > closely, that part of
> > >> Juno has to do with thread switching into and
> out
> > of the
> > >> Juno-machine...which is why I was happy to see
> it
> > disappear (however
> > >> it did that).
> > >
> > >Maybe you had stale code in the build
> directories?
> > Glad to hear it
> > >went away after recompiling.
> > >
> >
> > I *obsessively* clean my directories between
> builds!
> > I have double-
> > and triple-checked that nothing in the source tree
> > is left in object
> > form after doing
> >
> > do-cm3-std.sh realclean
> > do-cm3-core.sh realclean
> >
> > Yet, this happens. My best guess is that somehow,
> > old objects (from
> > /usr/local/cm3/pkg?) are "leaking" through the
> > bootstrapping process.
> > Surely that's not supposed to happen? Why does it
> > happen to me and
> > apparently not to you? I follow your directions
> > exactly and always
> > start from an absolutely clean system (on Mac I
> > don't even have PM3
> > installed, so there's no Modula-3 at all before I
> > start following
> > the instructions).
> >
> >
> > >> I still have a threading crash in mentor. I
> run
> > "Wheeler" to get this
> > >> one...
> > >>
> > ...
> > >>
> > >> ***
> > >> *** runtime error:
> > >> *** <*ASSERT*> failed.
> > >> *** file
> > "../src/thread/PTHREAD/ThreadPThread.m3", line 675
> > >> ***
> > >>
> > >
> > >That is an assert regarding setting the stack
> size.
> > I wonder if this
> > >is a Thread.SizedClosure which has a size value
> > that asks for a stack
> > >size less than PTHREAD_STACK_MIN. I am not sure
> > what the best way to
> > >handle that is except to disregard the return
> value
> > from
> > >pthread_attr_setstacksize. Can you try replacing
> > line 675 in
> > >ThreadPThread.m3 with:
> > >
> > > EVAL Upthread.attr_setstacksize(attr,
> > bytes);
> > >
> > >and rebuilding? I am surprised to see that error
> > though, since you
> > >will note that I get the default stack size from
> a
> > freshly
> > >initialized attributes structure on line 673 and
> > use the greater of
> > >the default size and the requested size.
> >
> > Debugging this a bit further, I think I'm just
> > running out of stack
> > space. You are saying that this call can fail
> > because of too small
> > a requested stack space, too? It might be nice to
> > have some sort
> > of error message here instead of just an assert
> > failure...
> >
> > How big is your stack limit on your mac? On mine
> > it's 64 megabytes,
> > and when I added some printing:
> >
> > RTIO.PutText("Upthread.attr_getstacksize
> > returned bytes=");
> > RTIO.PutInt(bytes);
> > RTIO.PutText(" defaultStackSize=");
> > RTIO.PutInt(defaultStackSize);
> > RTIO.PutChar('\n');
> >
> > bytes := MAX(bytes, size *
> ADRSIZE(Word.T));
> > WITH r = Upthread.attr_setstacksize(attr,
> > bytes) DO
> > IF r # 0 THEN
> >
> RTIO.PutText("Upthread.attr_setstacksize
> > failed, size=");
> > ELSE
> >
> RTIO.PutText("Upthread.attr_setstacksize
> > succeeded, size=");
> > END;
> > RTIO.PutInt(size);
> > RTIO.PutText(" bytes=");
> > RTIO.PutInt(bytes);
> > RTIO.PutChar('\n');
> > <*ASSERT r=0*>
> > END;
> > RTIO.Flush();
> >
> > I found the following:
> >
> > (running Wheeler)
> >
> > ... lots of times ...
> > Upthread.attr_setstacksize succeeded, size=79632
> > bytes=524288
> > Upthread.attr_getstacksize returned bytes=524288
> > defaultStackSize=79632
> > Upthread.attr_setstacksize succeeded, size=79632
> > bytes=524288
> > Upthread.attr_getstacksize returned bytes=524288
> > defaultStackSize=79632
> > Upthread.attr_setstacksize failed, size=637056
> > bytes=2548224
> >
> >
> > ***
> > *** runtime error:
> > *** <*ASSERT*> failed.
> > *** file
> > "../src/thread/PTHREAD/ThreadPThread.m3", line 692
> > ***
> >
> >
> > Program exited with code 01.
> >
> > It's really a bug in mentor. Zeus.m3:499 calls
> > IncDefaultStackSize
> > to request another 10 kilowords, Obliq.m3:32 calls
> > IncDefaultStackSize
> > for another 64 kilowords , and
> > WheelerCompressObliqView.m3 requests
> > 8*GetDefaultStackSize in a SizedClosure. A bunch
> of
> > those threads
> > and I just run out of stack space. (I am assuming
> > that pthreads
> > allocates stacks in the 'stack' segment of the
> > process...)
> >
> > Attempting to fix the bug in mentor makes it run
> out
> > of stack space,
> > looks like it's some recursive descent parser...
> > Maybe this demo
> > just won't run on my computer.
> >
> > >Weird, I was running Bresenham just fine
> yesterday
> > after the fix I
> > >checked in. Sounds like you may have some stale
> > object files lying
>
=== message truncated ===
____________________________________________________________________________________
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/entretenimiento.html
More information about the M3devel
mailing list