Export tracing records in rows instead of multi-line structures #271

elfring · 2021-09-30T19:25:34Z

Some tracing data are offered as data structures which are distributed over multiple lines.

Example:
Call and return information according to function executions

I suggest to provide corresponding values in a single row per data set on demand.

iipeace · 2021-09-30T23:12:02Z

could you explain more detailed examples that you imagine?

elfring · 2021-10-01T07:46:48Z

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.

iipeace · 2021-10-01T09:10:10Z

Please share detailed output examples :)

elfring · 2021-10-01T09:23:51Z

I suggest to take another look at analysis examples which you published already.

iipeace · 2021-10-01T09:54:19Z

I guess that you wanna get a line including both function entry and return info.
Is it right?

elfring · 2021-10-01T10:00:13Z

Yes (for another concrete use case)

iipeace · 2021-10-01T14:43:18Z

What do you think about this?
It will only print return context.

# ./guider.py btrace yes -c "|filter:RETVAL:BT:0"

elfring · 2021-10-01T15:59:48Z

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?

iipeace · 2021-10-02T02:16:31Z

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?

iipeace · 2021-10-02T04:34:12Z

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]

elfring · 2021-10-02T07:18:05Z

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).

elfring · 2021-10-02T07:20:52Z

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.

iipeace · 2021-10-02T16:18:39Z

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
'''

elfring · 2021-10-02T16:55:00Z

Thanks for another positive feedback.
👀 I am still looking for corresponding extensions according to the software documentation.

elfring · 2021-10-02T18:11:40Z

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.

iipeace · 2021-10-02T23:38:26Z

is it okay without -q option?
could you share your program binary?

elfring · 2021-10-03T08:42:39Z

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);
}

elfring · 2021-10-03T09:26:29Z

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?

iipeace · 2021-10-03T09:36:57Z

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?

elfring · 2021-10-03T10:58:38Z

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)?

iipeace · 2021-10-03T12:00:17Z

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

elfring · 2021-10-03T12:20:03Z

./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

iipeace · 2021-10-03T12:50:26Z

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"

elfring · 2021-10-03T13:20:13Z

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?

iipeace · 2021-10-03T15:09:31Z

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.

elfring · 2021-10-03T15:21:38Z

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.

iipeace · 2021-10-04T14:23:11Z

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?

elfring · 2021-10-04T15:12:43Z

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.

iipeace · 2021-10-05T12:29:29Z

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.

elfring · 2021-10-05T13:00:57Z

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?

iipeace · 2021-10-06T14:20:28Z

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 +++

elfring · 2021-10-06T16:40:34Z

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 +++

iipeace · 2021-10-06T22:53:56Z

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*'

elfring · 2021-10-07T08:11:15Z

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?

iipeace · 2021-10-07T08:17:50Z

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 +++

elfring · 2021-10-07T08:25:54Z

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?

iipeace · 2021-10-07T08:44:01Z

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.

elfring · 2021-10-07T08:57:18Z

I want to know more environment characteristics.

Which algorithm is applied for the handling of mentioned function names (and their aliases) at the moment?

iipeace · 2021-10-07T12:03:13Z

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*"

elfring · 2021-10-07T12:23:16Z

…,
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?

iipeace · 2021-10-07T13:01:03Z

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

elfring · 2021-10-07T13:38:08Z

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 +++

elfring · 2021-10-07T17:42:15Z

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?

iipeace · 2021-10-07T23:15:51Z

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)

elfring · 2021-10-08T07:12:00Z

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.

iipeace · 2021-10-08T12:19:02Z

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

elfring · 2021-10-08T15:12:39Z

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.

iipeace · 2021-10-08T23:20:20Z

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?

elfring · 2021-10-09T08:28:26Z

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?

Export tracing records in rows instead of multi-line structures #271

Export tracing records in rows instead of multi-line structures #271

Comments

elfring commented Sep 30, 2021

iipeace commented Sep 30, 2021

elfring commented Oct 1, 2021

iipeace commented Oct 1, 2021

elfring commented Oct 1, 2021

iipeace commented Oct 1, 2021

elfring commented Oct 1, 2021

iipeace commented Oct 1, 2021

elfring commented Oct 1, 2021

iipeace commented Oct 2, 2021

iipeace commented Oct 2, 2021

elfring commented Oct 2, 2021

elfring commented Oct 2, 2021

iipeace commented Oct 2, 2021

elfring commented Oct 2, 2021

elfring commented Oct 2, 2021

iipeace commented Oct 2, 2021

elfring commented Oct 3, 2021

elfring commented Oct 3, 2021 • edited Loading

iipeace commented Oct 3, 2021 • edited Loading

elfring commented Oct 3, 2021

iipeace commented Oct 3, 2021 • edited Loading

elfring commented Oct 3, 2021 • edited Loading

iipeace commented Oct 3, 2021 • edited Loading

elfring commented Oct 3, 2021 • edited Loading

iipeace commented Oct 3, 2021 • edited Loading

elfring commented Oct 3, 2021

iipeace commented Oct 4, 2021

elfring commented Oct 4, 2021

iipeace commented Oct 5, 2021

elfring commented Oct 5, 2021

iipeace commented Oct 6, 2021 • edited Loading

elfring commented Oct 6, 2021

iipeace commented Oct 6, 2021 • edited Loading

elfring commented Oct 7, 2021

iipeace commented Oct 7, 2021 • edited Loading

elfring commented Oct 7, 2021

iipeace commented Oct 7, 2021

elfring commented Oct 7, 2021

iipeace commented Oct 7, 2021 • edited Loading

elfring commented Oct 7, 2021

iipeace commented Oct 7, 2021

elfring commented Oct 7, 2021

elfring commented Oct 7, 2021

iipeace commented Oct 7, 2021

elfring commented Oct 8, 2021

iipeace commented Oct 8, 2021

elfring commented Oct 8, 2021

iipeace commented Oct 8, 2021

elfring commented Oct 9, 2021

elfring commented Oct 3, 2021 •

edited

Loading

iipeace commented Oct 3, 2021 •

edited

Loading

iipeace commented Oct 3, 2021 •

edited

Loading

elfring commented Oct 3, 2021 •

edited

Loading

iipeace commented Oct 3, 2021 •

edited

Loading

elfring commented Oct 3, 2021 •

edited

Loading

iipeace commented Oct 3, 2021 •

edited

Loading

iipeace commented Oct 6, 2021 •

edited

Loading

iipeace commented Oct 6, 2021 •

edited

Loading

iipeace commented Oct 7, 2021 •

edited

Loading

iipeace commented Oct 7, 2021 •

edited

Loading