New release: v0.14 #1714
Merged
New release: v0.14 #1714
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi, thanks for preparing the release. I've ran the tests and got the following result. It looks 281 is due to timing issue, but we have to check 028 replay_backtrace test. $ ./runtest.py -dp -O0 -c gcc 028
Start 1 tests without worker pool
Compiler gc
Test case pg
------------------------: O0
t028_replay_backtrace: diff result of gcc -pg -O0
--- expect 2023-06-03 14:42:02.775607669 +0900
+++ result 2023-06-03 14:42:02.775607669 +0900
@@ -1 +1,7 @@
+ __monstartup();
+ __cxa_atexit();
+ main() {
+ alloc1() {
+ alloc2() {
+ alloc3() {
/* [ 0] main */
@@ -4,6 +10,21 @@
/* [ 3] alloc3 */
- alloc4() {
- alloc5() {
- malloc();
- } /* alloc5 */
- } /* alloc4 */
+ alloc4() {
+ alloc5() {
+ malloc();
+ } /* alloc5 */
+ } /* alloc4 */
+ } /* alloc3 */
+ } /* alloc2 */
+ } /* alloc1 */
+ free1() {
+ free2() {
+ free3() {
+ free4() {
+ free5() {
+ free();
+ } /* free5 */
+ } /* free4 */
+ } /* free3 */
+ } /* free2 */
+ } /* free1 */
+ } /* main */
028 replay_backtrace : NGThe issue is filed at #1723 |
|
Thanks for the report. I've just loaded a fix for the backtrace problem. Also I don't see the problem in the agent tests. |
|
After applying the fix, 028 is fine now. The current failed tests are as follows. It shows another agent test failures but it might be related when multiple agents running together so I think it can be ignored. It also shows a bit more random failures but they don't have to be fixed all together now. |
|
The |
|
We better run minimal 32-bit build test. |
|
And it might be better to ask @bernhardkaindl or @thepaul for basic build check for packaging before making a release. There could be some issues because we now started to support python tracing from this release. |
Build test is fine but unittest with asan complains with some memory leak reports. |
|
I just confirmed that android build is fine without a problem. |
|
In addition, we might be better to clarify if python2 tracing is supported? I haven't tested it. |
|
I've tested it and it works at least on my machine. |
|
I have the same problem as #1725 (comment). However, replace # with ''' comment like below, and it passes. |
Thanks for testing. But it's not reasonable that deleting the comment changes the result. Are you running the latest version? |
|
Yes, I run the latest version of uftrace. You're right, it's not the comment problem. I tested using Python installed on the system, not venv, it passed regardless of the comment. |
|
Note for packagers: the default library installation directory was changed to have a separate "uftrace" directory. I think it's better to have it to carry different flavors of libmcount and now python tracing module too. While uftrace should be able to find the installed library, you may want to add it to ld.so.conf or something. |
|
@MichelleJin12 thanks for your reply. I've realized that I forgot to push the related changes. Could you please test it again with the current master? Also I've updated some documents, please correct my English. :) |
|
Sure, |
|
@MichelleJin12 thanks a lot! |
This is a new release with some interesting changes!
The first thing is Python language support. Now uftrace can trace python
functions and methods like C/C++ functions. Internally, it uses python's
sys.setprofile() and pass the entry/exit info to the libmcount.
For example, it can trace the following python script (it needs to be a
standalone executable - it should have #! line and executable permission).
$ cat abc.py
#! /usr/bin/python3
def a(): b()
def b(): c()
def c(): print("Hello")
if __name__ == '__main__':
a()
$ chmod +x abc.py
Then uftrace can trace the functions like below:
$ uftrace abc.py
Hello
# DURATION TID FUNCTION
[235209] | __main__.<module>() {
[235209] | a() {
[235209] | b() {
[235209] | c() {
10.810 us [235209] | builtins.print();
14.926 us [235209] | } /* c */
16.628 us [235209] | } /* b */
18.867 us [235209] | } /* a */
22.000 us [235209] | } /* __main__.<module> */
Not all features work well with python scripts, but filters by name (-F
and -N), depth (-D), time (-t), location (-L) would work. However you
can use full features for analysis after recording the data.
The next is the improved agent control. The agent listens to a client
connection in background when started with -g option. Then users can
connect to it with uftrace live using -p <PID> option. The <PID> should
be a process ID of the target, not the uftrace itself.
Say we want to trace my program with a filter at first. Please don't
forget to start an agent.
$ uftrace record -g -F ^mycode -- myprog
Later we don't want to use the function filter anymore, and decided to use
a time filter instead. Let's change the option for the uftrace record
like below:
$ uftrace -p $(pidof myprog) -F ^mycode@clear -t 100us
Note that the above command would not produce any data and just pass the
new options to the existing uftrace record session (for myprog).
One more big thing is Android build support. While it's not officially
supported, you can build uftrace as an external tool. This needed various
improvements in terms of portability like abstracting shmem access and
better handling of the tmp directory and dynamic linker behaviors.
It has been tested with Android 9+ on AArch64 and x86_64. You probably
want to use dynamic tracing due to issues with the Android runtime.
Please see INSTALL.md for the details.
The size filter at replay now works as same as record, since the symbol
file format was changed to save the symbol size as well.
Symbol demangling on Rust programs was improved to handle trait names in a
more compact way. The new demangling scheme (v0) is not supported yet.
There are also more fixes and improvements. Thank you contributors!
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's time for a new release. Please test and report any issues!
In this development cycle, we've seen many interesting changes including:
And of course, a lot more fixes and improvements are there as well. Thanks for all the contributors.