dtrace fails to install probes with long names e.g., _ZL19NewArrayTryUseGroupILj4294967295EEP8JSObjectPN2js16ExclusiveContextEN2JS6HandleIPNS2_11ObjectGroupEEEmNS2_13NewObjectKindEb Steps to reproduce: 1. Build www/firefox with DTRACE=on 2. kldload dtraceall or kldload sdt 3. Start firefox 4. Check dtrace -l output Actual result: $ dtrace -l | fgrep javascript <empty> Expected result: $ dtrace -l | fgrep javascript 33327 javascript65009 js _ZN2js13ExecuteKernelEP9JSContextN2JS6HandleIP8JSScriptEER8JSObjectRKNS2_5ValueESB_NS_11ExecuteTypeENS_16AbstractFramePtrEPS9_ execute-done 33328 javascript65009 js _ZN2js13ExecuteKernelEP9JSContextN2JS6HandleIP8JSScriptEER8JSObjectRKNS2_5ValueESB_NS_11ExecuteTypeENS_16AbstractFramePtrEPS9_ execute-start 33329 javascript65009 js _ZN2js16InterpreterFrame8prologueEP9JSContext function-entry ... Bisecting first bad: https://hg.mozilla.org/mozilla-central/rev/3a994e364343
I can reproduce the issue. I see the following when starting firefox with DTRACE_DOF_INIT_DEBUG=1 set in the environment: $ DTRACE_DOF_INIT_DEBUG=1 firefox dtrace DOF libxul.so: DTrace ioctl failed for DOF at 0x8054cc4d8: Invalid argument So this is probably not an issue with the port itself. Could you confirm that this is the case for you as well?
Indeed, it happens here on 11.0-CURRENT amd64 as well. One more line is printed after firefox is closed. $ DTRACE_DOF_INIT_DEBUG=1 firefox -no-remote -profile $(mktemp -d) dtrace DOF libxul.so: DTrace ioctl failed for DOF at 0x806c6c9a8: Invalid argument dtrace DOF libxul.so: DTrace ioctl removed DOF (0)
DTrace allows the function component of a probe to be up to DTRACE_FUNCNAMELEN - 1 == 127 bytes in length and rejects DOF sections containing functions longer than that. DTRACE_FUNCNAMELEN is embedded into a few structs, so fixing this is non-trivial. Doubling it would waste at least 128 bytes per probe, of which there are typically tens of thousands, and still only pushes the problem out. It's silly that DTrace imposes this limit at all. Constraints on provider and probe name lengths make sense, and the module component is generally a filename, so a limit is reasonable. But the function component is just a symbol name, and ELF doesn't impose a limit here AFAIK. I'll try to remove the limit.
Any hope this will be fixed before 11.0?
(In reply to Jan Beich from comment #4) Yes. Sorry, I've just been very busy with work. I've spent more time looking at the code, and I think raising DTRACE_FUNCNAMELEN isn't a bad way to address the problem. I said in comment 3 that a buffer of size DTRACE_FUNCNAMELEN is created for every single probe, but this isn't right. It's only used when passing probe descriptions between userland and the kernel, for instance when running dtrace -l, or when creating an enabling. I'll look at DTrace memory usage with and without a change that doubles this constant. Assuming I haven't missed anything, the difference should not be significant. I'll also modify the DOF validation code so that we simply skip probes with excessively long function names.
A commit references this bug: Author: markj Date: Mon Apr 25 18:40:57 UTC 2016 New revision: 298589 URL: https://svnweb.freebsd.org/changeset/base/298589 Log: Allow DOF sections with excessively long probe function components. Without this change, DTrace will refuse to load a DOF section if the function component of any of its probes exceeds DTRACE_FUNCNAMELEN (128). Probes in C++ programs can have very long function components. Rather than rejecting all probes if a single probe exceeds the limit, simply skip the invalid probe and emit a warning. This ensures that valid probes are instantiated. PR: 207735 MFC after: 2 weeks Changes: head/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
A commit references this bug: Author: markj Date: Mon Apr 25 18:44:11 UTC 2016 New revision: 298590 URL: https://svnweb.freebsd.org/changeset/base/298590 Log: Increase DTRACE_FUNCNAMELEN from 128 to 192. This allows for the long function components encountered in www/firefox. This constant is part of DTrace's userland ABI, so this change may not be MFC'ed. PR: 207735 Changes: head/sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h
A commit references this bug: Author: markj Date: Mon May 9 17:13:40 UTC 2016 New revision: 299277 URL: https://svnweb.freebsd.org/changeset/base/299277 Log: MFC r298589: Allow DOF sections with excessively long probe function components. PR: 207735 Changes: _U stable/10/ stable/10/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c