Bug 26786 - strace update for kernel 5.7
Summary: strace update for kernel 5.7
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2020-06-12 23:00 CEST by David Walser
Modified: 2020-06-19 12:26 CEST (History)
5 users (show)

See Also:
Source RPM: strace-5.6-1.mga7.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2020-06-12 23:00:16 CEST
Advisory:
----------------------------------------

The strace package has been updated to version 5.7 to support the
newest features in the 5.7 kernel and fix a few bugs.

References:
https://lists.strace.io/pipermail/strace-devel/2020-June/009783.html
----------------------------------------

Updated packages in core/updates_testing:
----------------------------------------
strace-5.7-1.mga7

from strace-5.7-1.mga7.src.rpm
Comment 1 David GEIGER 2020-06-12 23:12:44 CEST
but we haven't yet kernel 5.7 series in mga7...

CC: (none) => geiger.david68210

Comment 2 David Walser 2020-06-12 23:14:02 CEST
Haha, that's the same thing tmb said with 5.6.  It also doesn't matter.
Comment 3 Len Lawrence 2020-06-16 17:59:19 CEST
mga7, x86_64

Installed the update and ran a few simple tests.  There is a myriad of options to strace.
$ strace -o strace.trace cat EGPH.TXT >> tmp/testfile
$ cat strace.trace
execve("/usr/bin/cat", ["cat", "EGPH.TXT"], 0x7ffd3a6554e8 /* 94 vars */) = 0
brk(NULL)                               = 0x237e000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
[...]
read(3, "Edinburgh Airport, United Kingdo"..., 131072) = 427
write(1, "Edinburgh Airport, United Kingdo"..., 427) = 427
read(3, "", 131072)                     = 0
munmap(0x7f14c536c000, 139264)          = 0
close(3)                                = 0
...
+++ exited with 0 +++

$ strace -o glmark2.trace glmark2
ctrl-C interrupt
$ ll *.trace
-rw-r--r-- 1 lcl lcl 60058011 Jun 16 15:50 glmark2.trace
-rw-r--r-- 1 lcl lcl     2633 Jun 16 15:43 strace.trace
sched_yield()                           = 0
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
getpid()                                = 15346
getpid()                                = 15346
sched_yield()                           = 0
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++

Set glmark2 running and recorded its pid.
$ strace -o gl.trace -p 15652
strace: Process 15652 attached
Interrupted glmark2.
$ less gl.trace
getpid()                                = 15652
getpid()                                = 15652
sched_yield()                           = 0
sched_yield()                           = 0
[...]
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
getpid()                                = 15652
getpid()                                = 15652
sched_yield()                           = 0
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++

Not quite what was expected.  All entries were doubled and seem to record only the interactions between strace and glmark2 rather than what glmark2 was actually doing.  Wrong end of the stick probably.
$ strace -p `pidof glmark2` -o glmark2.trace 
strace: Process 28354 attached
That worked better, terminating when glmark2 finished.  Must be the order of the arguments.
$ tail glmark2.trace
munmap(0x7fa4b1004000, 4096)            = 0
ioctl(4, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x29, 0x10), 0x7ffe49b53eb0) = 0
munmap(0x7fa4ae586000, 1069056)         = 0
close(7)                                = 0
close(6)                                = 0
close(5)                                = 0
ioctl(4, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x29, 0x10), 0x7ffe49b53ee0) = 0
close(4)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

$ strace -e trace=ioctl -o filter.trace glmark2
$ tail glmark2.trace
ioctl(4, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x29, 0x10), 0x7ffe157d0b70) = 0
ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x6d, 0, 0x10), 0x7ffe157d0b90) = 0
ioctl(4, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x29, 0x10), 0x7ffe157d0b90) = 0
ioctl(4, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x29, 0x10), 0x7ffe157d0bc0) = 0
+++ exited with 0 +++

Testing all the options would take a month of Sundays.  Enough.

Whiteboard: (none) => MGA7-64-OK
CC: (none) => tarazed25

Comment 4 Thomas Andrews 2020-06-18 03:24:18 CEST
Validating. Advisory in Comment 0.

CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update

Nicolas Lécureuil 2020-06-19 11:27:56 CEST

CC: (none) => mageia
Keywords: (none) => advisory

Comment 5 Mageia Robot 2020-06-19 12:26:33 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2020-0147.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.