-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Andy Wood Sent: 27 June 2012 06:54 To: [email protected] Subject: Re: Setting SA SLIP traps
On Tue, 26 Jun 2012 20:31:16 +0800, Robin Atwood <[email protected]> wrote: >I am trying to intercept a pointer overwrite. From the dump I can see >we have something like > L R10,X'88'(R13) > ST R1,0(R10) > >which gets abend0C4 because R10 contains X'7FFFFFFF'. At some point the >stack addressed by R13 is getting overwritten. I have set a SLIP trap >using the command > > SLIP >SET,SA,RANGE=(13000000,14000000),DATA=(13R?+88,EQ,7FFFFFFF),JOBNAME=... > >since from the dumps the stack is normally in the range I specify. To >test I have deliberately set the pointer to X'7FFFFFFF' but the trap >isn't matched. Have I got the syntax right for what I want? I obviously >don't know exactly where the stack will be getmained when the program >starts. Does the RANGE specify instructions or data? Using an indirect >address in the DATA triplet seems to imply it's checked after every >instruction is executed. > RANGE for a SA trap refers to the storage being altered. RANGE on an IF trap on the other hand refers to where the instructions are. Ideally you would want the trap to match right on the instruction that caused the damage. What that trap is doing is causing a per PER interrupt every time any storage in the (somewhat huge) range is updated. For every interrupt, the slip code then checks the DATA using the R13 contents at the time the interrupt occurred. The trouble with that (besides the potentially high overhead) is that at the time the field gets clobbered, R13 quite possibly does not contain the same address as it does at the point you got the ABEND0C4, and so the trap would not match at that point. It might match at some later point when R13 happens to be pointing to the correct stack area, but when some some other data in the RANGE gets altered. So, at best you might get lucky and get a dump a bit closer to where things went wrong. That might not explain why the slip would not match for your test, as you might have had R13 pointing to the correct address, but I don't see anything else obviously wrong there, unless, as I think Binyamin was trying to say, the trap got disabled for PERCENTLIM, but you would see a message for that. It is possible to set a SA trap to cover a range in dynamically acquired storage, using a "dynamic PER chain". To do that, you would identify some point in the code where the stack area has been obtained, and where you know for sure that the address of this area is in a register (R13 or any other register). You can set a IF trap at that point, with TARGETID pointing to the SA trap to catch the overlay. Because the SA trap is then set via the IF trap, you can then use something like R13?+88 (or using some other register, as necessary) in the RANGE for the SA trap. There are some examples in the book. You still need to watch out for using DATA on the SA trap - using a register to locate the storage for a compare has the same issue as the trap you already tried. In the days when I used to tangle with SLIP, the solution to this involved knowing where the control register 10 value (start of PER range) was stashed, but now I see you can use the symbol "BPER" – I'm not sure when that symbol arrived. ---------------------------------------------------------------------- Thanks to Binyamin and Andy for their advice. Andy's dissertation was particularly helpful. However, as is so often the case, while I was sitting there pondering and staring at the dump and wondering why the SLIP hadn't gone off, suddenly all was revealed to me in a flash! It was so obvious I should have seen it days ago. Anyway, thanks again to everyone. :) -Robin This message has been scanned by MailController - portal1.mailcontroller.co.uk ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
