[M3devel] pthreads issues [was: Re: strange errors... ]

[Daniel Alejandro Benavides D.]

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  
> >around.
> 
> I was able to get it to run again.  And deadlock
> again.  And run
> again... it's definitely something intermittent.  I
> think it happens
> right when it attempts to start the threads, not
> afterwards.
> 
> And when you ctrl-C it, all you get is that it's
> stopped
> in Trestle__AwaitDelete (I already sent this one).
> 
> >
> >> I really don't think it's my old system that's
> corrupting the new  
> >> images,
> >> but I am *never* 100% certain of that.  I found a
> very weird behavior
> >> with the build system, actually.  I found that
> the not-yet-installed
> >> compiler in /usr/local/cm3/pkg/cm3/PPC_DARWIN/
> looks for cm3.cfg in
> >> /usr/local/cm3/bin, but *only* if that is in the
> shell PATH.  Is that
> >> a known/desired behavior?  It causes the brand
> new compiler to use the
> >> old cm3.cfg, and it does so quietly without any
> warnings or messages
> >> whatsoever.  Changing your PATH makes it stop do
> that and instead  
> >> crash,
> 
=== 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