Comments (49)
iipeace
commented on June 3, 2024
could you explain more detailed examples that you imagine?
from guider.
elfring
commented on June 3, 2024
I became especially interested in efficient and safe analyses for function executions.
I guess that other trace reports would be similarly affected.
(Will the software documentation be improved accordingly?)
👀 I am looking for ways to combine available information (from some lines) into rows for further data processing approaches.
from guider.
iipeace
commented on June 3, 2024
Please share detailed output examples :)
from guider.
elfring
commented on June 3, 2024
I suggest to take another look at analysis examples which you published already.
from guider.
iipeace
commented on June 3, 2024
I guess that you wanna get a line including both function entry and return info.
Is it right?
from guider.
elfring
commented on June 3, 2024
Yes (for another concrete use case)
from guider.
iipeace
commented on June 3, 2024
What do you think about this?
It will only print return context.
# ./guider.py btrace yes -c "|filter:RETVAL:BT:0"
from guider.
elfring
commented on June 3, 2024
Such a functionality can occasionally be also useful.
I hope that the software documentation will be improved.
But it is obvious that the mentioned filter example does not combine discussed data items, isn't it?
from guider.
iipeace
commented on June 3, 2024
Yes, it doesn't combine function entry info.
But the combined output will not displayed until the target function call is finished(return). is it okay?
from guider.
iipeace
commented on June 3, 2024
What do you think about this output?
0.035559 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000021 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.035842 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000021 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.037240 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000023 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.046022 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000021 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.052150 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000023 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.082249 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000022 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.088081 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000023 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
from guider.
elfring
commented on June 3, 2024
But the combined output will not displayed until the target function call is finished(return). is it okay?
Yes ‒ for a configured software analysis variant (as proposed).
from guider.
elfring
commented on June 3, 2024
What do you think about this output?
The display looks promising.
I would like to know more about the data items which are provided in such rows.
from guider.
iipeace
commented on June 3, 2024
You can check a new feature with a below command.
$ ./guider.py btrace yes -c "write|getret" -q completecall
0.037839 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037859 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037879 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037900 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037920 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037940 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037960 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037980 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
'''
from guider.
elfring
commented on June 3, 2024
Thanks for another positive feedback.
👀 I am still looking for corresponding extensions according to the software documentation.
from guider.
elfring
commented on June 3, 2024
I tried one of my small test programs out once more.
[Markus_Elfring@fedora guider]$ ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c 'statvfs64|getret' -q completecall
… ver_3.9.8_211002 on python_3.9
…
"2 20:00:02.327" Determining file system: "/home/Markus_Elfring/gui_rpc_auth.cfg"
"2 20:00:02.368" | "Data determination by setPath()" | 5730828 |ns
"2 20:00:02.371" type name: "ext4"
1.878231 +++ exited QStorageInfo-se(72007) with 0 +++
Now I am missing the analysis data output according to your software update.
from guider.
iipeace
commented on June 3, 2024
is it okay without -q option?
could you share your program binary?
from guider.
elfring
commented on June 3, 2024
is it okay without -q option?
No, not yet.
could you share your program binary?
The access to my executable file might not be directly needed for further test runs.
I imagine that it will be more helpful to check if the tool “guider” will be able to provide analysis data also for calls of the function “statvfs64”.
Other test programs can eventually help to clarify unexpected software behaviour better than my local file variants.
Otherwise:
🔮 Would you like to construct a Qt console application where you would use a function implementation like the following?
void Task::call_API(QStorageInfo& info, QString const & input)
{
l_t x(QStringLiteral("Data determination by setPath()"));
info.setPath(input);
}from guider.
elfring
commented on June 3, 2024
How will analysis data evolve together with Python programming interfaces like “os.statvfs(path)” (as another application example)? 🤔
Would you like to add any unit test cases accordingly?
from guider.
iipeace
commented on June 3, 2024
I tested on my PC using a below command.
root@osdc:/home/peacelee/guider/guider# ./guider.py btrace "python -c \"import os;os.statvfs('.')\"" -c "statvfs*|getret"
...
0.055871 statvfs@GLIBC_2.2.5/0x7f3773652bd0(0x7f37730464d0,0x7ffdbdb5ead0,0x0,0x4134e3,0x0,0x38) [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
0.055882 statvfs@GLIBC_2.2.5[RET]=0x0(0)/0.000012 -> 0x45e6e8/0x400000 [/usr/bin/python3.8]
0.058732 +++ exited python(1282301) with 0 +++
root@osdc:/home/peacelee/guider/guider# ./guider.py btrace "python -c \"import os;os.statvfs('.')\"" -c "statvfs*|getret" -q completecall
...
0.055787 statvfs@GLIBC_2.2.5(0x7fa1344f64d0,0x7ffec405e320,0x0,0x4134e3,0x0,0x38)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x0(0)/0.000010 -
0.058247 +++ exited python(1282306) with 0 +++
What do you think about this?
from guider.
elfring
commented on June 3, 2024
- Both Python command examples succeeded also on my system (in principle).
I wonder why the output was truncated for the combined analysis data by such test runs.
Should any line length limitations be accordingly reconsidered? - How will the situation be clarified further for the usage of the function “statvfs64” (by C++ programming interfaces)?
from guider.
iipeace
commented on June 3, 2024
Both Python command examples succeeded also on my system (in principle).
I wonder why the output was truncated for the combined analysis data by such test runs.
Should any line length limitations be accordingly reconsidered?
You can use -q option such below commands.
$ ./guider.py btrace "ls" -q nocut
$ ./guider.py btrace "ls" -c "*|getret" -q completecall, nocut
How will the situation be clarified further for the usage of the function “statvfs64” (by C++ programming interfaces)?
I wonder your test program called statvfs64 really?
https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/statvfs.2.html
The field f_size contains the size of file system in f_frsize units.
Note that this field is not part of the standard POSIX definition of statvfs.
When a 32-bit application uses statvfs64() with a large file system,
f_size will top out at MAXINT, rather than return an EOVERFLOW error.
Use f_blocks instead. https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/statvfs.2.html
from guider.
elfring
commented on June 3, 2024
./guider.py btrace "ls" -c "*|getret" -q completecall, nocut
Should data truncation be avoided by default?
I wonder your test program called statvfs64 really?
It is used also by the function “QStorageInfoPrivate::retrieveVolumeInfo” for example.
How do you think about to compare test results with any data from other available analysis tools?
Example:
[Markus_Elfring@fedora ~]$ uftrace --data=Test/QStorageInfo-setPath/Probe-uftrace report --filter=statvfs64
Total time Self time Calls Function
========== ========== ========== ====================
5.585 ms 5.585 ms 1 __x64_sys_exit_group
9.565 us 1.711 us 1 statvfs64
7.440 us 7.440 us 1 __x64_sys_statfs
0.209 us 0.209 us 1 exit_to_user_mode_prepare
0.205 us 0.205 us 1 syscall_exit_to_user_mode_prepare
from guider.
iipeace
commented on June 3, 2024
I can't build Qt program ;(
Could you share your program binary built statically.
did you get the result of uftrace today?
just statvfs can be called if QT_LARGEFILE_SUPPORT is not defined.
# if defined(QT_LARGEFILE_SUPPORT)
--
# define QT_STATFSBUF struct statvfs64
# define QT_STATFS ::statvfs64
# else
# define QT_STATFSBUF struct statvfs
# define QT_STATFS ::statvfs
# endif // QT_LARGEFILE_SUPPORT
please use a below option.
-c "statvfs*|getret"
from guider.
elfring
commented on June 3, 2024
I can't build Qt program
It seems that the software distribution dependencies can become more challenging then.
May I dare to “teach” you any further possibilities (by video conferences)?
Could you share your program binary?
I can eventually offer my executable file (1 MiB with debug data) as a compressed attachment for a private mail.
I am unsure if it will run in your test environment because of referenced shared library versions.
did you get the result of uftrace today?
I can refresh selected analysis data on demand.
just statvfs can be called if QT_LARGEFILE_SUPPORT is not defined.
I would like to benefit from the support of large files (also by Qt interfaces).
please use a below option.
[Markus_Elfring@fedora guider]$ ./guider.py btrace "python -c \"import os;os.statvfs('.')\"" -c 'statvfs*|getret' -q completecall,nocut
… ver_3.9.8_211002 on python_3.9
…
0.480995 statvfs@GLIBC_2.2.5(0x7fef265f7e90,0x7ffffcb638a0,0x0,0x0,0x0,0x556cd2847180)[/usr/lib64/libc-2.33.so]=0x0(0)/0.000012 -> 0x1fffa0/0x7fef33f80000 [/usr/lib64/libpython3.9.so.1.0]
0.497781 +++ exited python(13386) with 0 +++
Is another test result interesting?
[Markus_Elfring@fedora guider]$ ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c 'statvfs*|getret' -q completecall,nocut
…
1.798169 statvfs@GLIBC_2.2.5(0x7fe92530f2b7,0x7ffe789e0780,0x0,0x7fe925db2ac0,0x1bb2630,0x0)[/usr/lib64/libc-2.33.so]=0x0(0)/0.000112 -> 0x7110/0x7fe9252ef000 [/usr/lib64/libselinux.so.1]"3 15:32:53.876" Determining file system: "/home/Markus_Elfring/gui_rpc_auth.cfg"
1.824860 statvfs@GLIBC_2.2.5(0x1bcf3b8,0x7ffe789e01b0,0x1bcf3a0,0xa,0x1bd0732,0x0)[/usr/lib64/libc-2.33.so]=0x0(0)/0.000049 -> 0x255670/0x7fe92618b000 [/usr/lib64/libQt5Core.so.5.15.2]"3 15:32:53.918" | "Data determination by setPath()" | 8085252 |ns
"3 15:32:53.922" type name: "ext4"
1.834711 +++ exited QStorageInfo-se(13775) with 0 +++
May I expect the output of line breaks for data rows?
from guider.
iipeace
commented on June 3, 2024
I think I can't use your dynamic built binary in my system ;)
I guess the second statvfs() call in your last test result is it that you expected as statvfs64().
May I expect the output of line breaks for data rows?
is it right as default option?
if -q NOCUT option is default then the terminal will be getting little bit dirty.
from guider.
elfring
commented on June 3, 2024
I guess the second statvfs() call in your last test result is it that you expected as statvfs64().
- How do you think about to clarify the algorithm for the lookup and checking of function names?
- Would you take any aliases into account?
if -q NOCUT option is default then the terminal will be getting little bit dirty.
- Our understanding of desirable software behaviour is occasionally different, isn't it?
- I am looking for clearer separation of data output even if text lines would be “mixed” from the parallel program execution.
from guider.
iipeace
commented on June 3, 2024
How do you think about to clarify the algorithm for the lookup and checking of function names?
I found that stavfs and statvfs64 have WEEK symbols and are sharing the same address.
I need to study about this :)
root@osdc:/home/peacelee/guider/guider# readelf -a /usr/lib/x86_64-linux-gnu/libc.so.6 | grep statvfs
288: 0000000000110bd0 116 FUNC WEAK DEFAULT 16 statvfs64@@GLIBC_2.2.5
648: 0000000000110bd0 116 FUNC WEAK DEFAULT 16 statvfs@@GLIBC_2.2.5
718: 0000000000110c50 108 FUNC WEAK DEFAULT 16 fstatvfs@@GLIBC_2.2.5
1633: 0000000000110c50 108 FUNC WEAK DEFAULT 16 fstatvfs64@@GLIBC_2.2.5
I am looking for clearer separation of data output even if text lines would be “mixed” from the parallel program execution.
I agree with this.
Using "-o" option will make Guider to save it's all output to the specific per-task file without any strip.
isn't it enough?
from guider.
elfring
commented on June 3, 2024
I need to study about this
I am curious on further collateral evolution.
isn't it enough?
I became curious also about the order for writing line breaks for data rows.
from guider.
iipeace
commented on June 3, 2024
I am curious on further collateral evolution.
There is no difference between statvfs() and statvfs64() in my x86_64 system.
Have you tested it on 32bit system?
I became curious also about the order for writing line breaks for data rows.
- check the length of a string line when printing.
- It will be cut if only it is longer than the width of terminal except when output file is set.
from guider.
elfring
commented on June 3, 2024
There is no difference between statvfs() and statvfs64() in my x86_64 system.
- I hope that further software analyses will become supported for both function names.
- Would you like to check consequences any more for aliases?
Have you tested it on 32bit system?
I find that this technical detail should not matter for the desired clarification at the moment (also according to a function call report by the tool “uftrace”).
It will be cut if only it is longer than the width of terminal except when output file is set.
- I propose to reconsider case distinctions for data truncation.
- Will each data row be written with a line break at the end?
- Are file flushes applied here?
- Will any improvements help for the involved software documentation?
from guider.
iipeace
commented on June 3, 2024
I hope that further software analyses will become supported for both function names.
Wha do you think about this?
# ./guider.py btrace "python -c \"import os;os.statvfs('.')\"" -c "statvfs*|getret" -q allsym
...................
0.044599 statvfs64@GLIBC_2.2.5/statvfs@GLIBC_2.2.5/0x7f140c0dcbd0(0x7f140bad04d0,0x7fffd9d4f060,0x0,0x4134e3,0x0,0x38) [/usr/lib/x86_64-linux-g
0.044610 statvfs64@GLIBC_2.2.5/statvfs@GLIBC_2.2.5[RET]=0x0(0)/0.000011 -> 0x63b6a0/0x400000 [/usr/bin/python3.8]
0.047176 +++ exited python(1293801) with 0 +++
from guider.
elfring
commented on June 3, 2024
Another software extension can eventually be helpful.
Your test display looks promising (in principle).
Further considerations:
- Data truncation is presented once more.
- Can the asterisk be omitted from the shown filter specification?
- I do not see the expected output for my command example.
[Markus_Elfring@fedora guider]$ ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c 'statvfs*|getret' -q completecall,nocut,allsym … ver_3.9.8_211006 on python_3.9 … "6 18:20:17.028" Determining file system: "/home/Markus_Elfring/gui_rpc_auth.cfg" "6 18:20:17.069" | "Data determination by setPath()" | 6353325 |ns "6 18:20:17.073" type name: "ext4" 2.039042 +++ exited QStorageInfo-se(6329) with 0 +++
from guider.
iipeace
commented on June 3, 2024
Data truncation is presented once more.
yes, because I didn't use "-q nocut" option.
Can the asterisk be omitted from the shown filter specification?
sure.
I do not see the expected output for my command example.
Could you test below commands?
# rm /var/log/guider/*
# ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c 'statvfs*'
from guider.
elfring
commented on June 3, 2024
Wha do you think about this?
I do not see your output example also on another test system so far.
Markus_Elfring@bw-wst-linux1:~/Aktivitäten/guider/lokal/guider> python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c 'statvfs*|getret' -q allsym
… ver_3.9.8_211006 on python_3.8
…
[INFO] load /usr/lib64/libm.so.6... [done]
0.053185 +++ exited python3(9359) with 0 +++
Would you like to check any implementation details a bit more for the evolving software components?
from guider.
iipeace
commented on June 3, 2024
Could you test below commands?
# rm /var/log/guider/*
# ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c 'statvfs*'
It's very strange because I got this results from my PC.
# python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c 'statvfs*|getret' -q allsym
0.054027 statvfs64@GLIBC_2.2.5/statvfs@GLIBC_2.2.5/0x7fc02b422bd0(0x7fc02ae164d0,0x7ffdbb3bc060,0x0,0x4134e3,0x0,0x38) [/usr/lib/x86_64-linux-g
0.054037 statvfs64@GLIBC_2.2.5/statvfs@GLIBC_2.2.5[RET]=0x0(0)/0.000010 -> 0x63b6a0/0x400000 [/usr/bin/python3.8]
0.056542 +++ exited python3(2931) with 0 +++
from guider.
elfring
commented on June 3, 2024
It's very strange because I got this results from my PC.
Are the different test results becoming more interesting for the clarification of desirable software behaviour?
from guider.
iipeace
commented on June 3, 2024
Are the different test results becoming more interesting for the clarification of desirable software behaviour?
Please run commands I requested.
I want to know more environment characteristics.
from guider.
elfring
commented on June 3, 2024
I want to know more environment characteristics.
Which algorithm is applied for the handling of mentioned function names (and their aliases) at the moment?
from guider.
iipeace
commented on June 3, 2024
Which algorithm is applied for the handling of mentioned function names (and their aliases) at the moment?
That is simple.
Some symbols share a same address,
So I had used representative symbol among them,
I added merge option "-q ALLSYM' to concatenate all them.
So I ask you to run a below command.
# python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c "*statvfs*"
from guider.
elfring
commented on June 3, 2024
…,
So I had used representative symbol among them,
I added merge option "-q ALLSYM' to concatenate all them.
I find that such information will need further explanation.
So I ask you to run a below command.
Markus_Elfring@bw-wst-linux1:~/Aktivitäten/guider/lokal/guider> python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c '*statvfs*'
… ver_3.9.8_211006 on python_3.8
…
[INFO] load /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so... [done]
0.038945 statvfs@GLIBC_2.2.5/0x7fb3b8e6a0c0(0x7fb3b8b95f80,0x7ffe0e58fb40,0x0,0x7fb3b8d7a3e8,0x0,0x0) [/usr/lib64/libc.so.6]
0.038950 __internal_statvfs64/0x7fb3b8e6f1c0(0x7ffe0e58fb40,0x7ffe0e58fa50,0x0,0x7fb3b8d7a3e8,0x0,0x0) [/usr/lib64/libc.so.6]
0.041606 +++ exited python3(11357) with 0 +++
🔮 How will the clarification evolve further based on such a data display?
from guider.
iipeace
commented on June 3, 2024
It's very strange.
-c '*statvfs*' is okay,
-c 'statvfs*|getret' -q allsym is not okay,
right?
could you test more?
# python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c '*statvfs*|getret'
# python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c '*statvfs*|getret' -q allsym
# python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c '*statvfs*' -q allsym
from guider.
elfring
commented on June 3, 2024
could you test more?
A)
Markus_Elfring@bw-wst-linux1:~/Aktivitäten/guider/lokal/guider> python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c '*statvfs*|getret'
… ver_3.9.8_211006 on python_3.8
…
[INFO] load /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so... [done]
0.049263 statvfs@GLIBC_2.2.5/0x7fc62f9d10c0(0x7fc62f6fcfb0,0x7fffb13886e0,0x0,0x7fc62f8e13e8,0x0,0x0) [/usr/lib64/libc.so.6]
0.049272 __internal_statvfs64/0x7fc62f9d61c0(0x7fffb13886e0,0x7fffb13885f0,0x0,0x7fc62f8e13e8,0x0,0x0) [/usr/lib64/libc.so.6]
0.049277 __internal_statvfs64[RET]=0x1000(4096)/0.000005 -> statvfs@GLIBC_2.2.5/0x7fc62f8d0000 [/usr/lib64/libc.so.6]
0.049282 statvfs@GLIBC_2.2.5[RET]=0x0(0)/0.000019 -> 0x1f8b40/0x7fc62fada000 [/usr/lib64/libpython3.8.so.1.0]
0.052919 +++ exited python3(12605) with 0 +++
B)
Markus_Elfring@bw-wst-linux1:~/Aktivitäten/guider/lokal/guider> python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c '*statvfs*|getret' -q allsym
… ver_3.9.8_211006 on python_3.8
…
[INFO] load /usr/lib64/libm.so.6... [done]
0.045732 __statvfs64/__statvfs/statvfs/statvfs64/statvfs@GLIBC_2.2.5/0x7f6ce51c20c0(0x7f6ce4eedfb0,0x7ffdf373c060,0x0,0x7f6ce50d23e8,0x0,0x0) [/usr/lib64/libc.so.6]
0.045738 __internal_statvfs64/0x7f6ce51c71c0(0x7ffdf373c060,0x7ffdf373bf70,0x0,0x7f6ce50d23e8,0x0,0x0) [/usr/lib64/libc.so.6]
0.045743 __internal_statvfs64[RET]=0x1000(4096)/0.000005 -> __statvfs64/__statvfs/statvfs/statvfs64/statvfs@GLIBC_2.2.5/0x7f6ce50c1000 [/usr/lib64/libc.so.6]
0.045748 __statvfs64/__statvfs/statvfs/statvfs64/statvfs@GLIBC_2.2.5[RET]=0x0(0)/0.000015 -> 0x1f8b40/0x7f6ce52cb000 [/usr/lib64/libpython3.8.so.1.0]
0.049532 +++ exited python3(12635) with 0 +++
C)
Markus_Elfring@bw-wst-linux1:~/Aktivitäten/guider/lokal/guider> python3 guider.py btrace "python3 -c \"import os;os.statvfs('.')\"" -c '*statvfs*' -q allsym
… ver_3.9.8_211006 on python_3.8
…
[INFO] load /usr/lib64/libm.so.6... [done]
0.050044 __statvfs64/__statvfs/statvfs/statvfs64/statvfs@GLIBC_2.2.5/0x7f7bfe3330c0(0x7f7bfe05efb0,0x7fff2ecc7c00,0x0,0x7f7bfe2433e8,0x0,0x0) [/usr/lib64/libc.so.6]
0.050057 __internal_statvfs64/0x7f7bfe3381c0(0x7fff2ecc7c00,0x7fff2ecc7b10,0x0,0x7f7bfe2433e8,0x0,0x0) [/usr/lib64/libc.so.6]
0.053669 +++ exited python3(12688) with 0 +++
from guider.
elfring
commented on June 3, 2024
Could you test below commands?
I deleted the files from the directory “/var/log/guider” as suggested.
[Markus_Elfring@fedora guider]$ ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c '*statvfs*'
… ver_3.9.8_211007 on python_3.9
…
[INFO] load /usr/lib64/libgpg-error.so.0.32.0... [done]
1.858253 statvfs@GLIBC_2.2.5/0x7fa809dc0c20(0x7fa8093a12b7,0x7ffe99ab9070,0x0,0x7fa809e44ac0,0x183e630,0x0) [/usr/lib64/libc-2.33.so]
1.858391 __internal_statvfs/0x7fa809dc5fc0(0x7fa8093a12b7,0x7ffe99ab9070,0x7ffe99ab8fd0,0x7fa809e44ac0,0x183e630,0x0) [/usr/lib64/libc-2.33.so]"7 19:21:44.499" Determining file system: "/home/Markus_Elfring/gui_rpc_auth.cfg"
1.899326 statvfs@GLIBC_2.2.5/0x7fa809dc0c20(0x185b3b8,0x7ffe99ab8aa0,0x185b3a0,0xa,0x185c732,0x0) [/usr/lib64/libc-2.33.so]
1.899471 __internal_statvfs/0x7fa809dc5fc0(0x185b3b8,0x7ffe99ab8aa0,0x7ffe99ab89f0,0xa,0x185c732,0x0) [/usr/lib64/libc-2.33.so]"7 19:21:44.525" | "Data determination by setPath()" | 6232797 |ns
"7 19:21:44.530" type name: "ext4"
1.909640 +++ exited QStorageInfo-se(8135) with 0 +++
Is this test result still questionable?
It's very strange because I got this results from my PC.
Should the deletion of a continue statement trigger any more descriptions?
from guider.
iipeace
commented on June 3, 2024
I think the change will not affect.
I guess the delete of cache files will affect.
Is this ok finally?
[Markus_Elfring@fedora guider]$ ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c 'statvfs*|getret' -q completecall,nocut,allsym
…
ver_3.9.8_211006 on python_3.9
"6 18:20:17.028" Determining file system: "/home/Markus_Elfring/gui_rpc_auth.cfg" "6 18:20:17.069" | "Data determination by setPath()" | 6353325 |ns "6 18:20:17.073" type name: "ext4" 2.039042
+++ exited QStorageInfo-se(6329)
from guider.
elfring
commented on June 3, 2024
I think the change will not affect.
I got the impression that additional software adjustments will be desired.
Is this ok finally?
Unlikely (according to information which was presented recently).
👀 I am looking for further commits which will improve the software situation a bit more.
from guider.
iipeace
commented on June 3, 2024
did you test again?
[Markus_Elfring@fedora guider]$ rm /var/log/guider/*
[Markus_Elfring@fedora guider]$ ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c 'statvfs*|getret' -q completecall,nocut,allsym
from guider.
elfring
commented on June 3, 2024
did you test again?
[Markus_Elfring@fedora guider]$ ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c '*statvfs*|getret' -q completecall,nocut,allsym
… ver_3.9.8_211007 on python_3.9
…
[INFO] load /usr/lib64/libpthread-2.33.so... [done]
1.790555 __internal_statvfs(0x7f8d004ea2b7,0x7ffea8d59b70,0x7ffea8d59ad0,0x7f8d00f8dac0,0xb39630,0x0)[/usr/lib64/libc-2.33.so]=0x100a(4106)/0.000013 -> __statvfs/__GI_statvfs/__statvfs64/statvfs64/statvfs/statvfs64@GLIBC_2.2.5/statvfs@GLIBC_2.2.5/0x7f8d00e19000 [/usr/lib64/libc-2.33.so]
1.790416 __statvfs/__GI_statvfs/__statvfs64/statvfs64/statvfs/statvfs64@GLIBC_2.2.5/statvfs@GLIBC_2.2.5(0x7f8d004ea2b7,0x7ffea8d59b70,0x0,0x7f8d00f8dac0,0xb39630,0x0)[/usr/lib64/libc-2.33.so]=0x0(0)/0.000196 -> 0x7110/0x7f8d004ca000 [/usr/lib64/libselinux.so.1]"8 17:03:35.713" Determining file system: "/home/Markus_Elfring/gui_rpc_auth.cfg"
1.827108 __internal_statvfs(0xb563b8,0x7ffea8d595a0,0x7ffea8d594f0,0xa,0xb57732,0x0)[/usr/lib64/libc-2.33.so]=0x1000(4096)/0.000057 -> __statvfs/__GI_statvfs/__statvfs64/statvfs64/statvfs/statvfs64@GLIBC_2.2.5/statvfs@GLIBC_2.2.5/0x7f8d00e19000 [/usr/lib64/libc-2.33.so]
1.826998 __statvfs/__GI_statvfs/__statvfs64/statvfs64/statvfs/statvfs64@GLIBC_2.2.5/statvfs@GLIBC_2.2.5(0xb563b8,0x7ffea8d595a0,0xb563a0,0xa,0xb57732,0x0)[/usr/lib64/libc-2.33.so]=0x0(0)/0.000205 -> 0x255670/0x7f8d01366000 [/usr/lib64/libQt5Core.so.5.15.2]"8 17:03:35.744" | "Data determination by setPath()" | 9244798 |ns
"8 17:03:35.748" type name: "ext4"
1.835685 +++ exited QStorageInfo-se(9674) with 0 +++
I find that further software adjustments will be helpful also because of such a test result.
from guider.
iipeace
commented on June 3, 2024
You wanna split mixed output including guider and target?
What do you think about "-o FILE -a" option to save output to a specific file?
from guider.
elfring
commented on June 3, 2024
It seems that it is needed to repeat suggestions which I mentioned before.
You wanna split mixed output including guider and target?
Occasionally, yes, of course.
- It became supported (for my test program) since you added parameters for corresponding redirection of standard data streams.
- It is probably interesting to check the shown mixed output in more detail.
- Would you like to reconsider the handling of line breaks?
- The software documentation is improvable.
- The repetition of the texts “
statvfs64” and “@GLIBC_2.2.5” indicates also remaining open issues, doesn't it?
May I expect an unambiguous display for the called function (eventually also together with a working filter for a known single name)?
What do you think about "-o FILE -a" option to save output to a specific file?
Would these options trigger more data processing than I would like to analyse here at the moment?
from guider.
Related Issues (20)
- Checking status for data recording HOT 17
- Fix exception handling for the import of essential modules HOT 3
- Split the grown script into loadable modules HOT 6
- Fix specifications of exit codes for the Guider launcher HOT 1
- Choose an error code according to a wrong depth type HOT 1
- Choose an error code according to a failed priority setting HOT 1
- Increase the usage of augmented assignment statements HOT 13
- Addition of a build system generator HOT 4
- Improve build support for newer Python versions HOT 1
- Fix error indication for a successful program analysis HOT 7
- Export tracing data in tabular form HOT 8
- Increase selection of data output streams HOT 6
- Provide numerical data instead of texts in output streams HOT 2
- Support the configuration of a shell environment before tracing a passed command HOT 10
- Reconsider “import gc” HOT 1
- Checking repetition for dictionary entry “statx” HOT 2
- Is it possible to record the process usage based on process id HOT 5
- release? HOT 6
- webservice 具体用什么指令开启呀 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from guider.