Re: A: sched_xetattr.test fails consistently on aarch64

2017-03-13 Thread Mike Frysinger
On 14 Mar 2017 00:57, Mike Frysinger wrote: > so there's a disagreement in the overall system somewhere. > i'd assume either the kernel's implementation of access_ok, > or gcc's handling of the inline assembly. > > once i have access to a local system and reduce a bit more, > i'll file some

Re: A: sched_xetattr.test fails consistently on aarch64

2017-03-13 Thread Mike Frysinger
On 14 Mar 2017 00:13, Dmitry V. Levin wrote: > sched_xetattr.test introduced by commit v4.16-10-gf31755f > (tests: check decoding of sched_[gs]etattr corner cases) > consistently fails on aarch64. > > At the same time the test passes on all other architectures > where strace is being tested

Re: GSOC: Introduction

2017-03-13 Thread Abhishek Tiwari
On Tue, Mar 14, 2017 at 2:00 AM, Dmitry V. Levin wrote: > On Tue, Mar 14, 2017 at 12:40:46AM +0530, Abhishek Tiwari wrote: >> > Per-file summary is not in GNU change log format, please refer to >> > https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html . >> >

Re: Implemented -e trace=%clock option

2017-03-13 Thread Dmitry V. Levin
On Mon, Mar 13, 2017 at 11:20:30PM +0530, Rishi Bhatt wrote: > Hey does $STRACE in init.sh is doing this:strace -e trace=%clock > ./clock_nanosleep > /dev/null > > So my problem here is the output in .tmp file is correct but the .exp has > the print statements from ./clock_nanosleep so for

Re: A: sched_xetattr.test fails consistently on aarch64

2017-03-13 Thread Dmitry V. Levin
On Mon, Mar 13, 2017 at 08:04:02PM -0400, Mike Frysinger wrote: > On 14 Mar 2017 00:13, Dmitry V. Levin wrote: > > However, I'm not an aarch64 expert myself, nor do I have the appropriate > > aarch64 hardware to investigate, so this issue is not going to be solved > > without your help. > > fwiw,

Re: Gsoc Introduction.

2017-03-13 Thread Dmitry V. Levin
Hi, On Tue, Mar 14, 2017 at 08:35:45AM +0700, Николай Марчук wrote: > Hello, > my name is Nikolay Marchuk and I am a first-year student in NSU, Russia. I > want to implement advanced filtering syntax for strace. I am familiar with > c and c++ and have an experience of making parsers. Thanks for

Gsoc Introduction.

2017-03-13 Thread Николай Марчук
Hello, my name is Nikolay Marchuk and I am a first-year student in NSU, Russia. I want to implement advanced filtering syntax for strace. I am familiar with c and c++ and have an experience of making parsers. I wanted to add support of new ioctl commands from linux 4.9 - 4.11 as my introduction

Re: A: sched_xetattr.test fails consistently on aarch64

2017-03-13 Thread Mike Frysinger
On 14 Mar 2017 00:13, Dmitry V. Levin wrote: > However, I'm not an aarch64 expert myself, nor do I have the appropriate > aarch64 hardware to investigate, so this issue is not going to be solved > without your help. fwiw, i should have a Gentoo system available for you to remote access in the

A: sched_xetattr.test fails consistently on aarch64

2017-03-13 Thread Dmitry V. Levin
Hi, sched_xetattr.test introduced by commit v4.16-10-gf31755f (tests: check decoding of sched_[gs]etattr corner cases) consistently fails on aarch64. At the same time the test passes on all other architectures where strace is being tested regularly, both 64-bit (alpha, ia64, mips64, ppc64,

Re: GSOC: Introduction

2017-03-13 Thread Dmitry V. Levin
On Tue, Mar 14, 2017 at 12:40:46AM +0530, Abhishek Tiwari wrote: > > Per-file summary is not in GNU change log format, please refer to > > https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html . > > Specifically, it lacks asterisks at the beginning of each new file > > description

Re: Implemented -e trace=%clock option

2017-03-13 Thread Rishi Bhatt
Hey does $STRACE in init.sh is doing this:strace -e trace=%clock ./clock_nanosleep > /dev/null So my problem here is the output in .tmp file is correct but the .exp has the print statements from ./clock_nanosleep so for matching .exp and .tmp files i have to filter setitimer string from .exp

Re: GSoC: Introduction

2017-03-13 Thread Dmitry V. Levin
Hi, On Sun, Mar 12, 2017 at 06:55:44AM +0100, Israel vianney wrote: > Hi, > > I am Vianney Israel a second year undergraduate computer science student in > ISICOM University from Cameroon. I am new to open-source and i wish to > contribute to Strace as for Gsoc 2017. > I am familiar with C, git

Re: [PATCH v1] unwind.c: fix a possible buffer overflow

2017-03-13 Thread Dmitry V. Levin
On Sat, Mar 11, 2017 at 02:27:33PM +0300, Victor Krapivensky wrote: > Linux does not prevent a user from creating a lot of nested directories > with length of the absolute path of the deepest one exceeding PATH_MAX, > then chdir'ing into it, creating a file there and mmap'ing it. Since the >

Re: [PATCH v1] util.c: remove a wrong comment

2017-03-13 Thread Dmitry V. Levin
On Fri, Mar 10, 2017 at 08:48:35PM +0300, Victor Krapivensky wrote: > 4924dbd6d750665cf383b20ab4fd67e48219ab91 modified the return type, but > not the comment. > --- > util.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/util.c b/util.c > index a38f821..f05d4ef 100644 > --- a/util.c >

Re: Implemented -e trace=%clock option

2017-03-13 Thread Eugene Syromyatnikov
> diff --git a/strace.1 b/strace.1 > index 9b69ec22..c46ca3ba 100644 > --- a/strace.1 > +++ b/strace.1 > @@ -429,6 +429,9 @@ Trace all memory mapping related system calls. > .BR "\-e\ trace" = %sched > Trace all scheduler-related (sched_*) system calls. > .TP > +.BR "\-e\ trace" = %clock >

Re: GSOC: Introduction

2017-03-13 Thread Eugene Syromyatnikov
On Sat, Mar 11, 2017 at 02:26:42PM +0530, Abhishek Tiwari wrote: > On Sat, Mar 11, 2017 at 1:46 PM, Abhishek Tiwari > wrote: > > Sir, I figured out that open system call is implemented corresponding > > to kernel version it supports, so open syscall is inside > >

Re: GSoC 2017 introduction

2017-03-13 Thread Eugene Syromyatnikov
On Sat, Mar 11, 2017 at 02:51:35PM +0300, Victor Krapivensky wrote: > Removed a trailing semicolon in a macro definition in tests/xstatx.c > and changed copyright holders of new files to "The strace developers". > > Please review this one. > > I've also found a possile buffer overflow bug in