Eric Schrock wrote On 11/18/05 17:42,: > The '-L' flag requires manipulating the agent LWP in the target process. > If you mix this with the '-F' flag, you're dancing with the devil. > You'll basically have two processes fighting over the register sets of > the agent LWP, and it's no surprise that the target process died > unexpectedly. I'm not exactly sure why the pmap(1) process itself died, > that shouldn't be the case. In any case, don't use '-F' unless you're > really sure what you're doing. For example, a safe use case is if the > target is stopped via MDB, but you want to examine detailed state.
It hadn't clicked with me that the -L was done with the agent LWP so I guess that makes sense. I think it would be good to mention in the revised pmap man page that it is bad to cross the streams in such a way. People get used to forcing procbin tools and having a target of pmap dump out unexpectedly could be shocking to say the least. Let me know who wants the cores. Jon. > - Eric > > On Fri, Nov 18, 2005 at 04:43:32PM +0000, Jonathan Haslam wrote: > >>Hi, >> >>I've been using the new MPO observability tools on several >>projects (as a few of you on this list know). They are proving >>to be an *extremely* useful addition to the toolkit. >> >>Today I've just hit an issue that I wondered if you'd seen >>before. A colleague and I both issued a 'pmap -L' on an >>Oracle shadow process at roughly the same time (actually I >>forced mine). Unfortunately, not only did both pmap invocations >>core but the Oracle shadow process did as well (along with it's >>28GB of SGA...). >> >>The stack from pmap looks like: >> >># pstack core >>core 'core' of 1107: pmap -FL 900 >> 0000000000404970 get_meminfo () + 70 >> 0000000000405057 look_lgmap () + 197 >> 0000000000402267 iter_map () + 47 >> 00000000004047f1 main () + e91 >> 0000000000401fbc _start () + 6c >> >> >>Have you seen this before? I can get you the cores when >>the machine is available again. Unfortunately, it's feeling >>poorly at the minute though and needs to be massaged to >>resume normal service. This is snv_27, ptools-bin-0.1.2 on >>an amd based system. >> >> >>Cheers. >> >>Jon. >> >>_______________________________________________ >>observability-discuss mailing list >>observability-discuss at opensolaris.org > > > -- > Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
