Problem with "findpregtype".

Narendra Thapa — Mon, 30 Nov 2009 12:22:08 GMT

Hi All,

I am writing a device driver on HPUX. I am seeing different behavior of findpregtype() on debug and non debug HPUX OS.

findpregtype() in the code below is always returning “preg->p_reg” as NULL on debug version of HPUX (B.11.31.0903). But, it works correctly on PERF HPUX.

vas = p_vas(procp_self());
vas_read_lock(vas);
preg = findpregtype(vas, PT_TEXT, (struct kthread *)NULL);
vas_unlock(vas);
if (preg && preg->p_reg)
{
vp = preg->p_reg->r_fstore;
}

Please let me know if I am missing anything here.

Re: Problem with "findpregtype".

Don Morris_1 — Mon, 30 Nov 2009 15:09:26 GMT

Well, the first thing that comes to mind is that if you have access to debug builds -- you shouldn't be asking *here*. Either you're with HP (which I can't determine to be true hence I have to reply to you here) or you're suitably supported that you should use your support channels.

No one outside of R&D development environments should ever be running true debug bits.

That aside -- there are a couple thoughts on your code snippet:

1) It is not safe to read the p_reg field of the pregion in general as you describe without the VAS lock held. Yes, it is your VAS -- but the region underlying the pregion could be changed by another thread in your process [perhaps the text is being made self-patching (write is granted) and needs to be changed to a private copy instead of the globally shared bopy... that's a new region and hence the old region might go away between your dropping the lock and reading the field -- interrupts can happen at any time and mean you can't wave this away with "I do this quickly"].

2) More to the point -- what you're describing makes me wonder if your driver is also compiled Debug when you link with the debug kernel. The usual culprit when I see this type of nonsense result (and it is nonsense -- the race I describe at (1) is possible but should be really rare, which means that usually reading your own VAS/text combination should work. You handle the daemon case by checking for NULL -- and if the pregion is non-NULL, it pretty much should have a region. The fact that you imply this is both repeatable and does not happen on a Perf kernel (when there's no difference between the two for this algorithm) suggests to me that you're really reading the *wrong field*. Which naturally flows if you're linking a perf-built driver to a debug kernel. The debug version of a pregion structure gains a lot of extra (debugging fields) in things like embedded locks, etc. The p_reg offset may easily just be pointing to garbage -- which you happen to see as NULL.

One way to confirm (2) would be to use the debugger or disassemble your driver code -- see where the offset referenced is on the perf versus debug kernels. If the offset is the same (as I suspect), then compare that with the fields of preg_t, and you should see what you're really reading.

Re: Problem with "findpregtype".

Dennis Handly — Tue, 01 Dec 2009 09:21:49 GMT

>Don: One way to confirm (2) would be to use the debugger or disassemble your driver code

If it has debug info, you can get it to print out the offsets of each field.
gdb has "info types" and "ptype -v".
kwdb doesn't have -v but q4 has "fields -cv".

Re: Problem with "findpregtype".

Narendra Thapa — Tue, 01 Dec 2009 12:28:31 GMT

Hi Don Morris I was able to solve the issue with your suggested 2nd point.

Thanks to Dennis also for replying to my query.

Closing the thread as script is working now.

topic Re: Problem with "findpregtype". in Operating System - HP-UX

Problem with "findpregtype".

Re: Problem with "findpregtype".

Re: Problem with "findpregtype".

Re: Problem with "findpregtype".