jjfeiler@tybalt.caltech.edu (John J. Feiler) (08/30/88)
I'm trying to get a new process started using the example in Bob Pecks book, and I'm getting some strange crashes. I'm using SDB, and if I single-step through the code, everything works fine. When I run the code w/o SDB, i get a 87000004 guru. The code frag looks something like this: PutMsg(loaderport,hellomessage); WaitPort(myport); <- here is where it crashes reply = GetMsg(myport); Any suggestions? I'm also getting some crashes that can be eliminated by inserting a printf in the appropriate place, but these are nowhere near each other. Thanks.. John Feiler ============== John Feiler "Life's like a jigsaw, you get the 709 Locust #7 straight bits, but there's something Pasadena, CA 91101 missing in the middle..." jjfeiler@tybalt.caltech.edu -- XTC What's the difference between a duck? ==============
rap@ardent.UUCP (Rob Peck) (08/31/88)
In article <7730@cit-vax.Caltech.Edu>, jjfeiler@tybalt.caltech.edu (John J. Feiler) writes: > I'm trying to get a new process started using the example in Bob Pecks book, and I'm getting some strange crashes. I'm using SDB, and if I single-step > through the code, everything works fine. When I run the code w/o SDB, i get a > 87000004 guru. > > I'm also getting some crashes that can be eliminated by inserting a printf > in the appropriate place, but these are nowhere near each other. I am posting a pair of messages I received from Steve Walton regarding using the Create Process example with Manx. Part of these messages wound up in the latest posting of my errata, but maybe not all of it. Anyway, it seems that Steve found that the Manx adaptation required a lot of work, and if anyone else out there has done a short example that would be both Manx and Lattice compatible without such a degree of effort (and of course run clean and return all memory and not busy wait, etc etc etc) I would jump at the chance to replace the existing program with that something-better and as I did for Tom Rokiki's "showdate" program, I would be PLEASED to include your (whomever's) name as the contributor of a better example. This is LOTSA work, folks, that Steve did, and I would prefer a different example rather than recommend that everyone go thru this: ======================================= (Question from Jerry Tunnell:) page 319- Do you know how to modify the proctest - littleproc example to work under Manx C? It worked fine under lattice, but I could not find the analog of Astartup to handle the process stdin and stdout. (Replies from Steve Walton, on two separate occasions, both printed here:) Rob, I can give you a very quick answer to Jerry Tunnell's comments on proctest/littleproc under Manx. There is no Manx equivalent of ASTARTUP.OBJ. stdin, stdout, stderr always point to Manx file descriptors, not AmigaDOS file handles. Since the Manx functions printf/fprintf are a proper superset of the ones in Amiga.lib, the examples in the book work fine without linking to amiga.lib. The original purpose of the Astartup.obj code was to make smaller programs, I believe, but this is not a problem with Manx nor, I believe, with the latest Lattice compiler. The other item, specific to proctest, is that new tasks should call the Manx-provided geta4() first. By default, Manx produces code in a "small model" in which all code references are done with a 16-bit offset from the value contained in A4. Since the value of A4 gets lost during a CreateTask() call, Manx's hook into Exec's CreateTask() saves A4 in a global variable; geta4() places the contents of that global back into A4 for use by the new task. If this is too much trouble, the code in the book should compile without change using the new +P (super portability) switch to Manx's cc command. However, you'll need to use cl32.lib (and ml32.lib, if need be) in this case, rather than c.lib. Hope this helps. Steve Walton -------------------------------------- (second message as a followup) -------------------------------------- Rob and Jerry, I have proctest/littleproc working under 1.2 and Aztec C 3.4. Rather than try to get Astartup.asm to work with Manx, I simply made the following changes to the Manx-supplied startup and cleanup routines, _main.c and _exit.c, found on the second 3.4 distribution disk in the directory crt_src. These changes make them functionally equivalent to Astartup.asm. Both files ---------- Remove all references to _devtab. Remove the #include of fcntl.h. _main.c ------- (1) Add the line long stdin, stdout, stderr; to the beginning of the file to declare these external longs. (2) Just before the call to main(), add the lines: stdin = Input(); if ((stdout = Output()) != NULL) stderr = Open("*", MODE_NEWFILE); This sets up the extern longs stdin, stdout and stderr to point to the AmigaDOS files in question. Astartup.asm sets stderr to be equal to stdout, but I prefer them to be separate, hence the Open(). _exit.c ------- (1) Add the declaration extern long stdin, stdout, stderr; to the top of the file. (2) Add to the beginning of the routine: if (stderr != NULL) Close(stderr); to close the stderr file if it was opened. Finally, compile these two routines and littleproc.c and proctest.c with the +L switch to the Manx cc, put the CBM amiga.lib (on the 1.2 native developers' kit) someplace where ln can find it, and link with the commands: ln -o proctest _main.o _exit.o proctest.o +l amiga.lib +l -lc32 and similarly for littleproc. This will take a *long* time, and should be done with with amiga.lib in a RAMdisk (or with Facc installed). Manx's library format is much more efficient than the Amiga's. I actually went through proctest.c and littleproc.c and fixed all the places where there was an int where there should have been a long or a pointer: declarations of FindTask() and AllocMem(), declarations of mm_inputHandle and mm_OutputHandle, and declarations of stdin, stdout, stderr, and myOutput (or whatever littleproc called it). I also made sure the arguments to system calls were long, for instance by changing FindTask(0) to FindTask(0L) and casting the sizeof() arguments to AllocMem and FreeMem to long. This allowed them to work without the +L cc switch. Hope all this helps. I haven't tried the above _main and _exit with inittask, but it should work, provided a call to geta4() is added to the start of the child task. Steve ================== Again, thanks to Steve Walton for providing this information. I am planning to try to get SYBEX to include this information as an addendum or appendix to the book, or find some way (can you say aaaarrrggghhh!) to include the appropriate information directly into the text so that this question will not come up for 50% of my audience (Manx users %?). Probably the appendix route is better, thereby avoiding massive retype setting beginning at P319. Will see what I can do in the near term. Meantime, PLEASE spread this file far and wide, ok? Along with any other errata I have already posted. Thanks. Rob Peck
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/31/88)
:PutMsg(loaderport,hellomessage); :WaitPort(myport); <- here is where it crashes :reply = GetMsg(myport); : :Any suggestions? : : Thanks.. : John Feiler Well, it isn't enough of a fragment to tell you what is wrong. loaderport must be a pointer to a port, obviously. Same goes for myport. hellomessage must be a pointer to a message. hellomessage must have mn_ReplyPort set to myport if you intend for it to come back to myport. myport must be properly initialized.... ln_Type = NT_PORT, mp_SigBit = signal number, mp_Flags = PA_SIGNAL, mp_SigTask = FindTask(NULL), and the port's list properly initialized: NewList(&myport->MsgList). Did I miss anything? -Matt
jjfeiler@tybalt.caltech.edu (John J. Feiler) (08/31/88)
In article <8808301933.AA16947@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
-:PutMsg(loaderport,hellomessage);
-:WaitPort(myport); <- here is where it crashes
-:reply = GetMsg(myport);
-:
-:Any suggestions?
-:
- Well, it isn't enough of a fragment to tell you what is wrong.
- loaderport must be a pointer to a port, obviously. Same goes for
- myport. hellomessage must be a pointer to a message. hellomessage
- must have mn_ReplyPort set to myport if you intend for it to come
- back to myport.
- myport must be properly initialized.... ln_Type = NT_PORT, mp_SigBit =
- signal number, mp_Flags = PA_SIGNAL, mp_SigTask = FindTask(NULL), and
- the port's list properly initialized: NewList(&myport->MsgList).
- -Matt
loaderport and myport and hellomessage and mn_replyport are set correctly
I use muport = CreatePort("loader",0L); or something like that, so that should
do all of the proper initialization for myport, right?
John
==============
John Feiler "Life's like a jigsaw, you get the
709 Locust #7 straight bits, but there's something
Pasadena, CA 91101 missing in the middle..."
jjfeiler@tybalt.caltech.edu -- XTC
What's the difference between a duck?
==============dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/01/88)
>loaderport and myport and hellomessage and mn_replyport are set correctly >I use muport = CreatePort("loader",0L); or something like that, so that should >do all of the proper initialization for myport, right? > John Yup, for the port at least. I dunno whats wrong though... -Matt