similar to: 6256581 System got a hang or a panic with dtrace+kmdb

Displaying 20 results from an estimated 300 matches similar to: "6256581 System got a hang or a panic with dtrace+kmdb"

2006 Oct 31
0
4970475 There should be a stackdepth equivalent for userland
Author: ahl Repository: /hg/zfs-crypto/gate Revision: a2677fc0a5fb6895ed56fc4698646ece44978a48 Log message: 4970475 There should be a stackdepth equivalent for userland 5084954 value of dip can be incorrect in autovec 6181505 dtrace sysinfo:::modload probe does not fire when using ''modload'' 6265417 schedctl-yield isn''t listed in sdt_subr.c 6272558 gcc and dtrace
2007 Jun 07
2
plockstat/dtrace core dump S10U3
Hey, Im able to reproduce a crash from plockstat everytime Im tracing a JVM pid. I do recall a problem related with this one, but not clear if this has been fixed in U3 or is it planned for U4 ? Any BugID opened for this stack trace: > ::stack libc.so.1`strlen+0x50(100003faa, ffffffff7ffff5c8, ffffffff7eca1114, ffffffff7fffec79, 0, 100003fa9) libc.so.1`snprintf+0x88(ffffffff7ffff8f0, 0,
2005 Oct 18
2
intrstat prints incomplete interrupt statistics
> There are times when arg0 can be NULL [for the interrupt-start or > interrupt-complete probe] if there''s no associated device. > There''s already a bug open to address the error in the documentation. > 6284911 args to interrupt-start and interrupt-complete need more info Hmm, I noticed that, too. There''s currently a thread on yahoo''s solarisx86
2012 Jul 03
1
buildworld fails with clang
Hello, 9-STABLE fails to build with clang and *without* "NO_WERROR=" and "WERROR=" in /etc/make.conf. It used to work not long before : FreeBSD zozo.afpicl.lan 9.0-STABLE FreeBSD 9.0-STABLE #0 r237222M: Mon Jun 18 10:18:54 CEST 2012 root@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64 # svnversion 238067M # make NOCLEAN=yes NO_CLEAN=yes buildworld [...] ===> cddl/lib
2008 Jun 16
1
"stuck" in kmdb due to dtrace breakpoint()
So I realize this is somewhat stupid, and I''ve actually gotten myself out of kmdb to kill my dtrace script but this has happened in the past and I''m wondering if there''s any better way around it than hitting :c a bunch of times. Say you set a breakpoint() to fire in a common function. This will drop you into kmdb where you can do some debugging, you take a look around
2008 Feb 11
0
Project proposal for enhanced ustack/jstack
Hello, The Hotspot JVM Runtime group would like to put forth a project proposal to improve the capabilities of DTrace''s ustack()/jstack() actions to better handle non-standard user stack frames. This email will describe the background, the problem, and our proposed solution. We''re interested in getting a sponsor for this work to help us with the process of getting the
2006 Oct 31
0
6336683 address::queue -v blows up kmdb and mdb
Author: meem Repository: /hg/zfs-crypto/gate Revision: 4d618a4110ff44c57939c29a3a8a198be2ec8352 Log message: 6336683 address::queue -v blows up kmdb and mdb 6338969 netstrategy needs to use SIOCGLIFFLAGS and friends to see IFF_VIRTUAL 6339847 ip_rcm incorrectly parses interface names 6340643 ip_rcm is lugging around dead code 6340645 ip_rcm tracks needless phyint state Files: update:
2009 Jul 19
0
Disabling checksum offloading at OSOL DomU via kmdb at intial boot.
Disabling checksum offloading at OSOL DomU via kmdb at intial boot :- ( -kd at extra line):- root@ServerJaunty:/home/boris/nevada# xm create -c osol.install Using config file "./osol.install". Started domain osol.install (id=6)                                   Loading kmdb... Welcome to kmdb Loaded modules: [ unix krtld genunix ] [0]> ::bp xnf`_init [0]> :c v3.4.1-rc7 chgset
2009 Jul 19
5
How to disable checksum offloading for OSOL DomU via kmdb at initial boot ?
Adding -kd to extra line drops me to kmdb :- root@ServerJaunty:/home/boris/nevada# xm create -c osol.install Using config file "./osol.install". Started domain osol.install (id=4) Loading kmdb... Welcome to kmdb Loaded modules: [ unix krtld genunix ] [0]> I want patch kernel like it happens when adding to /etc/system:- set xnf:xnf_cksum_offload = 0
2006 Oct 31
0
6395902 use of USDT probes can cause plockstat and other scripts to fail
Author: ahl Repository: /hg/zfs-crypto/gate Revision: 72ce7e116da4db6c063a5c3c3f1bec23ce3ca69a Log message: 6395902 use of USDT probes can cause plockstat and other scripts to fail Files: update: usr/src/lib/libdtrace/common/dt_pid.c
2006 Oct 31
0
6370454 dtrace should support USDT probes in static functions
Author: ahl Repository: /hg/zfs-crypto/gate Revision: b1ab97f77b0ad2a4fe2a43d9c5aac7259840bb90 Log message: 6370454 dtrace should support USDT probes in static functions Files: update: usr/src/lib/libdtrace/common/dt_dof.c update: usr/src/lib/libdtrace/common/dt_link.c update: usr/src/lib/libdtrace/common/dt_provider.c update: usr/src/lib/libdtrace/common/dt_provider.h
2010 Aug 10
2
USDT probes
Hi, I''m posting a question hoping someone will know the answer off hand thereby reducing my search time. :-) With USDT probes, the tracepoint is only installed by libdtrace itself, never by the drti ioctl. So whenever I run a program with an USDT probe, no tracepoint is installed. Only after I run the dtrace command the tracepoint is actually installed on the victim process. My question
2005 Aug 23
0
Duplication in dtrace''s forceload entries in /etc/system
Hi, If you have a custom kernel (and therefore have duplicates of everything in /kernel in your custom kernel) and have noticed that when you try to use anonymous tracing, dtrace adds multiple copies of the forceload directives to /etc/system, e.g.: * vvvv Added by DTrace * * The following forceload directives were added by dtrace(1M) to allow for * tracing during boot. If these
2008 May 16
2
how can we use libdtrace within the DTrace security restrictions?
Hi all, What is the correct way to give one non-root user the ability to use DTrace with providers running in a process by another user? Through the Web Stack project and some work by Ludovic Champenois and Nasser Nouri, we have done a bit of work to bring together parts of chime, the Web Stack Apache, Ruby and PHP providers, and stuff reused from the DTrace toolkit. It''s in
2008 Nov 24
3
debugging a faulty jboss/application
>From time to time a jboss process would end eating all, the available CPU and the load avg would skyrocket. Once the operators restarted jboss, the system''d be normal again (sometimes for weeks) until the next incident Since we moved the app from a v440 running Solaris 10 8/07 to a t2000 running Solaris 10 5/08 the problem started to happen more frequently (2-3 times a week). The
2008 Jul 24
5
printa stddev error
Hi, Searched for similar errors and nothing came up. Anybody know what this is? When using aggregate stddev, and then trying to print it at END, using printa, I get this error: dtrace: processing aborted: Invalid return value from callback avg works fine. Tried on two recent builds of solaris (build 89 and build 94), on two difference sparc systems. Here''s a sample script:
2008 Jun 16
0
java stack trace using DTrace
Hi all i want to view the stack trace of the real time java application using DTrace probes. i am using jrts provider for finding the information of real time threads. In this i have used the ustack(), jstack() and this gives the following type of information libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x5e
2006 Oct 31
0
6414036 ::interrupts share_cnt can be misleading
Author: anish Repository: /hg/zfs-crypto/gate Revision: 445b09139fca7f498d4a47a7a31fc69e742dd484 Log message: 6414036 ::interrupts share_cnt can be misleading 6415576 add new options to ::interrupts for displaying intrstat like output etc. Files: update: usr/src/cmd/mdb/i86pc/modules/pcplusmp/apic.c update: usr/src/cmd/mdb/i86pc/modules/uppc/uppc.c
2006 Oct 31
0
PSARC 2006/196 DTrace Filesystem Info Provider
Author: bmc Repository: /hg/zfs-crypto/gate Revision: 7f6ac6a8f8587aa1bf748eb29f8c942583047d10 Log message: PSARC 2006/196 DTrace Filesystem Info Provider 6405662 add DTrace fsinfo provider Files: update: usr/src/lib/libdtrace/common/io.d.in update: usr/src/uts/common/dtrace/sdt_subr.c update: usr/src/uts/common/fs/vnode.c
2008 Mar 04
0
Determining curthread pointer (ulwp_t) via libproc on i386
How would I determine the address of the ulwp_t structure for the current thread of a process from a 32-bit i386 executable looking at a 32-bit executable? (This is in support of a fix for 6593259: "libdtrace should prefer pid probes to breakpoints".) For example, if I compile the following code 64-bit snippet, I can get that address from 32-bit or 64-bit executables: