>
> Hi All,
> I have modified mdb so that I can use ::print type with a raw disk. You
> can read this: http://www.bruningsystems.com/mdb.rdsk.txt
> for an example use. The changes to mdb that I made are essentially a
> hack, but they work... I modified source from around build 55b. So, I
>
> Since posting from opensolaris.org seems to get rejected, I'm trying
> this again...
>
>
> I'm currently finishing off some loose ends before (hopefully)
> integrating a non-encumbered libdisasm.so for sparc. During this,
> I've run into a minor issue with the kmdb build. I'd like to get som
> Hi all,
>
> since ufs community is somehow assumed dead and inactive and therefore
> viewed as not being able to sponsor projects,
> I would like to know your opinion and possibly ask for sponsorship of
> the following project related to MDB.
>
> ufs-ondisk
>
> Description:
>
> The goal of
>
> 10>n
> ::walk proc | head -n
> says
>
> Usage: head -num|-n num
> mdb: try '::help head' for more information
>
> Is that intentional? Is there a workaround?
>From a syntax perspective, the right-hand side of a dcmd is a collection
of strings, unless the $[ ] syntax is used to evaluate
> On Sun, Jan 28, 2007 at 05:21:46AM -0800, max at bruningsystems.com wrote:
>
> > I want to be able to use ::print some_type_in_kernel with the raw disk
> > as a target. Has anyone already done this, or do I need to write code?
>
> In an ideal world, you could do:
>
> # mdb /dev/dsk/c1t1d0s0
> Hi,
>
> Just wondering is there an mdb equivalvent for ecache_size on x64,
> can't see one, but just in case I'm missing something. Or is smbios
> the only/preferred way to get this info out of an x64 machine?
>
> - Fintan
There is no common definition of that on x64, nor any real need to kno
> Playing with MDB ::ps dcmd I noticed that the status field interpretation is
> different from the regular ps(1) command. The status in MDB is the value of
> pr.p_stat field which, according to the code may only have values SRUN, SIDL
> and SZOMB. The code in MDB pretends to understand other sta
> Unfortunately there in no pgrep dcmd in Solaris 9's version of mdb.
Well you should upgrade to S10 anyway :) ::pgrep is just the beginning.
In the meantime,
::ps ! grep
is your easiest substitute.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
> Hello everyone:)
>
> I've got a couple of questions and I'll be very thankful if someone can shed
> a light on these.
>
> 1) For example, I want to print proc_t structure of process "bc"
> I tried the following variant but stucked at the this stage
>
> ::walk proc p |::print proc_t p_user.u_
> Is there a way in mdb to specify the library path (similar to pathmap in dbx)
> so I can open the application core on target systems that doesn't have to be
> running at the same patch level as the system where the application core
> dumped..
MDB does not presently have such a pathmap feature.
> Is there a working version of svc_pool dcmd for Solaris 10 ?
> AFAIK it works only on Nevada.
>
> Thanks,
> -- leon
This dcmd does exist in the S10 patch gate as well, but perhaps there is
a problem. Can you e-mail back:
- what you're seeing when you apply it
- the output of uname -a on your
>
> Hi folks,
>
> I am looking at a S10 system dump, that has all kernel and user pages
> dumped to it.
>
> I am looking at the stack of a particular kernel thread, that does a
> door upcall to a user process acting as the door server.
>
> Since I know the proc_t address for the user process,
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> I have a query on user-level watchpoints. How do I get mdb
> to not stop when a watchpoint is hit? Basically I want to
> get a complete list of stacks which write to a particular
> memory location and obviously I do not want to do a ":c"
> e
> > panic[cpu1]/thread=88736740:
> > assertion failed: total_size == 0, file: ../../common/syscall/sendfile.c,
> > line: 738
> >
> > fe8001085a00 genunix:assfail+83 ()
> > fe8001085b60 genunix:sendvec_small_chunk+8ff ()
> > fe8001085eb0 genunix:sendfilev+348 ()
> >
>
> Hi,
>
> Can I have .mdbrc such that it loads necessary libraries/stab based on
> current OS revision. I mean if I run mdb on S9 machine, it should take
> the library as / .
>
> Similarly, it should choose correct library for S8/S10 if the current
> machine is S8/S10.
>
> Take it little
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Today I was trying to debug a problem with the cardbus driver in b44
> using kmdb, and I tried to set a break point using the delayed syntax
> that I recall using back in the Solaris 8 days:
>
> boot kadb -d
>
> boots and leaves me in the
> is there any way to dump on two devices or make the core
> smaller?
FYI, we do compress the core to make it smaller and reduce i/o. If you have
a huge amount of RAM or some kind of resource leak, you may need quite a
large dump device. The thing to do is to configure a dedicated dump device
> Hi experts,
> Running "echo ::fsinfo | mdb -k ", you will get
> VFSP FS MOUNT
> 018a5908 ufs /
> 06267a00 namefs
> /etc/sysevent/syseventconfd_event_channel/re...
> 0604b500 mntfs /etc/mnttab
>
> How can I get a co
>
> Hi All,
> I am trying to debug a conditional variable at this situation:
> I have a daemon running and I am trying to send a signal to it thru cv_signal
> controlled by a conditional variable. The first request I sent to it works
> fine and when it comes to the second request, I am not abl
> I need to look at the content of the lwpsinfo structure from a process core
> dump. Is there some MDB magic for that?
>
> - Alexander Kolbasov
The mdb proc target publishes some of the libproc data structures
as "xdata" (extended data buffers): you can list them using ::xdata:
> ::xdata
auxv
> John Levon wrote:
> > You know what I'm going to say ... file RFEs (but please not 'make MDB like
> > scat'). It's unfortunate that we have some divided effort on two tools that
> > do
> > essentially the same thing. 'mdb' is what's shipped with Solaris and we
> > really
> > should try and loo
> I am newbie to ctf. We applied ctfconvert/ctfmerge to our (10Gbps)networking
> driver(and the size almost doubled). Wondering if adding ctf will have any
> performance impact on the code execution path?
>
> Any doc. on what ctf actually does to the obj./bin.?
>
> TIA,
> Raghu
Great question:
> It's on Solaris 8. A core file is examined by pstack and shows that it's
> core dumped due to receiving SIGKILL. Based on my knowledge, SIGKILL can not
> be caught and ignored. The default action is just to exit. So how could it
> happen to core for SIGKILL? Bug?
>
> Thanks.
> -- Hunter
Can you
> Hi,
>
> I'm on Solaris 8. By using pfiles, I can get some info. of the open files in
> a process. pfiles on Solaris 10 will also display the filename and path. But,
> I don't know how to get it on Solaris 8. Is there any way to do it by using
> mdb? Or, is there way to retrieve the filename and
> $
> .
> void Tug::Initialize+0x28cc
> main+0x2f4
> _start+0x108
>
> >main::dis (Works as expected)
> >Tug::Initialize::dis <---(Obviously not gonna work!)
>
> What's correct syntax to disassemble Tug::Initialize?
There is no support in mdb for C++ (or any non-C language) symbols: you
> In gdb, I can use commands such as "frame 1", "frame 2" to select a
> particular stack frame, and "info locals" to print the stack variables.
>
> Are there equivalents in mdb? I've found ::stack and ::vars, but I feel
> like I'm missing something.
>
> Thanks in advance,
>
> --Wez.
Nope, yo
>
> On Mon, 6 Mar 2006, Michael Shapiro wrote:
> >
> > Hmm: as you see there is no NAME for that mapping, so this is why you're
> > not getting any symbols: we didn't match it to an object file.
> > Can you send back the entire $m output?
>
>
>
> On Mon, 6 Mar 2006, Michael Shapiro wrote:
>
> > Typically there are two reasons for seeing something like this:
> >
> > - a stripped binary or stripped loadable object
> > - a loadable object which has been dlclose()d
> >
> > Is it pos
>
> Howdy,
>
> I am trying to use findleaks to spot a memory leak in one of our
> applications. When I run "::findleaks -dv" it reports numerous
> leaks, and a stack backtrace for each leak:
>
> umem_alloc_112 leak: 94 buffers, 112 bytes each, 10528 bytes total
> ADDR BUFA
>
> core file from an apache httpd process from Solaris 9
>
> debugging core file of httpd (32-bit) from nonstop
> executable file: /usr/local/bin/httpd
> threading model: multi-threaded
> status: process terminated by SIGSEGV (Segmentation Fault)
>
> libc.so.1`_read+4: mov
> Does kmdb support source-level kernel debugging?
>
> Got out of Solaris work for quite sometime now, and just catching up,
> with the latest developments. I know earlier debuggers like kadb had
> only assembly-level kernel debugging.
Not sure what specifically you're looking for, but in genera
> I compiled a simple device driver according to Device Driver Tutorial, and
> ran the mdb like below:
>
> #mdb -k
> >dummy`_init::nm
> Value Size Type Bind Other Shndx Name
> 0xf9609c20|0x002a|FUNC|GLOB|0x0|1|dummy`_init
> >dummy`_init::bp
> mdb: failed
> One more question, I found mdb 1.0 comes with solairs 8 has very
> limited print capability for my own data structure. I also tried to
> move kernel dump from solaris 8 to 10, and use mdb 1.1 to debug it, but
> solaris 10 mdb can not recognize the dump from solaris 8. I used to use
> adbgen to
> On Fri, Aug 19, 2005 at 05:50:52PM -0700, Dan Mick wrote:
> > John Weekley wrote:
> > >No, no errors at all. That's why I kept making the same mistake.
> > >'Nother bug?
> >
> > :b is a valid command (set a breakpoint at ".").
> > :bp, :bpr, :bprfqoiuer all appear to be accepted. That seems t
> --- Jonathan Haslam wrote:
>
> > Hi Stefan,
> >
> > The ::getenv dcmd was only introduced in Solaris 10.
>
> right, thanks. That explains.
>
> I will try tomorrow to see if I'm able to extract the
> information using " the pr_envp pointer
> in the psinfo_t struct"
>
> I'm trying to figure
>
> Does anyone have any thoughts on the following [1] issue with mdb's
> memstat dcmd? For some reason the values are incorrect on machines
> with lots (64 GB in this case) of RAM.
>
> Thanks for any insight,
> - Ryan
>
> [1]
>
> >Does anyone know if there are any known issues with mdb's "::m
> Hey,
>
> Im on S10 GA and I am trying to figure out why when I fire ::memstat it takes
> 7 seconds or so to execute. The mdb's CPU consumption goes around 30%
> reported by prstat during this period.
>
> Is it ok for ::memstat to execute in a 6, 7 seconds ? My machine is:
>
> Thinkapd T23
> Pent
37 matches
Mail list logo
