[Bug 219451] [dtrace] Certain llquantize() parameters trigger assertion
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon May 22 09:46:18 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219451
Bug ID: 219451
Summary: [dtrace] Certain llquantize() parameters trigger
assertion
Product: Base System
Version: 11.0-STABLE
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: fk at fabiankeil.de
CC: freebsd-dtrace at FreeBSD.org
Created attachment 182796
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=182796&action=edit
libdtrace: Prevent an assertion from triggering with certain llquantize()
parameters
On a system based on r318579/0c33b79a4 the following dtrace command reliably
triggers an
assertion when printing output:
fk at t520 ~ $sudo dtrace -n 'syscall::read:return /execname ==
"privoxy"/ { @[execname] = llquantize(arg0, 100, 0, 10, 100); @m = max(arg0)}'
[...]
9800 | 0
9900 | 0
10000 |@@@@@@@@@@@@@@@@@@@@ 37
20000 | 0
Assertion failed: (value < next), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c,
line 1083.
Abort trap
(gdb) where
#0 0x00000008011effda in thr_kill () from /lib/libc.so.7
#1 0x00000008011effa4 in __raise (s=6) at
/usr/src/lib/libc/gen/raise.c:52
#2 0x00000008011eff19 in abort () at
/usr/src/lib/libc/stdlib/abort.c:65
#3 0x000000080088c3b2 in __assert (expr=0x8008d3172 "value < next",
file=0x8008d3078
"/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c",
line=1083)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include/assert.h:56
#4 0x000000080088c190 in dt_print_llquantize (dtp=0x802633000,
fp=0x8014c37e8, addr=0x80269a110, size=7840, normal=1) at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume
.c:1083
#5 0x000000080088e37d in dt_print_datum (dtp=0x802633000,
fp=0x8014c37e8, rec=0x8026900e8, addr=0x80269a110 "d", size=7848,
aggdata=0x802690150, normal=1, pd=0x7fffffffe750)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c:2211
#6 0x000000080088dc12 in dt_print_aggs (aggsdata=0x7fffffffe630,
naggvars=1, arg=0x7fffffffe750) at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c:2313
#7 0x000000080088e6cf in dt_print_agg (aggdata=0x802690150,
arg=0x7fffffffe750) at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c:2361
#8 0x0000000800895f8b in dt_aggregate_walk_sorted (dtp=0x802633000,
func=0x80088e610 <dt_print_agg>, arg=0x7fffffffe750, sfunc=0x0)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_aggregate.c:1585
#9 0x0000000800895d39 in dtrace_aggregate_walk_sorted
(dtp=0x802633000, func=0x80088e610 <dt_print_agg>, arg=0x7fffffffe750)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_aggregate.c:1605
#10 0x0000000800897f12 in dtrace_aggregate_print (dtp=0x802633000,
fp=0x8014c37e8, func=0x800895d10 <dtrace_aggregate_walk_sorted>)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_aggregate.c:2130
#11 0x0000000000403a5e in main (argc=<optimized out>, argv=<optimized
out>) at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:2005
(gdb) f 4
#4 0x000000080088c190 in dt_print_llquantize (dtp=0x802633000,
fp=0x8014c37e8, addr=0x80269a110, size=7840, normal=1) at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume
.c:1083
1083 assert(value < next);
(gdb) p step
$2915 = 77662796314522419
(gdb) p value
$2916 = 7834326075677972872
(gdb) p next
$2917 = 7766279631452241920
It works as expected when replacing the 10 with a 5.
Various other parameter combinations work as expected as well and I've used
similar commands for weeks without issues.
The problem is reproducible with other execnames as long as the probe fires.
The "@m = max(arg0)" part isn't required to trigger the assertion but I only
noticed it
after already patching the system where libdtrace is build with reduced
optimizations.
The attached patch prevents the assertion from triggering but may not be the
best solution.
The code flow in dt_print_llquantize() seems strange to me and maybe the
loop should break if "bin" reaches "last_bin" instead. My impression is that
it does a bunch of cycles at the end without doing meaningful work.
Obtained from: ElectroBSD
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list