[mdb-discuss] spurious mdb stops in sigacthandler when debugging b117 Xorg ?

2009-07-05 Thread Jürgen Keil
I'm trying to debug an Xorg mouse problem in b116 or newer, on 32-bit x86.
The problem is that under unknown conditions the mouse pointer jumps to 
the upper left screen corner.
( http://www.opensolaris.org/jive/thread.jspa?threadID=105715tstart=0 )


Unfortunately, when I recompile Xorg from source and run that, the problem
disappears. So that adding printfs to Xorg, or trying to compile Xorg binaries
with certain changesets removed can't be used to narrow down the problem.


For that reason I'm now trying to debug the problem with mdb using the original
b116 / b117 Xorg 32-bit binary.  The idea was to set a conditional mdb write
access breakpoint on the mouse driver's y coordinate, that triggers only in
case y was changed to a value of 0:

# mdb -p `pgrep -x Xorg`
Loading modules: [ ld.so.1 libproc.so.1 libnvpair.so.1 libuutil.so.1 
libavl.so.1 ]
 GetPointerEvents+113/i
GetPointerEvents+0x113: movl   %ecx,-0x20(%ebp)
 :b
 :c
mdb: stop at GetPointerEvents+0x113
mdb: target stopped at:
GetPointerEvents+0x113: movl   %ecx,-0x20(%ebp)
 eax=X
86f5998 

At this point, %eax contains a pointer to the mouse driver's
state structure, and offset 0xf8 in that structure is the current
x coordinate, and offset 0xfc is the y coordinate.

The following should set a conditional write access breakpoint,
that stops only when y has been changed to 0:

 0x86f5998+0xfc::wp -w -L 4 -c ,*(0x86f5998+0xfc)!=0:c
 :c
mdb: stop at GetPointerEvents+0x113
mdb: target stopped at:
GetPointerEvents+0x113: movl   %ecx,-0x20(%ebp)
 $b
   ID S TA HT LM Description  Action   
- - -- -- --  --
[ 1 ] + T   0  0 stop on SIGINT   -
[ 2 ] + T   0  0 stop on SIGQUIT  -
[ 3 ] + T   0  0 stop on SIGILL   -
[ 4 ] + T   0  0 stop on SIGTRAP  -
[ 5 ] + T   0  0 stop on SIGABRT  -
[ 6 ] + T   0  0 stop on SIGEMT   -
[ 7 ] + T   0  0 stop on SIGFPE   -
[ 8 ] + T   0  0 stop on SIGBUS   -
[ 9 ] + T   0  0 stop on SIGSEGV  -
[ 10] + T   0  0 stop on SIGSYS   -
[ 11] + T   0  0 stop on SIGXCPU  -
[ 12] + T   0  0 stop on SIGXFSZ  -
 13 + 2  0 stop at GetPointerEvents+0x113   -
[ 14] + 2  0 stop on write of [0x86f5a94, 0x86f5a98)  ,*(0x86f5998+0xfc ...
 ::delete 13
 :c

   ... Xorg is running for some time ...

mdb: target stopped at:
libc_hwcap1.so.1`sigacthandler+1:   movl   %esp,%ebp
 0x86f5998+0xf8/XX
0x86f5a90:  274 36d 


Now this is something I don't understand and looks like a mdb bug:
After some time using the mouse in Xorg we do stop in mdb, but
the y value didn't change to 0 ?

Seems we didn't stop because of the write access breakpoint.
But why did we stop?

 $C
08047758 libc_hwcap1.so.1`sigacthandler+1(86f5768)
08047788 xf86SigioReadInput+0x2f(15, 86f5768, 8047858, 80dfe15)
08047858 xf86SIGIO+0x1a9(16, 0, 8047920)
0804786c libc_hwcap1.so.1`__sighndlr+0xf(16, 0, 8047920, 80dfdf8)
080478dc libc_hwcap1.so.1`call_user_handler+0x2af(16)
0804790c libc_hwcap1.so.1`sigacthandler+0xdf(16, 0, 8047920)
08047b38 SecurityLookupIDByType+0xe(878cc00, 1600286, 3, 20)
08047b58 dixLookupGC+0x22(8047b7c, 1600286, 878cc00, 20)
08047b98 ProcChangeGC+0x37(878cc00, 38)
08047c28 Dispatch+0x44f(840a418, 840a41c, 8409930, 840a8b8, 840a8ec, 820694c)
08047d18 main+0x605(9, 8047d50, 8047d78, 8047d0c)
08047d44 _start+0x7d(9, 8047e20, 8047e32, 8047e35, 8047e3f, 8047e43)
 ::status
debugging PID 950 (32-bit)
file: /usr/X11/bin/i386/Xorg
threading model: native threads
status: stopped after a single-step
 $b
   ID S TA HT LM Description  Action   
- - -- -- --  --
[ 1 ] + T   0  0 stop on SIGINT   -
[ 2 ] + T   0  0 stop on SIGQUIT  -
[ 3 ] + T   0  0 stop on SIGILL   -
[ 4 ] + T   0  0 stop on SIGTRAP  -
[ 5 ] + T   0  0 stop on SIGABRT  -
[ 6 ] + T   0  0 stop on SIGEMT   -
[ 7 ] + T   0  0 stop on SIGFPE   -
[ 8 ] + T   0  0 stop on SIGBUS   -
[ 9 ] + T   0  0 stop on SIGSEGV  - 

[mdb-discuss] kmdb amd64: parameters not shown in stack backtraces ?

2008-10-15 Thread Jürgen Keil
I'm not exactly sure when it happened (somewhere between snv_98
and snv_100), but starting a couple of weeks ago kmdb appears to
have lost the ability to display parameter values in stack backtraces
on the amd64 platform.

E.g. on an old build 82 or wiith an opensolaris snv_97 livecd,
mdb -k / kmdb was able to show a stack backtrace like this:

 ::pgrep init | ::walk thread | ::findstack -v
stack pointer for thread ff01c9373b20: ff0007b6fc00
[ ff0007b6fc00 _resume_from_idle+0xf1() ]
  ff0007b6fc40 swtch+0x17f()
  ff0007b6fcd0 cv_timedwait_sig+0x194(ff01c939663a, ff01c9396600, 
719e2)
  ff0007b6fd60 cv_waituntil_sig+0xbb(ff01c939663a, ff01c9396600, 
ff0007b6fe80, 2)
  ff0007b6fe40 poll_common+0x3dd(806b500, 1, ff0007b6fe80, 0)
  ff0007b6fec0 pollsys+0xec(806b500, 1, 80475f8, 0)
  ff0007b6ff10 sys_syscall32+0x101()


But with snv_100 or newer, all I get is this:

 ::pgrep init | ::walk thread | ::findstack -v
stack pointer for thread ff02d38dbb20: ff000f917c50
[ ff000f917c50 _resume_from_idle+0xf1() ]
  ff000f917c80 swtch+0x160()
  ff000f917cf0 cv_timedwait_sig+0x1c0()
  ff000f917d60 cv_waituntil_sig+0xb0()
  ff000f917e40 poll_common+0x465()
  ff000f917ec0 pollsys+0xe8()
  ff000f917f10 sys_syscall32+0x101()


Is it possible that the switch to the studio 12 compiler
did break this kmdb  feature?
--
This message posted from opensolaris.org



[mdb-discuss] kmdb amd64: parameters not shown in stack backtraces ?

2008-10-15 Thread Jürgen Keil
James C. McPherson wrote:

 J?rgen Keil wrote:
  ... starting a couple of weeks ago kmdb appears to
  have lost the ability to display parameter values in stack backtraces
  on the amd64 platform.

 Yes, and it was noticed starting with daily.0925.
 
 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6753543
 6753543 is_argsaved() needs to be augmented for SS12

Oh, somehow I missed 6753543 when I tried to find
an existing bug report for this problem...


 This is one of the fixes that's gone into the new compilers,

Ok, I expected something like that, that the compiler
is using a different code sequence to save the parameters...


 I'm not sure whether the patch (-08, iirc)
 is available on sunsolve yet. I don't know whether the
 tarball via opensolaris.org has been updated either,
 sorry.

Hmm, as far as I can tell, a studio 12 compiler tarball
is not yet available for download from the opensolaris
web site.  I'm using the studio 12 compiler that was
included with one the SX:CE 9x release (build 91?).

I just checked the web pages bwlow and they tell me that
patch 124868-06 is needed for the (x86) C 5.9 compiler;
the latest version of that patch from sunsolve is -07
(release two days ago) and according to the description
text doesn't seem to fix this problem;
-08 is not yet available

  http://www.opensolaris.org/os/downloads/on/
  
http://www.opensolaris.org/os/community/tools/sun_studio_tools/sun_studio_12_tools/


  --

Sun Studio 12 Compilers and Tools for OpenSolaris Developers!

Starting with Build 100, you must use the Sun Studio 12 compiler plus a 
specific set of patches to build ON.

* The Sun Studio 12 compiler can be obtained from:

http://developers.sun.com/sunstudio/downloads/index.jsp

You must choose the package installer to download, and if you want to do a 
custom install, you must be sure to include PerfLib.

* You must also download and apply the following critical patches:

SPARC:

124867-07: Sun Studio 12: Patch for C 5.9 compiler

124863-07: Sun Studio 12: Patch for Sun C++ Compiler

124861-08: Sun Studio 12: Compiler Common patch for Sun C C++ F77 F95

x86:

124868-06: Sun Studio 12x86: Patch for C 5.9 compiler

124864-07: Sun Studio 12x86: Patch for Sun C++ Compiler

126498-09: Sun Studio 12_x86: Sun Compiler Common patch for x86 backend

These can be obtained from:

http://sunsolve.sun.com/show.do?target=patchpage

A tarball containing an install image of Sun Studio 12 with appropriate patches 
is being created and will be posted soon.
--
This message posted from opensolaris.org



[mdb-discuss] mdb wraps lines at 80 characters when input is redirected

2008-12-08 Thread Jürgen Keil
 echo ::findleaks -v -d  | mdb -p $pid | c++filt
 
 However, it does not work: it seems that when mdb input is redirected, 
 it wraps lines at 80 characters and C++ names are not demangled 
 correctly.

Does setting the output width with the $w command work?

   echo '300$w ; ::findleaks -v -d' | mdb ...
-- 
This message posted from opensolaris.org



[mdb-discuss] build 38: mdb disassembler broken / segfaults

2006-04-10 Thread Jürgen Keil
Is the following a known bug?

On a 32-bit x86 platform, running on-20060404 bits, mdb segfaults, like this:

$ mdb /bin/date
 main:b
 :r
mdb: stop at main
mdb: target stopped at:
main:   pushl  %ebp
 puts:b
 :c
mdb: stop at libc.so.1`puts
mdb: target stopped at:
libc.so.1`puts: pushl  %ebp
 puts?i
libc.so.1`puts:
Segmentation Fault - core dumped



$ pstack core
core 'core' of 1033:mdb /bin/date
 ce5a44a2 memcpy   (80456b4, ce74fac0, 0, 804558c, 1) + 22
 ce66115a get_byte (80d3ac8) + 32
 ce661545 dtrace_get_SIB (80d3adc, 8045618, 8045650, 804564c) + 2a
 ce6615c3 dtrace_get_modrm (80d3adc, 8045618, 8045650, 804564c) + 3a
 ce663e5e dtrace_disx86 (80d3adc, 2) + 204e
 ce6612cc dis_disassemble (80d3ac8, ce74fabf, 0, 8045780, 400) + 3d
 08066853 libdisasm_ins2str (80d2fa8, 80dfeb0, fffd, 8045780, 400, 
ce74fabf) + 50
 0806659e mdb_dis_ins2str (80d2fa8, 80dfeb0, fffd, 8045780, 400, ce74fabf) 
+ 24
 08069f0d fmt_instr (80dfeb0, fffd, ce74fabf, 0, 1) + 4e
 0806a250 mdb_fmt_print (80dfeb0, fffd, ce74fabf, 0, 1, 69) + 55
 080609e1 print_arglist (fffd, ce74fabf, 0, 1, 1, 80d69b8) + 1f8
 08060aee print_common (fffd, 1, 1, 80d69b8, 805e45c, 10) + 9d
 08060b28 cmd_print_object (ce74fabf, 1, 1, 80d69b8) + 16
 0805e47a dcmd_invoke (80cc2e0, ce74fabf, 1, 1, 80d69b8, 0) + 53
 0805e63e mdb_call_idcmd (80cc2e0, ce74fabf, 0, 1, 0, 1) + 111
 0805e07b mdb_call (ce74fabf, 0, 1, 0, 1, 8046334) + 2d3
 0808e423 yyparse  (8046bbc, 8099450, 8046c7c, 8046300, 80b1b20, 0) + a4b
 0805db9b mdb_run  (8047280, 0, 0, 7273752f, 8047214, 80470ac) + 266
 08075449 main (2, 80470f0, 80470fc) + f29
 0805ae0e  (2, 804727c, 8047280, 0, 804728a, 804729c)
 
 
This message posted from opensolaris.org



[mdb-discuss] mdb :r command corrupts arguments for 64 bit x86 debug target

2010-02-06 Thread Jürgen Keil
Can anyone reproduce this:

I'm running SX:CE b129 amd64, bfu'ed to current ON bits;
the same problem exists on OpenSolaris dev build b132.

I'm trying to debug a /usr/sbin/amd64/update_drv problem,
using mdb.  Problem is that the debug target somehow
receives a :r quoted string argument slightly modified.

Here's an example that reproduces the issue with
a 64-bit echo test program:

% cat x.c
#include stdio.h

int
main(int argc, char **argv)
{
int i;
for (i = 1; argv[i] != NULL; i++)
printf(%s , argv[i]);
printf(\n);
return 0;
}

% cc -m64 -o x x.c

% ./x -d -i 'pci1814,601' rtls
-d -i pci1814,601 rtls 

Ok, test program works as expected.
Now the same under mdb control:

% mdb ./x
 :r -d -i 'pci1814,601' rtls
-d -i pci1144,601 rtls 
mdb: target has terminated


Note how the pci1814,601 string
argument was modified when running
under mdb.

The problem does not happen with a
32-bit debug target.
-- 
This message posted from opensolaris.org