Hi, William
# Sorry for un-related/un-linked reply posting,
# because I joined the list after your post
So, the question I ask to the mailing list -
is writing to kernel memory allowed in dtrace or not?
As far as I know, DTrace script can not modify any data
in kernel memory space.
So, once
Hi, Hans:
Even if you would fix your D script as mentioned by Brian,
you may see same DTrace error(invalid address .) at runtim.
If so, you may hit DTrace bug 6734858
# http://www.opensolaris.org/jive/thread.jspa?threadID=127996
The ways to avoid this problems are:
- use patched
Are the padding rules supposed to be consistent
between the compiler and
dtrace on x64?
Bug?
I think so.
Please refer my posts about this problem to dtrace-discuss and bugzilla, too !
http://www.opensolaris.org/jive/thread.jspa?threadID=127996
Hi, Bill.
I tripped over this bug recently.
Has anyone ever attempted to fix this?
Temporary name for parameter in declaration seems to prevent dtrace
from recognizing valid source as invalid.
typedef struct foo {
int f1;
} foo_t;
/* int bar(struct foo[]); = causes
Hi, Bill.
Sorry for my redundant post, if you mean attempted to fix
as a kind of source patch or fundamental workaround other
than giving temporary name to declaration.
Temporary name for parameter in declaration seems to
prevent dtrace
from recognizing valid source as invalid.
You can reporoduce problem easily by D script shown below.
struct foo { /* size: */
char f1; /* 1 */
/* 3 (padding for alignemt of f2) */
void* f2; /* 4 (for 32bit env) */
}; /* = 8 */
struct bar { /* size: */
Hi, dtracers.
Sometimes I have trouble with dtracing at complicated structure access.
DTrace seems to make mistakes at calculation of:
(1) nested structures' alignment
(2) total size of structure, which has un-aligned field at the end of it
Bugster 6734858 seems to be as same as (2) of my
