🚀 go-pugleaf

In article <Bxw84n.I5C@CAM.ORG> vandry@CAM.ORG (Phillip Vandry) writes:
>
>I'm having problems -- crashy problems with creating a child process.
>Consider this code fragment:
>
>        fork    #process
>        sta     pid1
>loop34  wait    #0
>        brk     0
>        case    on
>        cmp     pid1
>        bne     loop34
>        brl     bigbig
>
>It's almost identical to the code in script.asm, so it should work!


Looking over your snapshot of code, nothing immediately jumps out as being
incorrect. I assume the macros are correct and just extracted from the
script.asm code. For example, the #0 passed to wait is a long null pointer,
not a word.

Another possibility is the forked process completed before the wait
call was executed, but that doesn't jive with a crash bug.

One powerful way of debugging code that use kernel calls is the
'setdebug' command builting to gsh. The entire wait() mechanism is
based on signals, so a 'setdebug +sigtrace' will show you all the
signals being passed through the system. If your code is simply 
corrupting the stack, however, setdebug will never show you the
problem, though you may be able to determine that a crash happened before
or after a certain signal.

oh, another pitfall, if you are running multiple copied of the forked
code (which your code seems to say you aren't) be sure to use stack
based variables or some sort of mutual exclusion scheme, otherwise
several versions of the code will be simultaneously trying to use
the same variable for different tasks, thus royally screwing with
the system.

If anyone has a really cool idea for a multitasking demo I could
whip together in assembly using foks ands semaphores and such, be
sure to let me know, I'm sure the more sample code available,
the easier it will be for any of you to write multitasking
code.

Philip, if your code isn't too large or cumbersome and you're still
having problems, send me enough code so I can assemble it and I'll
see if I can come up with a solution...

-tim

TIM MEEKINS                    Ask me about GNO/ME! - MultiTasking on a IIGS!
meekins@cis.ohio-state.edu     Procyon, Inc., 11738 Aqueduct Drive
AOL: GNO Tim2 (@aol.com)       Littleton, CO 80127   (303) 933-4649
                          
      "Computers aren't intelligent, they just think they are."