Re: Release plans?
On Mon, Mar 12, 2012 at 01:26:35PM +0100, Denys Vlasenko wrote: > On 03/10/2012 11:17 PM, Dmitry V. Levin wrote: > > On Thu, Feb 09, 2012 at 07:38:27PM +0100, Denys Vlasenko wrote: > >> On 02/09/2012 05:29 PM, Dmitry V. Levin wrote: > >>> But I'd like to hear from Denys about PTRACE_SEIZE perspective first. > >>> We surely won't release PTRACE_SEIZE_DEVEL code enabled by default because > >>> the kernel API might change. > >> > >> I'm going to ask kernel people to drop PTRACE_SEIZE_DEVEL. > > > > The patch was submitted in February, but current v3.3-rc6-240-gc7b2855 > > still insists on PTRACE_SEIZE_DEVEL. Is there a prospect to release > > without PTRACE_SEIZE_DEVEL any time soon, or should we rather leave this > > experimental code disabled in the next release? > > It's in linux-next git: [...] > Looks like this change will go into linux-3.4 So it is not going to be in a released kernel this spring? -- ldv pgpucWqDBNzcm.pgp Description: PGP signature -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Release plans?
On Mon, Mar 12, 2012 at 08:00:46PM +0100, Denys Vlasenko wrote: > On 03/12/2012 02:47 PM, Dmitry V. Levin wrote: > >>>>> But I'd like to hear from Denys about PTRACE_SEIZE perspective first. > >>>>> We surely won't release PTRACE_SEIZE_DEVEL code enabled by default > >>>>> because > >>>>> the kernel API might change. > >>>> > >>>> I'm going to ask kernel people to drop PTRACE_SEIZE_DEVEL. > >>> > >>> The patch was submitted in February, but current v3.3-rc6-240-gc7b2855 > >>> still insists on PTRACE_SEIZE_DEVEL. Is there a prospect to release > >>> without PTRACE_SEIZE_DEVEL any time soon, or should we rather leave this > >>> experimental code disabled in the next release? > >> > >> It's in linux-next git: > > [...] > >> Looks like this change will go into linux-3.4 > > > > So it is not going to be in a released kernel this spring? > > I guess not. OK, let's release without USE_SEIZE enabled then. There is a lot of stuff waiting since 4.6, more than enough to justify a release. It's such a pity we didn't have a policy to update the NEWS file along with committing noteworthy changes. What version should this release be, 4.6.1 or 4.7? -- ldv pgpVuQvubi3PG.pgp Description: PGP signature -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Release plans?
On Mon, Mar 12, 2012 at 06:37:01PM +, Grant Edwards wrote: > On 2012-03-12, Denys Vlasenko wrote: > > On 03/10/2012 11:17 PM, Dmitry V. Levin wrote: > >> On Thu, Feb 09, 2012 at 07:38:27PM +0100, Denys Vlasenko wrote: > >>> On 02/09/2012 05:29 PM, Dmitry V. Levin wrote: > >>>> But I'd like to hear from Denys about PTRACE_SEIZE perspective first. > >>>> We surely won't release PTRACE_SEIZE_DEVEL code enabled by default > >>>> because > >>>> the kernel API might change. > >>> > >>> I'm going to ask kernel people to drop PTRACE_SEIZE_DEVEL. > >> > >> The patch was submitted in February, but current v3.3-rc6-240-gc7b2855 > >> still insists on PTRACE_SEIZE_DEVEL. Is there a prospect to release > >> without PTRACE_SEIZE_DEVEL any time soon, or should we rather leave this > >> experimental code disabled in the next release? > > > > It's in linux-next git: > > > > commit fe948360bf475b705c021fc9ba8ee3992c5d0d67 > > Author: Denys Vlasenko > > Date: Tue Mar 6 11:25:31 2012 +1100 > > > > ptrace: remove PTRACE_SEIZE_DEVEL bit > > > > PTRACE_SEIZE code is tested and ready for production use, remove the > > code > > which requires special bit in data argument to make PTRACE_SEIZE work. > > > > Strace team prepares for a new release of strace, and we would like to > > ship the code which uses PTRACE_SEIZE, preferably after this change > > goes > > into released kernel. > > > > Signed-off-by: Denys Vlasenko > > Acked-by: Tejun Heo > > Acked-by: Oleg Nesterov > > Cc: Pedro Alves > > Cc: Jan Kratochvil > > Signed-off-by: Andrew Morton > > > > Looks like this change will go into linux-3.4 > > Does this mean that the upcoming release of Strace will require Linux > 3.4 or newer? The PTRACE_SEIZE feature will work only on kernels that support this API. On other kernels, the runtime check will fall back to traditional PTRACE_TRACEME interface. -- ldv pgpAKacgehsjF.pgp Description: PGP signature -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: tagged version vs released tarball
On Mon, Mar 12, 2012 at 08:50:44PM +0100, Abdoulaye Walsimou GAYE wrote: > Sorry for this thread hijack, Could you at least change the subject next time, please? Thanks. > but I noticed that tagged version and corresponding > tarball does not contain the same files. This prevents for example to > cherry-pick > some critical fixes and apply them against the release tarball source code, > if you > don't want to wait several months for a new release. > So it would nice to to release a tarball which contains the same files as the > tag. Released tarballs are produced by "make-dist" script, which essentially does "autoreconf -f", "configure --enable-maintainer-mode" and "make distcheck", which in turn pack some additional autotools- and git-generated files, and leave some git-only files out. There should be no problem to build strace from a git checkout, just have a look at "make-dist" script. "autoreconf -if && ./configure && make" should be enough in most cases. One can expect that HEAD always builds and works at least on x86-64. Said that, we probably should consider releasing strace more often. -- ldv pgpo6CFCgWsOH.pgp Description: PGP signature -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
upcoming release: what needs to be done
Hi, There is quite enough good stuff accumulated in strace.git since v4.6 to have a new release soon. If there are no objections, here is a list of pre-release work to be done for this release: - merge pending patches if any (please speak up); - test on supported non-x86 architectures; - update the NEWS file; - sync and update strace.spec and debian/* files. -- ldv pgpW8McevAc8t.pgp Description: PGP signature -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [SCM] strace branch, master, updated. v4.6-258-ge8172b7
On Fri, Mar 09, 2012 at 12:03:01PM +, Denys Vlasenko wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "strace". [...] > Allow -p PID to take comma or whitespace-separated list of PIDs > > * defs.h: Clarify meaning of TCB_ATTACHED. No code changes. > * strace.c (process_opt_p_list): New function. > (main): Call process_opt_p_list to process -p PIDs argument. I suppose this extension should be documented in the manual page, too. -- ldv pgptealO6v7ES.pgp Description: PGP signature -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Wed, Mar 14, 2012 at 08:39:35PM -0400, Mike Frysinger wrote:
> On Monday 12 March 2012 17:50:48 Dmitry V. Levin wrote:
> > - test on supported non-x86 architectures;
>
> build fails with <=glibc-2.12 because SWAP_FLAG_DISCARD wasn't added until
> then. files.c unconditionally uses that.
I had to expect that. Fixed, thanks.
> ia64 has these warnings ... maybe just deleting these defines from the ia64
> header would work ?
> ./linux/ia64/syscallent.h:47:0: warning: "sys_alarm" redefined
> ./linux/dummy.h:114:0: note: this is the location of the previous definition
> ./linux/ia64/syscallent.h:115:0: warning: "sys_getresgid" redefined
> ./linux/dummy.h:73:0: note: this is the location of the previous definition
Fixed, thanks.
> alpha looks broken with signals ... these funcs pass the target's syscall arg
> pointer to the C library's sigprocmask() which obviously won't be valid:
> signal.c: In function ‘sys_sigprocmask’:
> signal.c:1185:3: warning: passing argument 1 of ‘printsigmask’ makes pointer
> from integer without a cast
> signal.c:352:1: note: expected ‘struct sigset_t *’ but argument is of type
> ‘long int’
> signal.c:1188:3: warning: passing argument 2 of ‘sprintsigmask’ makes pointer
> from integer without a cast
> signal.c:283:1: note: expected ‘struct sigset_t *’ but argument is of type
> ‘long int’
The code is in "#ifdef ALPHA" section. Yes, it looks odd, but those lines
remain essentially unchanged since the previous century. Is there anybody
who can look into this?
> ppc64 had a build warning in the syscall code, but i posted a patch to fix
> that.
Applied, thanks.
> then it hit a strict aliasing warning in sys_cap{g,s}et (and looking at
> the code, it does look pretty wrong):
> system.c: In function ‘sys_capset’:
> system.c:559: warning: dereferencing pointer ‘arg0’ does break
> strict-aliasing rules
> system.c:559: warning: dereferencing pointer ‘arg0’ does break
> strict-aliasing rules
> system.c:548: note: initialized from here
This is result of commits v4.6-45-gb0bafbb and v4.6-47-g1c706b3.
I wonder why these warnings appear only on ppc64.
Anyway, I've pushed a fix.
> getting past those, and make compiled cleanly & passed check on:
> alpha ia64 ppc ppc64 s390 s390x x86_64
That's nice, thanks.
--
ldv
pgpce2ul4JWu1.pgp
Description: PGP signature
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: RFC: better signal names?
On Thu, Mar 15, 2012 at 04:13:18PM +0100, Denys Vlasenko wrote:
> Currently we emit something like this:
>
> --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19483, si_status=0,
> si_utime=0, si_stime=0} (Child exited) ---
> --- {si_signo=SIGWINCH, si_code=SI_USER, si_pid=15407, si_uid=0} (Window
> changed) ---
> --- {si_signo=SIGSTOP, si_code=SI_USER, si_pid=15407, si_uid=0} (Stopped
> (signal)) ---
> --- Stopped (signal) by SIGSTOP ---
> --- {si_signo=SIGTSTP, si_code=SI_USER, si_pid=15407, si_uid=0} (Stopped)
> ---
> --- Stopped by SIGTSTP ---
> --- {si_signo=SIGTTIN, si_code=SI_USER, si_pid=15407, si_uid=0} (Stopped
> (tty input)) ---
> --- Stopped (tty input) by SIGTTIN ---
>
> The part where we try to emit a "descriptive" signal string
> does not look like succeeding in this regard: it's often
> barely comprehensible, and sometimes plainly wrong.
I find the technical part of these messages (produced by printsiginfo)
much more informative than the descriptive part (produced by strsignal).
I suppose we can safely drop this strsignal-made part.
--
ldv
pgp8OerCclDxm.pgp
Description: PGP signature
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Wed, Mar 14, 2012 at 08:39:35PM -0400, Mike Frysinger wrote: > alpha looks broken with signals ... Not only with signals, IPC decoding also seems to be broken on alpha: SYS_ipc_subcall is naturally not defined, but indirect_ipccall() returns 1 there. Could you confirm that, e.g. by checking whether "strace -eipc ipcs" outputs crap or not, please? -- ldv pgpNFVqbH4Jof.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Fri, Mar 16, 2012 at 01:10:37AM +0400, Dmitry V. Levin wrote: > On Wed, Mar 14, 2012 at 08:39:35PM -0400, Mike Frysinger wrote: > > alpha looks broken with signals ... > > Not only with signals, IPC decoding also seems to be broken on alpha: > SYS_ipc_subcall is naturally not defined, but indirect_ipccall() > returns 1 there. Could you confirm that, e.g. by checking whether > "strace -eipc ipcs" outputs crap or not, please? The same bug exists on ARM EABI, so I suppose my guess about ALPHA is correct and I'm going to commit the fix. -- ldv pgpBHueKb2EeH.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Thu, Mar 15, 2012 at 01:56:12PM -0400, Mike Frysinger wrote: > superh compiles and passes make check. it warns about the new system.c code > (strict aliasing), but this is a 4.4 compiler, so i'm going to update it and > see if that makes a difference. btw, I've got these warnings on ARM EABI with a 4.4 compiler, too, but on the same system with a 4.5 compiler they are gone, so I suppose the new code is OK. -- ldv pgpgEkjr3v1A1.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Thu, Mar 15, 2012 at 06:36:16PM -0400, Mike Frysinger wrote: > On Thursday 15 March 2012 17:10:37 Dmitry V. Levin wrote: > > On Wed, Mar 14, 2012 at 08:39:35PM -0400, Mike Frysinger wrote: > > > alpha looks broken with signals ... > > > > Not only with signals, IPC decoding also seems to be broken on alpha: > > SYS_ipc_subcall is naturally not defined, but indirect_ipccall() > > returns 1 there. Could you confirm that, e.g. by checking whether > > "strace -eipc ipcs" outputs crap or not, please? > > this box doesn't have any shared memory segments active (which isn't > surprising as it's a headless build/dev box). here's the output, but i'm not > sure it exactly answers your question ? Yes, it perfectly does, thanks. > $ ./strace -eipc ipcs > > shmctl(0, IPC_64|SHM_INFO, 0) = 0 > shmctl(0, IPC_64|SHM_STAT, 0) = -1 EINVAL (Invalid argument) The 3rd argument must be a valid memory address, e.g. shmctl(0, IPC_64|SHM_INFO, 0xbfc398f8) = 0 shmctl(0, IPC_64|SHM_STAT, 0xbfc39880) = -1 EINVAL (Invalid argument) I've pushed a fix. -- ldv pgpAONCEmZSND.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Thu, Mar 15, 2012 at 12:53:23AM -0400, Mike Frysinger wrote:
> arm hits this warning:
> signal.c: In function ‘sys_rt_sigaction’:
> signal.c:1345:4: warning: left shift count >= width of type
I saw this warning a year ago as well. The code is unreachable on ARM,
but gcc seems to be too dumb to recognize that. I've pushed a change to
optimize out this code on the preprocessor stage.
> ignoring that, `make check` fails because my /bin/sh is dash, and the $* code
> the tests uses doesn't work. not sure if it's a bug in dash, but using
> ${*:-../strace} instead of ${*-../strace} in tests/init.sh makes it work.
> i'd
> lean towards this syntax anyways as you should default to ../strace even if
> the user gave you "" ...
OK, I've changed tests/init.sh, but that version of dash is certainly buggy.
> getting past that, `make check` passes and strace seems to work on this old
> netwinder of mine.
Thanks.
--
ldv
pgp2p1hrmvvBn.pgp
Description: PGP signature
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Thu, Mar 15, 2012 at 01:17:56AM -0400, Mike Frysinger wrote: > hppa hit this warning: > ipc.c: In function ‘sys_shmat’: > ipc.c:407:16: warning: unused variable ‘raddr’ > but looking at the code, we could add another ifdef around the variable > definition, but i'm not sure that really improves things all that much ... There is no hppa specific in sys_shmat(). The code was wrong, it had to check for indirect_ipccall() instead, like other ipc decoders do. It does now. > it also hit another warning, but i posted a patch for that > > otherwise, hppa builds clean & passes make check > > sparc32 compiles cleanly and passes make check Thanks. -- ldv pgpg6YW6tgS5R.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Q: can rlim_t be a long long type on linux
Hi, While writing a prlimit64 syscall parser I found a seemingly dead HAVE_LONG_LONG_RLIM_T code in resource.c that implements [gs]etrlimit parsers for systems where sizeof(rlim_t) == sizeof(long long). Looking at "struct rlimit" and "struct compat_rlimit" definitions in include/linux/resource.h and include/linux/compat.h I see no way for sizeof(rlim_t) to be greater than sizeof(long) on linux. Is it correct that rlim_t cannot be a long long type on linux, or am I missing something? -- ldv pgpjIGTIMlfO7.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Q: can rlim_t be a long long type on linux
On Fri, Mar 16, 2012 at 05:45:51PM -0400, Mike Frysinger wrote: > On Friday 16 March 2012 16:18:33 Andreas Schwab wrote: > > "Dmitry V. Levin" writes: > > > Is it correct that rlim_t cannot be a long long type on linux, > > > or am I missing something? > > > > x32 is going to be the first. > > mips/n32 doesn't ? Thanks. To be on the safe side, I'll rewrite the code in terms of uint32_t and uint64_t. -- ldv pgpbHdKufTJfe.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [SCM] strace branch, master, updated. v4.6-333-g31972d5
On Sat, Mar 17, 2012 at 12:28:50PM +, Denys Vlasenko wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "strace". [...] > commit 31972d52b1059d8faca1c5f417c2db1a90b868ae > Author: Denys Vlasenko > Date: Sat Mar 17 13:23:00 2012 +0100 > > Remove underscores from a few syscall names which have them I think this change is wrong. > Affected names are "_newselect", "_llseek", "_sysctl". > I see no apparent reason why they have leading underscores. > Moreover, some arches have underscored names and some have > non-underscored ones. This is not consistent. The naming consistency does not matter here. It is not our business to give syscalls consistent names. All we have to do about syscall names is just to follow the kernel. And the kernel still exports some names with leading underscores, e.g. $ git grep '[[:space:]]_' arch/x86/syscalls/syscall_32.tbl arch/x86/syscalls/syscall_32.tbl:140i386_llseek sys_llseek arch/x86/syscalls/syscall_32.tbl:142i386_newselect sys_select compat_sys_select arch/x86/syscalls/syscall_32.tbl:149i386_sysctl sys_sysctl compat_sys_sysctl -- ldv pgpvoBiWlHlrN.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Q: can rlim_t be a long long type on linux
On Fri, Mar 16, 2012 at 05:45:51PM -0400, Mike Frysinger wrote: > On Friday 16 March 2012 16:18:33 Andreas Schwab wrote: > > "Dmitry V. Levin" writes: > > > Is it correct that rlim_t cannot be a long long type on linux, > > > or am I missing something? > > > > x32 is going to be the first. > > mips/n32 doesn't ? btw, how one can reliably identify that kind of information just looking at the kernel? For example, we have an oddness in file.c with several different definitions of sys_lseek, one for HAVE_LONG_LONG_OFF_T, another for !HAVE_LONG_LONG_OFF_T, and yet another one for LINUX_MIPSN32 where off_t is actually emulated via "long long". How could it be that off_t is not a "long long" type but lseek takes a "long long" argument? -- ldv pgpC6SYBLCwA8.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: bug in commit 20f6b54385d2462d858419f7c67509cb3d22d155
On Mon, Mar 26, 2012 at 01:56:22PM +0200, Andreas Schwab wrote:
> Denys Vlasenko writes:
>
> > Hi Dmitry,
> >
> > for file in "$logfile".*; do
> > [ -f "$file" ] || continue
> > - suffix=${file:1+$pfxlen}
> > - [ "$suffix" -gt 0 ] 2> /dev/null || {
> > - echo "Skipped file '$file' (bad suffix)" >&2
> > + suffix=${file#$logfile.}
> >
> > suffix=${file#$logfile.} is not a good way to strip $logfile prefix:
> > ${var#pattern} operation interprets , indeed, as glob pattern.
>
> Unless quoted.
>
> > Try this:
> >
> > logfile=""
> > file=FILE.123
> > suffix=${file#$logfile.}
> suffix=${file#"$logfile".}
Thanks, I've pushed this fix.
--
ldv
pgp6j3anjNGM8.pgp
Description: PGP signature
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] powerpc: Add syscall entries for socket system calls
On Tue, Mar 27, 2012 at 10:34:54AM +1100, Anton Blanchard wrote:
>
> * linux/powerpc/syscallent.h: Add socket system calls
Just for the record, what have happened with the socket subcall on ppc?
> diff --git a/linux/powerpc/syscallent.h b/linux/powerpc/syscallent.h
> index 8dd56bd..a382bdc 100644
> --- a/linux/powerpc/syscallent.h
> +++ b/linux/powerpc/syscallent.h
> @@ -352,25 +352,25 @@
> { 2,TD, sys_fanotify_init, "fanotify_init" }, /*
> 323 */
> { 5,TD|TF, sys_fanotify_mark, "fanotify_mark" }, /*
> 324 */
> { 4,0, sys_prlimit64, "prlimit64" }, /*
> 325 */
> - { 5,0, NULL, NULL}, /*
> 326 */
> - { 5,0, NULL, NULL}, /*
> 327 */
> - { 5,0, NULL, NULL}, /*
> 328 */
> - { 5,0, NULL, NULL}, /*
> 329 */
> - { 5,0, NULL, NULL}, /*
> 330 */
> - { 5,0, NULL, NULL}, /*
> 331 */
> - { 5,0, NULL, NULL}, /*
> 332 */
> - { 5,0, NULL, NULL}, /*
> 333 */
> - { 5,0, NULL, NULL}, /*
> 334 */
> - { 5,0, NULL, NULL}, /*
> 335 */
> - { 5,0, NULL, NULL}, /*
> 336 */
> - { 5,0, NULL, NULL}, /*
> 337 */
> - { 5,0, NULL, NULL}, /*
> 338 */
> - { 5,0, NULL, NULL}, /*
> 339 */
> - { 5,0, NULL, NULL}, /*
> 340 */
> - { 5,0, NULL, NULL}, /*
> 341 */
> - { 5,0, NULL, NULL}, /*
> 342 */
> - { 5,0, NULL, NULL}, /*
> 343 */
> - { 5,0, NULL, NULL}, /*
> 344 */
> + { 3,TN, sys_socket, "socket"}, /*
> 326 */
> + { 3,TN, sys_bind, "bind" }, /*
> 327 */
> + { 3,TN, sys_connect,"connect" }, /*
> 328 */
> + { 2,TN, sys_listen, "listen"}, /*
> 329 */
> + { 3,TN, sys_accept, "accept"}, /*
> 330 */
> + { 3,TN, sys_getsockname,"getsockname" }, /*
> 331 */
> + { 3,TN, sys_getpeername,"getpeername" }, /*
> 332 */
> + { 4,TN, sys_socketpair, "socketpair"}, /*
> 333 */
> + { 4,TN, sys_send, "send" }, /*
> 334 */
> + { 6,TN, sys_sendto, "sendto"}, /*
> 335 */
> + { 4,TN, sys_recv, "recv" }, /*
> 336 */
> + { 6,TN, sys_recvfrom, "recvfrom" }, /*
> 337 */
> + { 2,TN, sys_shutdown, "shutdown" }, /*
> 338 */
> + { 5,TN, sys_setsockopt, "setsockopt"}, /*
> 339 */
> + { 5,TN, sys_getsockopt, "getsockopt"}, /*
> 340 */
> + { 3,TN, sys_sendmsg,"sendmsg" }, /*
> 341 */
> + { 5,TN, sys_recvmsg,"recvmsg" }, /*
> 342 */
> + { 5,TN, sys_recvmmsg, "recvmmsg" }, /*
> 343 */
> + { 4,TN, sys_accept4,"accept4" }, /*
> 344 */
> { 5,TD|TF, sys_name_to_handle_at, "name_to_handle_at" }, /*
> 345 */
> { 3,TD, sys_open_by_handle_at, "open_by_handle_at" }, /*
> 346 */
> { 2,0, sys_clock_adjtime, "clock_adjtime" }, /*
> 347 */
--
ldv
pgpsDQNMFTGgL.pgp
Description: PGP signature
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Concurrency output issue
Hi, On Mon, Mar 26, 2012 at 05:24:07PM -0400, Bao Hong Tan wrote: > Hi all, > > I looked at strace's output and saw the following: > > 01:20:00.727079 recv(-1345034744, 01:20:00.727768 write(24, "338", > 301:20:00.728785 SYS_224(0x3adfa8, 0x40025730, 0xa, 0x45006f40) = 0xccd000 > 01:20:00.729827 recv(-1345034744, 0x81, 1, MSG_OOB) = 1 > "", 2, 0) = 0 This output is odd in many aspects, I haven't seen such things for ages. > The traced program have multiple threads. Looks like strace is not able > to handle concurrent output to the log file. > > For example, the first line is interrupted by another. > > I am using version 4.5.12 (in Android) by the way, has this issue been > fixed? Well, 4.5.12 was released almost 7 years ago, the latest released version at this moment is 4.6, it definitely works better with threads. -- ldv pgpBGCGMawvQN.pgp Description: PGP signature -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v2] decode mtd ioctls
On Tue, Apr 03, 2012 at 02:24:33AM -0400, Mike Frysinger wrote: > I got tired of figuring out mtd structures (which show up a lot > in the embedded space), so add decoders for those ioctls. > > * defs.h (mtd_ioctl): New prototype. > (print_loff_t): Likewise. > * io.c (print_loff_t): Delete static keyword > * ioctl.c (ioctl_decode): Call mtd_ioctl when code is 'M'. > * Makefile.am (strace_SOURCES): Add mtd.c. > * mtd.c: New file. I've got a system where it doesn't compile because mtd/mtd-user.h is not installed there: mtd.c:30:26: fatal error: mtd/mtd-user.h: No such file or directory One may argue that the system must provide this file, but I'd rather like to have a traditional workaround for such cases. ;) -- ldv pgpXjo8ILFmkQ.pgp Description: PGP signature -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Mon, Apr 02, 2012 at 11:26:06PM -0400, Mike Frysinger wrote: > On Monday 12 March 2012 17:50:48 Dmitry V. Levin wrote: > > There is quite enough good stuff accumulated in strace.git since v4.6 to > > have a new release soon. If there are no objections, here is a list of > > pre-release work to be done for this release: > > > > - merge pending patches if any (please speak up); > > - test on supported non-x86 architectures; > > - update the NEWS file; > > - sync and update strace.spec and debian/* files. > > anything still pending ? The NEWS file; unfortunately, it was not updated since v4.6, and we now have some 371 commits to be condensed into the list of noteworthy changes. Well, I cannot be excused from completing this task anyway, just let me a bit more time. -- ldv pgp3zQ8hc15bT.pgp Description: PGP signature -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v2] decode mtd ioctls
On Tue, Apr 03, 2012 at 10:22:48PM -0400, Mike Frysinger wrote: > On Tuesday 03 April 2012 19:11:32 Dmitry V. Levin wrote: > > On Tue, Apr 03, 2012 at 02:24:33AM -0400, Mike Frysinger wrote: > > > I got tired of figuring out mtd structures (which show up a lot > > > in the embedded space), so add decoders for those ioctls. > > > > > > * defs.h (mtd_ioctl): New prototype. > > > (print_loff_t): Likewise. > > > * io.c (print_loff_t): Delete static keyword > > > * ioctl.c (ioctl_decode): Call mtd_ioctl when code is 'M'. > > > * Makefile.am (strace_SOURCES): Add mtd.c. > > > * mtd.c: New file. > > > > I've got a system where it doesn't compile because mtd/mtd-user.h > > is not installed there: > > > > mtd.c:30:26: fatal error: mtd/mtd-user.h: No such file or directory > > > > One may argue that the system must provide this file, but I'd rather > > like to have a traditional workaround for such cases. ;) > > should i just copy the header locally ? or add a mtd-user.h header check and > disable the code if it's not found ? I've got another system where this header file is installed but it's quite unusable: mtd.c:33:4: error: 'MTD_OPS_PLACE_OOB' undeclared here (not in a function) mtd.c:34:4: error: 'MTD_OPS_AUTO_OOB' undeclared here (not in a function) mtd.c:35:4: error: 'MTD_OPS_RAW' undeclared here (not in a function) mtd.c:47:4: error: 'MTD_MLCNANDFLASH' undeclared here (not in a function) So I suppose it would be safer to provide a local copy. -- ldv pgpyqF2lmdyQa.pgp Description: PGP signature -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v2] decode mtd ioctls
On Wed, Apr 04, 2012 at 08:31:34PM -0400, Mike Frysinger wrote: > On Wednesday 04 April 2012 14:14:49 Dmitry V. Levin wrote: > > On Tue, Apr 03, 2012 at 10:22:48PM -0400, Mike Frysinger wrote: > > > On Tuesday 03 April 2012 19:11:32 Dmitry V. Levin wrote: > > > > On Tue, Apr 03, 2012 at 02:24:33AM -0400, Mike Frysinger wrote: > > > > > I got tired of figuring out mtd structures (which show up a lot > > > > > in the embedded space), so add decoders for those ioctls. > > > > > > > > > > * defs.h (mtd_ioctl): New prototype. > > > > > (print_loff_t): Likewise. > > > > > * io.c (print_loff_t): Delete static keyword > > > > > * ioctl.c (ioctl_decode): Call mtd_ioctl when code is 'M'. > > > > > * Makefile.am (strace_SOURCES): Add mtd.c. > > > > > * mtd.c: New file. > > > > > > > > I've got a system where it doesn't compile because mtd/mtd-user.h > > > > is not installed there: > > > > > > > > mtd.c:30:26: fatal error: mtd/mtd-user.h: No such file or directory > > > > > > > > One may argue that the system must provide this file, but I'd rather > > > > like to have a traditional workaround for such cases. ;) > > > > > > should i just copy the header locally ? or add a mtd-user.h header check > > > and disable the code if it's not found ? > > > > I've got another system where this header file is installed but it's quite > > unusable: > > mtd.c:33:4: error: 'MTD_OPS_PLACE_OOB' undeclared here (not in a function) > > mtd.c:34:4: error: 'MTD_OPS_AUTO_OOB' undeclared here (not in a function) > > mtd.c:35:4: error: 'MTD_OPS_RAW' undeclared here (not in a function) > > mtd.c:47:4: error: 'MTD_MLCNANDFLASH' undeclared here (not in a function) > > yeah, i wrote it to the stuff exported in linux-3.3 > > > So I suppose it would be safer to provide a local copy. > > hrm, i could do: > #include > #if KERNEL_VERSION(3, 3, 0) < LINUX_VERSION_CODE > # include "mtd-user.h" > #else > # include > #endif > > this should give us the best of both worlds ? Yes, at least it looks so. -- ldv pgpZEg5j9BLm9.pgp Description: PGP signature -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] fix indefinite hang on no-mmu systems
On Thu, Apr 05, 2012 at 01:52:25AM -0400, Mike Frysinger wrote: > The ptrace setoptions code will fork a child which goes to sleep and > expects the parent to continue on to do tests. Unfortunately, this > does not work on no-mmu systems as fork() is actually vfork() and any > vforked children will hang the parent until it exits or execs. > > We might be able to make this test work on no-mmu systems with a bit > of work, but easier to just disable this for the release so it works > now. > > * strace.c (test_ptrace_setoptions_for_all): Return if strace_vforked. Applied, thanks. -- ldv pgp2C3SVuIVHs.pgp Description: PGP signature -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v4] decode mtd ioctls
On Wed, Apr 04, 2012 at 10:22:01PM -0400, Mike Frysinger wrote: > I got tired of figuring out mtd structures (which show up a lot > in the embedded space), so add decoders for those ioctls. > > * defs.h (mtd_ioctl): New prototype. > (print_loff_t): Likewise. > * io.c (print_loff_t): Delete static keyword > * ioctl.c (ioctl_decode): Call mtd_ioctl when code is 'M'. > * Makefile.am (strace_SOURCES): Add mtd.c. > (EXTRA_DIST): Add linux/mtd-abi.h. > * mtd.c: New file. > * linux/mtd-abi.h: New file. Applied, thanks. -- ldv pgpsNQtxLOcJF.pgp Description: PGP signature -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: PATCH: Add x32 support to strace
On Sun, Apr 15, 2012 at 07:09:02PM -0700, H.J. Lu wrote: > --- a/configure.ac > +++ b/configure.ac > @@ -8,6 +8,11 @@ AM_INIT_AUTOMAKE([foreign check-news dist-xz no-dist-gzip > silent-rules]) > AM_MAINTAINER_MODE > AC_CANONICAL_HOST > > +AC_PROG_CC > +AC_GNU_SOURCE > + > +AC_USE_SYSTEM_EXTENSIONS > + The use of AC_GNU_SOURCE along with AC_USE_SYSTEM_EXTENSIONS is a bit more redundant than necessary. -- ldv pgpb8M8OusOtV.pgp Description: PGP signature -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] Cast clock_t type to unsigned long
Hi, On Mon, Apr 16, 2012 at 07:39:58AM -0700, H.J. Lu wrote: > On Sun, Apr 15, 2012 at 11:17:13AM -0700, H.J. Lu wrote: > > > > Linux kernel v3.4 adds x32 support whose clock_t is long long. This > > patch casts clock_t type to unsigned long for "%lu". > > > > H.J. > > --- > > Here is a patch to case clock_t type to unsigned long long. What about other cases where clock_t type is printed? -- ldv pgpCJuajDee9z.pgp Description: PGP signature -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] Cast clock_t type to unsigned long
On Mon, Apr 16, 2012 at 08:31:46AM -0700, H.J. Lu wrote: > On Mon, Apr 16, 2012 at 8:14 AM, Dmitry V. Levin wrote: > > On Mon, Apr 16, 2012 at 07:39:58AM -0700, H.J. Lu wrote: > >> On Sun, Apr 15, 2012 at 11:17:13AM -0700, H.J. Lu wrote: > >> > > >> > Linux kernel v3.4 adds x32 support whose clock_t is long long. This > >> > patch casts clock_t type to unsigned long for "%lu". > >> > > >> > H.J. > >> > --- > >> > >> Here is a patch to case clock_t type to unsigned long long. > > > > What about other cases where clock_t type is printed? > > Here is a patch to use unsigned long long for clock_t in resource.c > and signal.c Thanks, applied. -- ldv pgpXCj5DTyuC3.pgp Description: PGP signature -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: PATCH: Add ia32 support to x32 strace
On Tue, Apr 17, 2012 at 11:05:04AM -0700, H.J. Lu wrote:
> Hi,
>
> This patch adds ia32 support to x32 strace. Tested on Linux/x32.
[...]
> @@ -868,15 +874,14 @@ get_scno(struct tcb *tcp)
> }
> # endif
> # ifdef X32
> - if (currpers == 0 || currpers == 1) {
> - fprintf(stderr, "syscall_%lu (...) in unsupported %s "
> - "mode of process PID=%d\n", scno,
> - currpers == 0 ? "64-bit" : "32-bit", tcp->pid);
> + if (currpers == 0) {
> + fprintf(stderr, "syscall_%lu (...) in unsupported 64-bit "
> + "mode of process PID=%d\n", scno, tcp->pid);
> return 0;
> }
> -# else
> - update_personality(tcp, currpers);
> + else if (currpers == 1)
> # endif
> + update_personality(tcp, currpers);
> #elif defined(IA64)
> #define IA64_PSR_IS ((long)1 << 34)
> if (upeek(tcp, PT_CR_IPSR, &psr) >= 0)
This part of the change seems to be wrong: if strace supports two personalities
on X32, it should be able to switch to any of them, not just to
currpers == 1. Looks like additional currpers translation is needed for
the X32 case.
--
ldv
pgpuOXBWE6Qo5.pgp
Description: PGP signature
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: PATCH: Add ia32 support to x32 strace
On Tue, Apr 17, 2012 at 05:03:20PM -0700, H.J. Lu wrote:
> On Tue, Apr 17, 2012 at 4:58 PM, Dmitry V. Levin wrote:
> > On Tue, Apr 17, 2012 at 11:05:04AM -0700, H.J. Lu wrote:
> >> Hi,
> >>
> >> This patch adds ia32 support to x32 strace. Tested on Linux/x32.
> > [...]
> >> @@ -868,15 +874,14 @@ get_scno(struct tcb *tcp)
> >> }
> >> # endif
> >> # ifdef X32
> >> - if (currpers == 0 || currpers == 1) {
> >> - fprintf(stderr, "syscall_%lu (...) in unsupported %s "
> >> - "mode of process PID=%d\n", scno,
> >> - currpers == 0 ? "64-bit" : "32-bit", tcp->pid);
> >> + if (currpers == 0) {
> >> + fprintf(stderr, "syscall_%lu (...) in unsupported 64-bit "
> >> + "mode of process PID=%d\n", scno, tcp->pid);
> >> return 0;
> >> }
> >> -# else
> >> - update_personality(tcp, currpers);
> >> + else if (currpers == 1)
> >> # endif
> >> + update_personality(tcp, currpers);
> >> #elif defined(IA64)
> >> # define IA64_PSR_IS ((long)1 << 34)
> >> if (upeek(tcp, PT_CR_IPSR, &psr) >= 0)
> >
> > This part of the change seems to be wrong: if strace supports two
> > personalities
> > on X32, it should be able to switch to any of them, not just to
> > currpers == 1. Looks like additional currpers translation is needed for
> > the X32 case.
>
> currpers is set the same value for both x32 and x86-64 strace,
>
> 0: x86-64
> 1: ia32
> 2. x32
>
> For x32 strace, when currpers == 1, we call update_personality to update
> personality. When currpers == 2, we do nothing since the current
> personality is x32.
We have to handle the case when currpers == 2 and current_personality == 1.
Supposing that currpers == 2 on X32 translates to current_personality == 0,
we have to call update_personality(tcp, 0) in that case.
--
ldv
pgprf2USEDwCs.pgp
Description: PGP signature
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] Decode /dev/loop ioctls
On Tue, Apr 17, 2012 at 04:36:12PM -0400, Mike Frysinger wrote:
> Needed to debug some losetup failures, and it's easier when you can see
> what the kernel is getting vs what you think you're sending, so add some
> decoders for those ioctls.
Thanks.
[...]
> + if (!abbrev(tcp)) {
> + tprintf("device=%" PRIi64 ", inode=%" PRIi64 ", "
> + "rdevice=%" PRIi64 ", offset=%#" PRIx64 ", "
> + "sizelimit=%" PRIi64 ", number=%" PRIi32,
> + (uint64_t) info64.lo_device,
> + (uint64_t) info64.lo_inode,
> + (uint64_t) info64.lo_rdevice,
> + (uint64_t) info64.lo_offset,
> + (uint64_t) info64.lo_sizelimit,
> + (uint32_t) info64.lo_number);
> + } else {
We can have more consistency here, e.g. natural printing format specifiers
for uint64_t are PRIu64 and PRIx64, while PRIi64 is more appropriate for
the signed type.
--
ldv
pgpB8TZmKR2lF.pgp
Description: PGP signature
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: PATCH: Add ia32 support to x32 strace
On Tue, Apr 17, 2012 at 05:39:28PM -0700, H.J. Lu wrote:
> On Tue, Apr 17, 2012 at 5:13 PM, Dmitry V. Levin wrote:
> > On Tue, Apr 17, 2012 at 05:03:20PM -0700, H.J. Lu wrote:
> >> On Tue, Apr 17, 2012 at 4:58 PM, Dmitry V. Levin wrote:
> >> > On Tue, Apr 17, 2012 at 11:05:04AM -0700, H.J. Lu wrote:
> >> >> Hi,
> >> >>
> >> >> This patch adds ia32 support to x32 strace. Tested on Linux/x32.
> >> > [...]
> >> >> @@ -868,15 +874,14 @@ get_scno(struct tcb *tcp)
> >> >> }
> >> >> # endif
> >> >> # ifdef X32
> >> >> - if (currpers == 0 || currpers == 1) {
> >> >> - fprintf(stderr, "syscall_%lu (...) in unsupported %s "
> >> >> - "mode of process PID=%d\n", scno,
> >> >> - currpers == 0 ? "64-bit" : "32-bit", tcp->pid);
> >> >> + if (currpers == 0) {
> >> >> + fprintf(stderr, "syscall_%lu (...) in unsupported 64-bit "
> >> >> + "mode of process PID=%d\n", scno, tcp->pid);
> >> >> return 0;
> >> >> }
> >> >> -# else
> >> >> - update_personality(tcp, currpers);
> >> >> + else if (currpers == 1)
> >> >> # endif
> >> >> + update_personality(tcp, currpers);
> >> >> #elif defined(IA64)
> >> >> # define IA64_PSR_IS ((long)1 << 34)
> >> >> if (upeek(tcp, PT_CR_IPSR, &psr) >= 0)
> >> >
> >> > This part of the change seems to be wrong: if strace supports two
> >> > personalities
> >> > on X32, it should be able to switch to any of them, not just to
> >> > currpers == 1. Looks like additional currpers translation is needed for
> >> > the X32 case.
> >>
> >> currpers is set the same value for both x32 and x86-64 strace,
> >>
> >> 0: x86-64
> >> 1: ia32
> >> 2. x32
> >>
> >> For x32 strace, when currpers == 1, we call update_personality to update
> >> personality. When currpers == 2, we do nothing since the current
> >> personality is x32.
> >
> > We have to handle the case when currpers == 2 and current_personality == 1.
> > Supposing that currpers == 2 on X32 translates to current_personality == 0,
> > we have to call update_personality(tcp, 0) in that case.
> >
>
> Here is the updated patch to set currpers == 0 for x32.
Converted those two "if" statements to a "switch" and applied. Thanks.
--
ldv
pgpYq1OXdAWir.pgp
Description: PGP signature
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v2] Decode /dev/loop ioctls
On Tue, Apr 17, 2012 at 10:19:31PM -0400, Mike Frysinger wrote:
> Needed to debug some losetup failures, and it's easier when you can see
> what the kernel is getting vs what you think you're sending, so add some
> decoders for those ioctls.
Applied, thanks.
[...]
> + if (!abbrev(tcp) || info.lo_encrypt_type != LO_CRYPT_NONE) {
> + string_quote((void *) info.lo_encrypt_key, s, 0,
> LO_KEY_SIZE);
> + tprintf(", encrypt_key=%s", s);
> + }
[...]
> + if (!abbrev(tcp) || info64.lo_encrypt_type != LO_CRYPT_NONE) {
> + string_quote((void *) info64.lo_crypt_name, s, -1,
> LO_NAME_SIZE);
> + tprintf(", crypt_name=%s", s);
> + string_quote((void *) info64.lo_encrypt_key, s, 0,
> LO_KEY_SIZE);
> + tprintf(", encrypt_key=%s", s);
> + }
I'm not sure the LO_CRYPT_NONE case worth decoding even in verbose mode.
If the kernel ignores this data, what kind of help for debugging could
it be?
--
ldv
pgpQfNPKuTwrV.pgp
Description: PGP signature
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: strace sys_pread / sys_pwrite : double definition
Hi, On Thu, Apr 26, 2012 at 01:52:28PM +0100, dark_footix wrote: > Hello Strace, > > Do you have a bugzilla ? It's perfectly fine to report bugs in strace to this mailing list. > There is an issue of compilation on the release 4.6, with > > ../strace-4.6/io.c:356:1: error: redefinition of 'sys_pread' > ../strace-4.6/io.c:281:1: note: previous definition of 'sys_pread' was here > ../strace-4.6/io.c:373:1: error: redefinition of 'sys_pwrite' > ../strace-4.6/io.c:298:1: note: previous definition of 'sys_pwrite' was here I believe this issue was fixed by commit v4.6-221-g309edeb. Please try to build strace from HEAD (git://strace.git.sourceforge.net/gitroot/strace/strace.git) which is going to be released as 4.7 soon. -- ldv pgpXuE3kLbV6H.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Wed, Apr 04, 2012 at 03:38:06AM +0400, Dmitry V. Levin wrote: > On Mon, Apr 02, 2012 at 11:26:06PM -0400, Mike Frysinger wrote: > > On Monday 12 March 2012 17:50:48 Dmitry V. Levin wrote: > > > There is quite enough good stuff accumulated in strace.git since v4.6 to > > > have a new release soon. If there are no objections, here is a list of > > > pre-release work to be done for this release: > > > > > > - merge pending patches if any (please speak up); > > > - test on supported non-x86 architectures; > > > - update the NEWS file; > > > - sync and update strace.spec and debian/* files. > > > > anything still pending ? > > The NEWS file; unfortunately, it was not updated since v4.6, and we now > have some 371 commits to be condensed into the list of noteworthy changes. > Well, I cannot be excused from completing this task anyway, just let me a > bit more time. I've finally managed to review all those commits and update the NEWS file. Of course I could miss something, so please have a look. I suggest to test HEAD once more on available architectures, to ensure that we haven't accidentally broken something last month. If there are no regressions, we could release 4.7 in the middle of the next week. -- ldv pgpVBFQvqCgqI.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] cast current_wordsize to an int
On Fri, Apr 27, 2012 at 06:58:20PM -0400, Mike Frysinger wrote: > On 64bit systems with a single personality, we see: > count.c: In function 'call_summary': > count.c:223:5: warning: format '%u' expects type 'unsigned int', > but argument 3 has type 'long unsigned int' > > Since on multi-personality systems this is an array of ints, cast > the multiplication to an int and update the printf format. > > * count.c (call_summary): Change %u to %i and cast first argument to int. strace code traditionally uses %d variant, so I've applied the fix with %i replaced by %d for consistency. -- ldv pgp0eDNnKwktG.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] NEWS: clarify & fix typo
On Fri, Apr 27, 2012 at 07:13:55PM -0400, Mike Frysinger wrote: > NEWS |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Thanks. -- ldv pgpNpUCt3TGub.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [SCM] strace branch, master, updated. v4.6-390-g3efa7c7
On Sat, Apr 28, 2012 at 03:01:15PM +, Denys Vlasenko wrote:
[...]
> - Log -
> commit 3efa7c7f1be0f54e0656de5cb4a5f4c39db10150
> Author: Denys Vlasenko
> Date: Sat Apr 28 16:59:47 2012 +0200
>
> Enable printing of uts.domainname in uname syscall
>
> * process.c (sys_uname): Enable printing of uts.domainname
>
> Signed-off-by: Denys Vlasenko
>
> ---
>
> Summary of changes:
> process.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/process.c b/process.c
> index 2fb6c92..8824abd 100644
> --- a/process.c
> +++ b/process.c
> @@ -1170,13 +1170,12 @@ sys_uname(struct tcb *tcp)
> else if (umove(tcp, tcp->u_arg[0], &uname) < 0)
> tprints("{...}");
> else if (!abbrev(tcp)) {
> -
> tprintf("{sysname=\"%s\", nodename=\"%s\", ",
> uname.sysname, uname.nodename);
> tprintf("release=\"%s\", version=\"%s\", ",
> uname.release, uname.version);
> tprintf("machine=\"%s\"", uname.machine);
> -#ifndef __GLIBC__
> +#if defined(_GNU_SOURCE) && defined(__GLIBC__)
> tprintf(", domainname=\"%s\"", uname.domainname);
> #endif
> tprints("}");
This change, besides enabling uts.domainname printing on __GLIBC__, also
disables it on non-__GLIBC__ which is hardly justifiable. I suppose a
configure check would be more appropriate for this case.
--
ldv
pgpwUB9qIUbdE.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: upcoming release: what needs to be done
On Sat, Apr 28, 2012 at 05:18:47PM -0400, Mike Frysinger wrote: > On Friday 27 April 2012 19:21:26 Mike Frysinger wrote: > > my sh/sparc boxes are offline atm ... need to get someone to kick them. > > i recovered the sh box. `make check` failed because the timeout in strace-f > was too low. it's a slow machine :(. once i upped it to 60 seconds, it > passed fine. Thanks, raised tests timeout to 60 seconds. -- ldv pgpkgxMxP1rn7.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [SCM] strace branch, master, updated. v4.6-390-g3efa7c7
On Tue, May 01, 2012 at 09:55:56PM +0400, Dmitry V. Levin wrote:
> On Sat, Apr 28, 2012 at 03:01:15PM +, Denys Vlasenko wrote:
> [...]
> > - Log -
> > commit 3efa7c7f1be0f54e0656de5cb4a5f4c39db10150
> > Author: Denys Vlasenko
> > Date: Sat Apr 28 16:59:47 2012 +0200
> >
> > Enable printing of uts.domainname in uname syscall
> >
> > * process.c (sys_uname): Enable printing of uts.domainname
> >
> > Signed-off-by: Denys Vlasenko
> >
> > ---
> >
> > Summary of changes:
> > process.c |3 +--
> > 1 files changed, 1 insertions(+), 2 deletions(-)
> >
> > diff --git a/process.c b/process.c
> > index 2fb6c92..8824abd 100644
> > --- a/process.c
> > +++ b/process.c
> > @@ -1170,13 +1170,12 @@ sys_uname(struct tcb *tcp)
> > else if (umove(tcp, tcp->u_arg[0], &uname) < 0)
> > tprints("{...}");
> > else if (!abbrev(tcp)) {
> > -
> > tprintf("{sysname=\"%s\", nodename=\"%s\", ",
> > uname.sysname, uname.nodename);
> > tprintf("release=\"%s\", version=\"%s\", ",
> > uname.release, uname.version);
> > tprintf("machine=\"%s\"", uname.machine);
> > -#ifndef __GLIBC__
> > +#if defined(_GNU_SOURCE) && defined(__GLIBC__)
> > tprintf(", domainname=\"%s\"", uname.domainname);
> > #endif
> > tprints("}");
>
> This change, besides enabling uts.domainname printing on __GLIBC__, also
> disables it on non-__GLIBC__ which is hardly justifiable. I suppose a
> configure check would be more appropriate for this case.
I've changed it to a configure check.
--
ldv
pgpfOlUxUL93a.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v2] Decode /dev/loop ioctls
On Tue, Apr 17, 2012 at 10:19:31PM -0400, Mike Frysinger wrote: > Needed to debug some losetup failures, and it's easier when you can see > what the kernel is getting vs what you think you're sending, so add some > decoders for those ioctls. > > * defs.h (loop_ioctl): New prototype. > (string_quote): Likewise. > * ioctl.c (ioctl_decode): Call loop_ioctl when code is 'L'. > * Makefile.am (strace_SOURCES): Add loop.c. > * loop.c: New file. > * util.c (string_quote): Delete static keyword On a system with quite old file from some 2.6.18-derived kernel headers I've got a build failure: loop.c:36:4: error: 'LO_FLAGS_AUTOCLEAR' undeclared here (not in a function) loop.c: In function 'loop_ioctl': loop.c:167:7: error: 'LOOP_SET_CAPACITY' undeclared (first use in this function) loop.c:167:7: note: each undeclared identifier is reported only once for each function it appears in -- ldv pgpwSGVclJXlg.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v2] Decode /dev/loop ioctls
On Wed, May 02, 2012 at 02:09:55PM +0400, Dmitry V. Levin wrote: > On Tue, Apr 17, 2012 at 10:19:31PM -0400, Mike Frysinger wrote: > > Needed to debug some losetup failures, and it's easier when you can see > > what the kernel is getting vs what you think you're sending, so add some > > decoders for those ioctls. > > > > * defs.h (loop_ioctl): New prototype. > > (string_quote): Likewise. > > * ioctl.c (ioctl_decode): Call loop_ioctl when code is 'L'. > > * Makefile.am (strace_SOURCES): Add loop.c. > > * loop.c: New file. > > * util.c (string_quote): Delete static keyword > > On a system with quite old file from some 2.6.18-derived > kernel headers I've got a build failure: > > loop.c:36:4: error: 'LO_FLAGS_AUTOCLEAR' undeclared here (not in a function) > loop.c: In function 'loop_ioctl': > loop.c:167:7: error: 'LOOP_SET_CAPACITY' undeclared (first use in this > function) > loop.c:167:7: note: each undeclared identifier is reported only once for each > function it appears in I've pushed a fix. -- ldv pgpKVRByCqCE5.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v2] Decode /dev/loop ioctls
On Wed, May 02, 2012 at 11:54:19AM -0400, Mike Frysinger wrote: > On Wednesday 02 May 2012 06:38:44 Dmitry V. Levin wrote: > > On Wed, May 02, 2012 at 02:09:55PM +0400, Dmitry V. Levin wrote: > > > On Tue, Apr 17, 2012 at 10:19:31PM -0400, Mike Frysinger wrote: > > > > Needed to debug some losetup failures, and it's easier when you can see > > > > what the kernel is getting vs what you think you're sending, so add > > > > some decoders for those ioctls. > > > > > > > > * defs.h (loop_ioctl): New prototype. > > > > (string_quote): Likewise. > > > > * ioctl.c (ioctl_decode): Call loop_ioctl when code is 'L'. > > > > * Makefile.am (strace_SOURCES): Add loop.c. > > > > * loop.c: New file. > > > > * util.c (string_quote): Delete static keyword > > > > > > On a system with quite old file from some 2.6.18-derived > > > kernel headers I've got a build failure: > > > > > > loop.c:36:4: error: 'LO_FLAGS_AUTOCLEAR' undeclared here (not in a > > > function) loop.c: In function 'loop_ioctl': > > > loop.c:167:7: error: 'LOOP_SET_CAPACITY' undeclared (first use in this > > > function) loop.c:167:7: note: each undeclared identifier is reported > > > only once for each function it appears in > > > > I've pushed a fix. > > i'm not sure if the configure test is really needed. seems like overkill > since > we're going to be using #ifdef in the source regardless. Not all these constants could be #ifdef'ed directly. For example, LO_FLAGS_AUTOCLEAR and LO_FLAGS_PARTSCAN are enums. The build fix also fixed LO_FLAGS_PARTSCAN recognition on systems where it is defined. -- ldv pgprpqBPH8lwz.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
strace 4.7 released
On Fri, Apr 27, 2012 at 09:59:23PM +0400, Dmitry V. Levin wrote: [...] > I suggest to test HEAD once more on available architectures, to ensure that > we haven't accidentally broken something last month. If there are no > regressions, we could release 4.7 in the middle of the next week. strace 4.7 is tagged and uploaded. I'd like to use this opportunity to thank all who contributed to this release. $ git log v4.6..v4.7 | git shortlog -s 2 Andi Kleen 3 Andreas Schwab 1 Anton Blanchard 1 Damir Shayhutdinov 251 Denys Vlasenko 116 Dmitry V. Levin 1 Grant Edwards 11 H.J. Lu 1 Heiko Carstens 12 Mike Frysinger 1 Sergei Trofimovich -- ldv pgpdjIW4WqCQQ.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
on updating NEWS file
On Fri, Apr 27, 2012 at 09:59:23PM +0400, Dmitry V. Levin wrote: > On Wed, Apr 04, 2012 at 03:38:06AM +0400, Dmitry V. Levin wrote: > > On Mon, Apr 02, 2012 at 11:26:06PM -0400, Mike Frysinger wrote: [...] > > > anything still pending ? > > > > The NEWS file; unfortunately, it was not updated since v4.6, and we now > > have some 371 commits to be condensed into the list of noteworthy changes. > > Well, I cannot be excused from completing this task anyway, just let me a > > bit more time. > > I've finally managed to review all those commits and update the NEWS file. > Of course I could miss something, so please have a look. The generally accepted solution is to update NEWS along with committing noteworthy changes. I see no reason why strace project shouldn't accept it, too. -- ldv pgp5kLs7ue1Pq.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: strace -f (v4.7) randomly failing on grsecurity and Ubuntu kernels
Hi,
On Tue, May 08, 2012 at 07:43:28PM -0400, Brad Spengler wrote:
> Hi guys,
>
> I'm writing to report this before the recent release sees more
> widespread use. I've already had one report from a user of strace v4.7
> failing on a grsecurity kernel when run with the -f argument. Strace
> (due to what IMO is a bug) is randomly conflicting with a feature of
> grsecurity that prevents ptracing processes other than one's decendents.
> Since Ubuntu's kernel carries the same logic/algorithm as grsecurity
> through the Yama module, strace will likewise fail on their kernels.
>
> I've investigated the problem a bit. The failing code (in strace.c) is:
>if (tracee_pid != pid) {
> found_grandchild = tracee_pid;
> if (ptrace(PTRACE_CONT, tracee_pid, 0, 0) < 0) {
> kill_save_errno(tracee_pid, SIGKILL);
> kill_save_errno(pid, SIGKILL);
> perror_msg_and_die("PTRACE_CONT doesn't
> work");
> }
> continue;
> }
>
> This happens because of the raciness of the following code (in strace.c):
> if (pid == 0) {
> pid = getpid();
> if (ptrace(PTRACE_TRACEME, 0L, 0L, 0L) < 0)
> perror_msg_and_die("%s: PTRACE_TRACEME doesn't work",
>__func__);
> kill_save_errno(pid, SIGSTOP);
> if (fork() < 0)
> perror_msg_and_die("fork");
> _exit(0);
> }
>
> Sometimes the child exits before the PTRACE_CONT is issued against the
> grandchild, while other times the child exits after. If the child exits
> after, there are no issues, as the grandchild keeps its descendent
> relation to the ptracing grandparent. If the child exits before,
> however, it gets reparented to init, breaking the ability to walk back
> through the ancestors of the grandchild to reach the (previous)
> grandparent. Because of this, grsecurity (and Ubuntu) will deny the
> ptrace to the grandchild.
The code in strace.c you are talking about is
test_ptrace_setoptions_followfork function, which is a runtime test for
kernel features. There is no problem to add a wait call in this test to
make grsec kernels happy, but the problem may arise in real code anyway.
If grsec disallows PTRACE_CONT'ing already attached processes just because
they were re-parented to init, then grsec changes ptrace semantics and
strace is hardly expected to work properly in such circumstances.
I wonder is there a rationale for such a restriction? What kind of
extra security risk could be caused by allowing ptrace of already
attached processes?
--
ldv
pgpdnFUmvE72f.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: strace shows unknown syscall newfstatat.
On Thu, May 10, 2012 at 06:01:01PM +0600, Марк Коренберг wrote:
> There is no such syscall. May be you mean fstatat64()?
strace$ git grep -E 'newfstatat|fstatat64' linux/i386/ linux/x86_64/
linux/i386/syscallent.h:{ 4,TD|TF, sys_newfstatat,
"fstatat64" }, /* 300 */
linux/x86_64/syscallent.h: { 4,TD|TF, sys_newfstatat,
"newfstatat"}, /* 262 */
linux$ git grep -E 'newfstatat|fstatat64' arch/x86/syscalls
arch/x86/syscalls:syscall_32.tbl:300i386fstatat64
sys_fstatat64 sys32_fstatat
arch/x86/syscalls:syscall_64.tbl:26264 newfstatat
sys_newfstatat
That is, strace just follows the kernel. If you don't like
syscall names, please speak to kernel folks.
--
ldv
pgpew8kqGbiRY.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] Modify the OS string parsing to handle two number strings
On Mon, May 14, 2012 at 10:34:46PM +1000, Bryce Gibson wrote:
> Modify OS string parsing to handle a two character OS string.
> If a shorter than expected OS string is found, pad a zero on the end and then
> try the comparison.
> ---
> strace.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/strace.c b/strace.c
> index 857136d..2bc8d59 100644
> --- a/strace.c
> +++ b/strace.c
> @@ -1432,6 +1432,11 @@ get_os_release(void)
> break;
> while (*p >= '0' && *p = KERNEL_VERSION(1,0,0))
> + break;
> + }
> if (*p != '.')
> error_msg_and_die("Bad OS release string: '%s'", u.release);
> p++;
Sorry, it is not a patch. How about this one:
diff --git a/strace.c b/strace.c
index 857136d..65dee7d 100644
--- a/strace.c
+++ b/strace.c
@@ -1432,8 +1432,14 @@ get_os_release(void)
break;
while (*p >= '0' && *p <= '9')
p++;
- if (*p != '.')
+ if (*p != '.') {
+ if (rel >= KERNEL_VERSION(0,1,0)) {
+ /* "X.Y-something" means "X.Y.0" */
+ rel <<= 8;
+ break;
+ }
error_msg_and_die("Bad OS release string: '%s'",
u.release);
+ }
p++;
}
return rel;
--
ldv
pgpORK1oV9kZu.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: strace scheduling fairness
On Tue, May 15, 2012 at 05:09:21PM +0200, Denys Vlasenko wrote:
> #include
> #include
> #include
> #define NTHD 10
> static int thd_no;
> static void *sub_thd(void *c) {
> printf("thread created: %d\n", ++thd_no);
> for (;;) getuid();
> return NULL;
> }
> int main(int argc, char **argv) {
> int i;
> pthread_t thd;
> for (i = 0; i < NTHD; i++)
> pthread_create(&thd, NULL, sub_thd, NULL);
> sleep(1);
> return 0;
> }
>
> The above program runs like this:
>
> $ gcc -lpthread -Wall test.c
> $ ./a.out
> thread created: 3
> thread created: 1
> thread created: 2
> thread created: 4
> thread created: 6
> thread created: 7
> thread created: 8
> thread created: 5
> thread created: 9
> thread created: 10
>
> But under strace it most of the time never finishes:
>
> $ strace -f -o /dev/null ./a.out
> thread created: 1
> thread created: 2
> thread created: 3
> thread created: 4
> <...big pause...>
> thread created: 5
> <...waits forever...>
>
> Testcase essentially starts threads, each if which does this:
>
> for (;;) getuid();
>
> Since getuid is a very cheap syscall, it finishes very quickly.
>
> When there are 2-3 such threads, strace's waitpid() picks up one, restarts it,
> picks another, restarts it, ...and meanwhile first thread stops again at
> syscall entry/exit and is ready to be picked up again.
>
> It may happen so that the very first thread, which starts all others, even
> though it is also ready to be handled by strace, will never be picked up
> because there is always at least one other getuid'ing thread, and that thread
> gets picked up instead.
>
> One solution is to run waitpid() in a loop until it returns 0 "no more tracees
> to wait", then handle them all. It was NAKed a few years ago.
It would be nice to have a look at that discussion. Do you have a
reference? What was the rationale that time?
> Do we want to fix it, of do we chalk it to
> "thread scheduling fairness is busted up under strace, won't fix"?
If the fix has no drawbacks, I'd rather have it fixed.
--
ldv
pgpI7g9pMwXLv.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: strace scheduling fairness
On Wed, May 16, 2012 at 12:47:14PM +0200, Denys Vlasenko wrote: > On 05/16/2012 11:48 AM, Dmitry V. Levin wrote: [...] > >> One solution is to run waitpid() in a loop until it returns 0 "no more > >> tracees > >> to wait", then handle them all. It was NAKed a few years ago. > > > > It would be nice to have a look at that discussion. Do you have a > > reference? What was the rationale that time? > > I guess Roland saw it as "ugly" and "trying to work around ptrace API > which is a hopelessly bad API anyway". > > On the technical note, it adds additional waitpid call per every > syscall entry/exit, So its cost is quite noticeable, and therefore this fair scheduling is not always desirable. Is it possible to implement the feature as an option? -- ldv pgpAL3m1QJFk5.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: missing clock_gettime constants
On Sun, May 20, 2012 at 12:15:24AM +0600, Марк Коренберг wrote:
> clock_gettime(0x4 /* CLOCK_??? */, {190897, 528960021}) = 0
>
> in my case, it was CLOCK_MONOTONIC_RAW.
>
> It will be nice if someone adds all known clock_gettime constants to strace.
Some constants (including CLOCK_MONOTONIC_RAW) were added by commit
v4.5.20-32-gcbaaf79. strace expects to define all these
constants, which e.g. glibc does since release 2.12.
--
ldv
pgp8fxJjSETZr.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] x32: update syscall table
On Mon, Jun 04, 2012 at 02:01:59PM -0400, Mike Frysinger wrote: > This syncs with the syscall table as it is in linux 3.4. > > * linux/x32/syscallent.h (59): Fix comment typo. > (78): Add missing getdents entry. > (174): Delete create_module entry (not in the kernel). > (181, 182, 183, 184, 185): Add missing entries. > (524, 536, 539, 540): Fix spacing. Applied, thanks. -- ldv pgpUaUPx32a64.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Q: drop PTRACE_SEIZE_DEVEL?
On Mon, Mar 12, 2012 at 01:26:35PM +0100, Denys Vlasenko wrote: > On 03/10/2012 11:17 PM, Dmitry V. Levin wrote: > > On Thu, Feb 09, 2012 at 07:38:27PM +0100, Denys Vlasenko wrote: > >> On 02/09/2012 05:29 PM, Dmitry V. Levin wrote: > >>> But I'd like to hear from Denys about PTRACE_SEIZE perspective first. > >>> We surely won't release PTRACE_SEIZE_DEVEL code enabled by default because > >>> the kernel API might change. > >> > >> I'm going to ask kernel people to drop PTRACE_SEIZE_DEVEL. > > > > The patch was submitted in February, but current v3.3-rc6-240-gc7b2855 > > still insists on PTRACE_SEIZE_DEVEL. Is there a prospect to release > > without PTRACE_SEIZE_DEVEL any time soon, or should we rather leave this > > experimental code disabled in the next release? > > It's in linux-next git: > > commit fe948360bf475b705c021fc9ba8ee3992c5d0d67 > Author: Denys Vlasenko > Date: Tue Mar 6 11:25:31 2012 +1100 > > ptrace: remove PTRACE_SEIZE_DEVEL bit > > PTRACE_SEIZE code is tested and ready for production use, remove the code > which requires special bit in data argument to make PTRACE_SEIZE work. > > Strace team prepares for a new release of strace, and we would like to > ship the code which uses PTRACE_SEIZE, preferably after this change goes > into released kernel. > > Signed-off-by: Denys Vlasenko > Acked-by: Tejun Heo > Acked-by: Oleg Nesterov > Cc: Pedro Alves > Cc: Jan Kratochvil > Signed-off-by: Andrew Morton > > Looks like this change will go into linux-3.4 I suppose we can safely drop PTRACE_SEIZE_DEVEL from USE_SEIZE code now. -- ldv pgppVFlyNEomB.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: How to detach if a process is setuid or setgid?
On Thu, Jul 19, 2012 at 03:31:51PM -0700, Aleatha Parker-Wood wrote: > I'm working with a modified version of strace to collect some information on > the long term behaviors of process trees and file system accesses. I've got > it logging data on a couple of different systems, some of which I do not > have root access to. Each of the users of the system spawns an strace > process which then traces all of their shell activity. > > However, since this is a long term tracing project, users will need to run > setuid or setgid executables from time to time. Rather than dropping those > bits silently (since strace is running as non-root), and breaking > functionality, I'd like to detect that the child process is doing setuid, > and detach from it, logging a message that there was an untraced child > process. > > Can you point me at the area of the code where the setuid bits on child > processes are handled? I'm assuming it's somewhere around startup_child(), > but I'm not spotting it. set[ug]id bits of executables are processed solely by kernel during execve(2), strace has no need to handle them: when a traced non-CAP_SETUID process calls execve(2) to execute a privileged executable, linux kernel silently resets euid to uid (and egid to gid). Of course you can modify your version of strace further to probe files passed to execve(2) and handle these bits, but that approach is inevitably racy and therefore is not reliable. -- ldv pgp3JgZFAte8k.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] x32: update {g,s}etsockopt syscall numbers
On Wed, Aug 22, 2012 at 11:56:15AM -0400, Mike Frysinger wrote: > Starting with linux 3.6 (and backported to earlier kernels), these two > syscalls have changed numbers (moving from native to compat entry points). > Update the strace syscall list accordingly. What will happen with applications using old syscall numbers (if any)? Will they get ENOSYS? > * linux/x32/syscallent.h: Move setsockopt from 54 to 541, and move > getsockopt from 55 to 542. > > Signed-off-by: Mike Frysinger > --- > Note: I'm not sure about the old entry points. Should they get relabeled > as "old" ? Or just leave them as is ? From one side, the rule is to stick to __NR_* names as close as possible. From another side, it's desirable to decode syscalls on older kernels properly. So maybe we should rather leave old entry points for compatibility. -- ldv pgpWYmzHOTTXY.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] x32: update {g,s}etsockopt syscall numbers
On Wed, Aug 22, 2012 at 02:51:33PM -0400, Mike Frysinger wrote:
> On Wednesday 22 August 2012 12:56:36 Dmitry V. Levin wrote:
> > On Wed, Aug 22, 2012 at 11:56:15AM -0400, Mike Frysinger wrote:
> > > Starting with linux 3.6 (and backported to earlier kernels), these two
> > > syscalls have changed numbers (moving from native to compat entry
> > > points). Update the strace syscall list accordingly.
> >
> > What will happen with applications using old syscall numbers (if any)?
> > Will they get ENOSYS?
>
> the 64bit and x32 syscall tables are shared. so you can call any of the
> 64bit
> syscalls from an x32 app, and vice versa. there are a few additional entry
> points which are really there just to map the x86 compat entry points which
> the x32 ABI uses (for when types are different sizes like pointers).
>
> for example, if we look at the rt_sigaction syscall, we see:
> 64bit's unisted.h sets the NR to 13
> x32's unistd.h sets the NR to 512
>
> nothing is stopping you from doing syscall(13) in an x32 app, or syscall(512)
> in a 64bit app. in either case, you won't get ENOSYS because they're both
> valid syscall entry points. but in most cases, the call won't "work" because
> the types being passed are wrong (which is why we've had to change the NRs
> here in the first place).
OK, I've pushed this commit as is.
> > > * linux/x32/syscallent.h: Move setsockopt from 54 to 541, and move
> > > getsockopt from 55 to 542.
> > >
> > > Signed-off-by: Mike Frysinger
> > > ---
> > > Note: I'm not sure about the old entry points. Should they get relabeled
> > > as "old" ? Or just leave them as is ?
> >
> > From one side, the rule is to stick to __NR_* names as close as possible.
> > From another side, it's desirable to decode syscalls on older kernels
> > properly. So maybe we should rather leave old entry points for
> > compatibility.
>
> should we fill out the entire table then ? with the rt_sigaction example
> above
> (which isn't the only one -- if you look at the x32 syscallent.h, pretty much
> every {} entry is in the same boat), we could label it as
> "64bit:rt_sigaction"
> or something similarly obvious that the x32 app is most likely doing
> something
> wrong. the other problem here is that we can't really decode these syscalls
> properly -- is the app passing up x32 structures (so the syscall will most
> likely fail anyways), or has it manually crafted a 64bit compatible structure
> and passing that up (which would be crazy and generally make no sense) ?
If there is a real chance to see these 64bit syscalls used by x32 apps (no
matter how crazy such apps are), would it be better to show syscall names
(e.g. with "64bit:" prefix) rather than their "syscall_*" names, even
without detailed decoding of these syscalls? What about setting
appropriate sys_flags in these syscall entries so that traditional syscall
filtering would work for them as well?
--
ldv
pgp1UnwLuzaqW.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Why "Close pipe and wait for the pipe process termination"?
Hi,
On Thu, Sep 13, 2012 at 09:55:43AM +0200, Denys Vlasenko wrote:
> Hi Dmitry,
>
> Why is the below change necessary?
> Was there any bad behavior in this area before it?
Before this change, strace used to exit before the pipe process
termination, there were no convenient method to wait for its
completion, and that behavior wasn't documented. As result,
strace users sometimes experienced unexpected data losses.
Is there any regressions with the change?
> commit cf53436f737c0273028503186fc0f837c7191085
> Author: Dmitry V. Levin
> Date: Thu Jul 12 20:54:46 2012 +
>
> Close pipe and wait for the pipe process termination
>
> In case of normal strace termination, when the trace output is
> redirected to a file or a pipe, close it and wait for the pipe
> process termination.
>
> * strace.c (main): Before normal exit, close shared_log when it
> differs from stderr, and wait for popen_pid termination.
>
> diff --git a/strace.c b/strace.c
> index e6d6d68..799fce5 100644
> --- a/strace.c
> +++ b/strace.c
> @@ -2214,6 +2214,12 @@ main(int argc, char *argv[])
>
> cleanup();
> fflush(NULL);
> + if (shared_log != stderr)
> + fclose(shared_log);
> + if (popen_pid) {
> + while (waitpid(popen_pid, NULL, 0) < 0 && errno == EINTR)
> + ;
> + }
> if (exit_code > 0xff) {
> /* Avoid potential core file clobbering. */
> struct rlimit rlim = {0, 0};
--
ldv
pgpywH2rvT8Zs.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
[RFC PATCH] Ignore fflush(3) return value
strace used to honor fflush(3) return value in trace_syscall_entering which resulted to tracees not being PTRACE_SYSCALL'ed which in turn caused nasty hangups like this one: $ strace -o'|:' pwd |:: Broken pipe There is little strace can do in case of fflush(3) returning EOF, and hangup is certainly not the best solution for the issue. * syscall.c (trace_syscall_entering): Ignore fflush(3) return value. --- syscall.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/syscall.c b/syscall.c index 52d742f..35f1608 100644 --- a/syscall.c +++ b/syscall.c @@ -1581,8 +1581,7 @@ trace_syscall_entering(struct tcb *tcp) else res = (*sysent[tcp->scno].sys_func)(tcp); - if (fflush(tcp->outf) == EOF) - return -1; + fflush(tcp->outf); ret: tcp->flags |= TCB_INSYSCALL; /* Measure the entrance time as late as possible to avoid errors. */ -- ldv pgpUuyv4jjFdE.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] x86_64/stat64: define struct stat64 as struct stat
On Wed, Oct 10, 2012 at 12:59:43PM +0100, Markos Chandras wrote: > From: Markos Chandras > > x86_64 does not define a struct stat64 in asm/stat.h. It uses > struct stat instead. > > This fixes a compilation problem when LFS is used > > file.c:1073:16: error: storage size of ‘statbuf’ isn’t known It means that, according to m4/long_long.m4, sizeof(off_t) > sizeof(long) on this x86_64 system. How could that be possible? -- ldv pgpWx7WjTugXF.pgp Description: PGP signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] x86_64/stat64: define struct stat64 as struct stat
On Wed, Oct 10, 2012 at 01:48:02PM +0100, Markos Chandras wrote: > On Wed, Oct 10, 2012 at 1:35 PM, Dmitry V. Levin wrote: > > On Wed, Oct 10, 2012 at 12:59:43PM +0100, Markos Chandras wrote: > >> From: Markos Chandras > >> > >> x86_64 does not define a struct stat64 in asm/stat.h. It uses > >> struct stat instead. > >> > >> This fixes a compilation problem when LFS is used > >> > >> file.c:1073:16: error: storage size of ‘statbuf’ isn’t known > > > > It means that, according to m4/long_long.m4, sizeof(off_t) > sizeof(long) > > on this x86_64 system. How could that be possible? > > Hi Dmitry, > > I am not sure what you are asking. This is a buildroot system > configured for x86_64. > > The build log is here: > http://autobuild.buildroot.net/results/bb66a3a06d26f558e1c4c0593bb68e7af1d82398/build-end.log It mentions strace 4.5.20 that was released 2.5 years ago. Please try to build strace 4.7 instead. -- ldv pgpPOZgCfdzax.pgp Description: PGP signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] x86_64/stat64: define struct stat64 as struct stat
On Wed, Oct 10, 2012 at 02:03:57PM +0100, Markos Chandras wrote: > On Wed, Oct 10, 2012 at 1:55 PM, Dmitry V. Levin wrote: > > On Wed, Oct 10, 2012 at 01:48:02PM +0100, Markos Chandras wrote: > >> On Wed, Oct 10, 2012 at 1:35 PM, Dmitry V. Levin wrote: > >> > On Wed, Oct 10, 2012 at 12:59:43PM +0100, Markos Chandras wrote: > >> >> From: Markos Chandras > >> >> > >> >> x86_64 does not define a struct stat64 in asm/stat.h. It uses > >> >> struct stat instead. > >> >> > >> >> This fixes a compilation problem when LFS is used > >> >> > >> >> file.c:1073:16: error: storage size of ‘statbuf’ isn’t known > >> > > >> > It means that, according to m4/long_long.m4, sizeof(off_t) > sizeof(long) > >> > on this x86_64 system. How could that be possible? > >> > >> Hi Dmitry, > >> > >> I am not sure what you are asking. This is a buildroot system > >> configured for x86_64. > >> > >> The build log is here: > >> http://autobuild.buildroot.net/results/bb66a3a06d26f558e1c4c0593bb68e7af1d82398/build-end.log > > > > It mentions strace 4.5.20 that was released 2.5 years ago. > > Please try to build strace 4.7 instead. > > The same problem happens with 4.7 and the patch that I submitted is > based on this version of strace Then the original question stands: how could it happen that HAVE_LONG_LONG_OFF_T is defined on your x86_64 system? -- ldv pgpZvr6SAu42k.pgp Description: PGP signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] x86_64/stat64: define struct stat64 as struct stat
On Wed, Oct 10, 2012 at 02:19:30PM +0100, Markos Chandras wrote: > On Wed, Oct 10, 2012 at 2:09 PM, Dmitry V. Levin wrote: > > On Wed, Oct 10, 2012 at 02:03:57PM +0100, Markos Chandras wrote: > >> On Wed, Oct 10, 2012 at 1:55 PM, Dmitry V. Levin wrote: > >> > On Wed, Oct 10, 2012 at 01:48:02PM +0100, Markos Chandras wrote: > >> >> On Wed, Oct 10, 2012 at 1:35 PM, Dmitry V. Levin > >> >> wrote: > >> >> > On Wed, Oct 10, 2012 at 12:59:43PM +0100, Markos Chandras wrote: > >> >> >> From: Markos Chandras > >> >> >> > >> >> >> x86_64 does not define a struct stat64 in asm/stat.h. It uses > >> >> >> struct stat instead. > >> >> >> > >> >> >> This fixes a compilation problem when LFS is used > >> >> >> > >> >> >> file.c:1073:16: error: storage size of ‘statbuf’ isn’t known > >> >> > > >> >> > It means that, according to m4/long_long.m4, sizeof(off_t) > > >> >> > sizeof(long) > >> >> > on this x86_64 system. How could that be possible? > >> >> > >> >> Hi Dmitry, > >> >> > >> >> I am not sure what you are asking. This is a buildroot system > >> >> configured for x86_64. > >> >> > >> >> The build log is here: > >> >> http://autobuild.buildroot.net/results/bb66a3a06d26f558e1c4c0593bb68e7af1d82398/build-end.log > >> > > >> > It mentions strace 4.5.20 that was released 2.5 years ago. > >> > Please try to build strace 4.7 instead. > >> > >> The same problem happens with 4.7 and the patch that I submitted is > >> based on this version of strace > > > > Then the original question stands: how could it happen that > > HAVE_LONG_LONG_OFF_T is defined on your x86_64 system? > > > I don't think it is defined, because if it was then this would have worked: You can have a syntax error with "struct stat64 statbuf" definition only if HAVE_STAT64 is defined but struct stat64 is not actually defined. Please provide a full strace build log. -- ldv pgpI5obu8wCF9.pgp Description: PGP signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [RFC] Add support for tracing memory related syscalls
Hi, On Thu, Oct 18, 2012 at 05:25:27PM +0900, Namhyung Kim wrote: > Hi, > > When I was debugging a memory related problem, I really want to see > only those syscalls but it wans't suppport by strace. Hence I decided > to create a patch. I guess others may want this too. > > This patch was made mostly by following script: The diffstat output is nice, but it doesn't substitute the patch itself. Could you send it to the list, please? -- ldv pgppt907uc4us.pgp Description: PGP signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] Add -e trace=memory option
On Fri, Oct 19, 2012 at 10:01:09AM +0900, Namhyung Kim wrote:
> Add a new 'memory' category for tracing memory related syscalls.
Most of syscalls are memory related because they take an address argument,
so I would rather call this subset as memory mapping related.
> Affected syscalls are: brk, mmap, munmap, mprotect, msync, mlock,
> munlock, mlockall, munlockall, mremap, mincore, madvise, mbind,
> {get,set}_mempolicy, migrate_pages, move_pages, vmsplice and
> remap_file_pages.
vmsplice is not a memory mapping related. I see it was not actually
changed by the patch.
I was able to reproduce the syscallent part of the patch with the
following command:
$ sed -ri
'/brk|get_mempolicy|madvise|mbind|migrate_pages|mincore|mlock|mlockall|mmap|move_pages|mprotect|mremap|msync|munlock|munlockall|munmap|remap_file_pages|set_mempolicy/
{s/^([^,]+,[[:space:]]*[NT][^,]+),/\1|TM,/; s/^([^,]+,[[:space:]]*)0,/\1TM,/}'
linux/*/syscallent.h
The short flag name (TM) defined in syscall.c has to be undefined the same way
as other short flag names.
Besides this, the patch looks OK.
> * defs.h: Define TRACE_MEMORY macro.
> * syscall.c (lookup_class): Handle "memory" option.
> * linux/alpha/syscallent.h: Add TM marker.
This is not a marker, it's a flag like TD or TF.
Something like "Add TM flag to memory mapping related syscalls" would do.
> * strace.1: Add description to man page.
Please make it less vague, e.g.
* syscall.c (lookup_class): Handle trace=memory option.
* strace.1: Document it.
--
ldv
pgp2FrpUuAVNM.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] Add -e trace=memory option
On Tue, Oct 23, 2012 at 06:01:16PM +0900, Namhyung Kim wrote:
> 2012-10-22 오전 4:25, Dmitry V. Levin 쓴 글:
> > On Fri, Oct 19, 2012 at 10:01:09AM +0900, Namhyung Kim wrote:
> >> Add a new 'memory' category for tracing memory related syscalls.
> >
> > Most of syscalls are memory related because they take an address argument,
> > so I would rather call this subset as memory mapping related.
> >
> >> Affected syscalls are: brk, mmap, munmap, mprotect, msync, mlock,
> >> munlock, mlockall, munlockall, mremap, mincore, madvise, mbind,
> >> {get,set}_mempolicy, migrate_pages, move_pages, vmsplice and
> >> remap_file_pages.
> >
> > vmsplice is not a memory mapping related. I see it was not actually
> > changed by the patch.
>
> It was my mistake of missing a comma. So do you want to get rid of it?
Since vmsplice was not affected by the change, there is no need to mention
it.
--
ldv
pgpYJLe7uGwGu.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] Update errno and ioctl definitions for newer Linux
On Tue, Oct 23, 2012 at 05:36:58PM +0100, Steve McIntyre wrote:
> Update errno and ioctl definitions for newer Linux
>
> Signed-off-by: Steve McIntyre
> ---
> linux/errnoent.h|4 +-
> linux/ioctlent.h.in | 121
> +++
> 2 files changed, 123 insertions(+), 2 deletions(-)
>
> diff --git a/linux/errnoent.h b/linux/errnoent.h
> index e43bff5..c2ac683 100644
> --- a/linux/errnoent.h
> +++ b/linux/errnoent.h
> @@ -519,8 +519,8 @@
> "ERESTARTNOHAND", /* 514 */
> "ENOIOCTLCMD", /* 515 */
> "ERESTART_RESTARTBLOCK", /* 516 */
> - "ERRNO_517", /* 517 */
> - "ERRNO_518", /* 518 */
> + "EPROBE_DEFER", /* 517 */
> + "EOPENSTALE", /* 518 */
> "ERRNO_519", /* 519 */
> "ERRNO_520", /* 520 */
> "EBADHANDLE", /* 521 */
This one is obvious. Please add a ChangeLog-style entry (see
README-hacking file for details) for this errnoent.h patch.
> diff --git a/linux/ioctlent.h.in b/linux/ioctlent.h.in
> index 98ebbcc..1ca126a 100644
> --- a/linux/ioctlent.h.in
> +++ b/linux/ioctlent.h.in
> @@ -2,6 +2,7 @@
> {"linux/fs.h", "FIBMAP", 0x0001},
> {"linux/fs.h", "FIGETBSZ", 0x0002},
> {"linux/fd.h", "FDGETPRM", 0x0204},
> + {"linux/fd.h", "FDGETPRM32", 0x0204},
I'm not sure such entries are worth adding. I know we have these
redundant "*32" entries in linux/ioctlent.h.in already, maybe it's time
to strip them instead of adding new ones.
> @@ -737,21 +757,91 @@
> {"sound/asound.h", "SNDRV_TIMER_IOCTL_PVERSION", 0x5400},
> {"linux/soundcard.h", "SNDCTL_TMR_TIMEBASE", 0x5401},
> {"sound/asound.h", "SNDRV_TIMER_IOCTL_NEXT_DEVICE",0x5401},
> + {"asm-generic/ioctls.h","TCGETS", 0x5401},
We were adding asm-generic entries to arch-specific ioctlent files before.
I'm not sure whether we'd rather move all these entries to the common
ioctlent file as indirectly proposed by this patch.
Any ideas why we might want to continue the old practice?
--
ldv
pgp7bt8UM1yY4.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] Add -e trace=memory option
On Wed, Oct 24, 2012 at 10:01:36AM +0900, Namhyung Kim wrote: > 2012-10-22 오전 4:25, Dmitry V. Levin 쓴 글: > > vmsplice is not a memory mapping related. I see it was not actually > > changed by the patch. > > But vmsplice takes memory addresses through iov->iov_base. Isn't it memory > (mapping) related? readv/writev also take struct iovec arguments, but you wouldn't add them to the trace=memory category, would you? -- ldv pgplQr03L7yZO.pgp Description: PGP signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 2/2] Add AArch64 support to strace
On Tue, Oct 23, 2012 at 05:38:22PM +0100, Steve McIntyre wrote: [...] > * syscall.c: Support AArch64. Uses new PTRACE_GETREGSET ptrace request > instead of PTRACE_GETREGS, so also include sys/uio.h and elf.h for needed > definitions. Could you please enlighten us what was the rationale behind this decision? Is there any registers you need that couldn't be easily obtained using PTRACE_GETREGS? -- ldv pgpoDAOqDVIzu.pgp Description: PGP signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v2] Add -e trace=memory option
On Wed, Oct 24, 2012 at 11:41:57AM +0900, Namhyung Kim wrote: > Add a new 'memory' category for tracing memory mapping related syscalls. I've applied this change with minor corrections. Thanks! -- ldv pgpxNrcjMTmmT.pgp Description: PGP signature -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] Update errno and ioctl definitions for newer Linux
On Wed, Oct 24, 2012 at 02:49:20PM +0100, Steve McIntyre wrote: > On Wed, Oct 24, 2012 at 03:58:46AM +0400, Dmitry V. Levin wrote: > >On Tue, Oct 23, 2012 at 05:36:58PM +0100, Steve McIntyre wrote: > >> Update errno and ioctl definitions for newer Linux > >> > >> Signed-off-by: Steve McIntyre > >> --- > >> linux/errnoent.h|4 +- > >> linux/ioctlent.h.in | 121 > >> +++ > >> 2 files changed, 123 insertions(+), 2 deletions(-) > >> > >> diff --git a/linux/errnoent.h b/linux/errnoent.h > >> index e43bff5..c2ac683 100644 > >> --- a/linux/errnoent.h > >> +++ b/linux/errnoent.h > >> @@ -519,8 +519,8 @@ > >>"ERESTARTNOHAND", /* 514 */ > >>"ENOIOCTLCMD", /* 515 */ > >>"ERESTART_RESTARTBLOCK", /* 516 */ > >> - "ERRNO_517", /* 517 */ > >> - "ERRNO_518", /* 518 */ > >> + "EPROBE_DEFER", /* 517 */ > >> + "EOPENSTALE", /* 518 */ > >>"ERRNO_519", /* 519 */ > >>"ERRNO_520", /* 520 */ > >>"EBADHANDLE", /* 521 */ > > > >This one is obvious. Please add a ChangeLog-style entry (see > >README-hacking file for details) for this errnoent.h patch. > > ACK. Here's an update for that. Applied, thanks. -- ldv pgpmtBj1bd6G3.pgp Description: PGP signature -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 2/2] Add AArch64 support to strace
On Wed, Oct 24, 2012 at 05:58:16PM +0100, Steve McIntyre wrote: > On Tue, Oct 23, 2012 at 02:11:59PM -0400, Mike Frysinger wrote: > >On Tuesday 23 October 2012 12:38:22 Steve McIntyre wrote: > >> Add AArch64 support to strace [...] > New patch included here with these changes included. Applied with linux/aarch64/syscallent.h updated for newly introduced trace=memory support. Thanks! -- ldv pgpvm9XBcNJCh.pgp Description: PGP signature -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] Update errno and ioctl definitions for newer Linux
On Tue, Oct 23, 2012 at 10:22:56PM -0400, Mike Frysinger wrote:
> On Tuesday 23 October 2012 19:58:46 Dmitry V. Levin wrote:
> > On Tue, Oct 23, 2012 at 05:36:58PM +0100, Steve McIntyre wrote:
> > > --- a/linux/ioctlent.h.in
> > > +++ b/linux/ioctlent.h.in
> > > @@ -2,6 +2,7 @@
> > >
> > > {"linux/fs.h", "FIBMAP", 0x0001},
> > > {"linux/fs.h", "FIGETBSZ", 0x0002},
> > > {"linux/fd.h", "FDGETPRM", 0x0204},
> > > + {"linux/fd.h", "FDGETPRM32", 0x0204},
> >
> > I'm not sure such entries are worth adding. I know we have these
> > redundant "*32" entries in linux/ioctlent.h.in already, maybe it's time
> > to strip them instead of adding new ones.
>
> if the # is the same as the non-32 version, then yeah, we should omit it.
> otherwise the output is generally useless:
> ioctl(1, FDGETPRM or FDGETPRM32, {...}) = 0
>
> the decoder would need to know more info in order to tell which one exactly
> is
> being used (based on the active ELF). but we don't have that, so we should
> filter it.
>
> i'm guessing Steve just ran the script in the tree to generate this and
> didn't
> hand update it. which means we should update the script to be smarter.
I've added a new script and removed redundant "*32" entries from
linux/ioctlent.h.in.
--
ldv
pgpXZ9GTSx0le.pgp
Description: PGP signature
--
WINDOWS 8 is here.
Millions of people. Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Q: drop PTRACE_SEIZE_DEVEL?
On Tue, Jul 10, 2012 at 04:36:18PM +0200, Denys Vlasenko wrote:
> On 07/10/2012 01:01 AM, Dmitry V. Levin wrote:
[...]
> > I suppose we can safely drop PTRACE_SEIZE_DEVEL from USE_SEIZE code now.
>
> I'm going to do that. Also will drop PTRACE_EVENT_STOP1
> and enable USE_SEIZE in defs.h
It seems to be working so far, but with annoying addition to the strace
output:
$ strace true
--- stopped by SIGSTOP ---
--- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=4096, si_uid=512} ---
execve("/bin/true", ["true"], [/* 32 vars */]) = 0
exit_group(0) = ?
+++ exited with 0 +++
The child process is actually being stopped and continued, but are these
technical details of USE_SEIZE implementation worth seeing?
--
ldv
pgpAsc1MBxRxP.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Update AArch64 strace to also support tracing 32-bit ARM binaries
On Sat, Nov 10, 2012 at 11:24:48AM +, Steve McIntyre wrote: > On Sat, Nov 10, 2012 at 12:20:34AM -0500, Mike Frysinger wrote: > >On Thursday 08 November 2012 12:36:05 Steve McIntyre wrote: [...] > Here's the updated patch. Thanks for the quick review. Applied (with trailing whitespaces removed), thanks. -- ldv pgpLiSYLIPvHP.pgp Description: PGP signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Bug in setbpt/clearbpt for SPARC/SPARC64?
Hi, On Wed, Nov 28, 2012 at 01:14:33PM +, James Hogan wrote: > While implementing regset support in strace for the metag architecture, > I think I've noticed a problem in util.c. > > For SPARC/SPARC64, arg_setup and arg_finish_change are defined to use > PTRACE_GETREGS and PTRACE_SETREGS. However change_syscall also does a > read-modify-write using PTRACE_GETREGS and PTRACE_SETREGS. > > These are then combined in a bad way in setbpt: > > if (arg_setup(tcp, &state) < 0 > /* reads the registers into state */ > || get_arg0(tcp, &state, &tcp->inst[0]) < 0 > || get_arg1(tcp, &state, &tcp->inst[1]) < 0 > /* reads arguments from state */ > || change_syscall(tcp, clone_scno[current_personality]) < 0 > /* reads registers again, and changes one of them */ > || set_arg0(tcp, &state, CLONE_PTRACE|SIGCHLD) < 0 > || set_arg1(tcp, &state, 0) < 0 > /* sets argument registers in state */ > || arg_finish_change(tcp, &state) < 0) > /* writes back state, presumably undoing change_syscall's hard work. */ > > Looking at a "git diff v4.7..master util.c", it looks like clearbpt is > doing something similar too. > > Is that analysis correct or have I missed something important that would > make it work? Yes, there seems to be a bug on SPARC/SPARC64 where change_syscall is effectively disabled due to the way how it is implemented. -- ldv pgp7aTAZc6kRo.pgp Description: PGP signature -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/1] Add state argument to change_syscall and fix SPARC
On Thu, Nov 29, 2012 at 05:37:37PM +, James Hogan wrote: > Add a state argument to change_syscall() so that SPARC can modify that > instead of read-modify-writing the whole register set. This function is > always called within an arg_setup/arg_finish_change sequence which on > certain architectures like SPARC will also be doing a read-modify-write. > This prevents the second write (from arg_finish_change) from undoing the > effects of the change_syscall() call. > > * util.c (change_syscall): Add state arg. > Move below definition of arg_setup_state. > Change SPARC to set state->u_regs[U_REG_G1] rather than > read-modify-writing it with PTRACE_GETREGS and PTRACE_SETREGS. > (setbpt, clearbpt): Pass state arg to change_syscall. > > Signed-off-by: James Hogan > --- > Note, I haven't compiled or tested this on SPARC or SPARC64, only on > x86_64. It looks pretty trivial though. I also haven't tested this on SPARC/SPARC64 but the fix is obvious so I've applied it as is. Thanks, -- ldv pgpPwISrAzPhe.pgp Description: PGP signature -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] check if __GLIBC__ is defined before using it
On Mon, Dec 03, 2012 at 12:29:20AM +0100, John Spencer wrote:
> --- a/signal.c
> +++ b/signal.c
> @@ -419,7 +419,7 @@ print_sigset(struct tcb *tcp, long addr, int rt)
> # define SI_FROMUSER(sip)((sip)->si_code <= 0)
> #endif
>
> -#if __GLIBC_MINOR__ < 1
> +#if defined(__GLIBC__) && __GLIBC_MINOR__ < 1
> /* Type for data associated with a signal. */
> typedef union sigval
> {
> @@ -,7 +,7 @@ sys_sigsuspend(struct tcb *tcp)
> #if !defined SS_ONSTACK
> #define SS_ONSTACK 1
> #define SS_DISABLE 2
> -#if __GLIBC_MINOR__ == 0
> +#if defined(__GLIBC__) && __GLIBC_MINOR__ == 0
> typedef struct
> {
> __ptr_t ss_sp;
> diff --git a/util.c b/util.c
> index b058a42..b0cdab7 100644
> --- a/util.c
> +++ b/util.c
> @@ -39,7 +39,7 @@
> # include
> #endif
>
> -#if __GLIBC__ < 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ < 1)
> +#if defined(__GLIBC__) && (__GLIBC__ < 2 || (__GLIBC__ == 2 &&
> __GLIBC_MINOR__ < 1))
> # include
> #endif
>
These two glibc version checks in signal.c remains incomplete after the patch,
I suppose they should be the same as the check in util.c.
When submitting a patch, please follow our simple commit log requirements
described in
README-hacking file.
--
ldv
pgpGHXzmEtiTY.pgp
Description: PGP signature
--
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] sys_semtimedop(): fix timeval argument index in wrapped call
On Fri, Dec 07, 2012 at 09:30:51PM +0100, Stanislav Brabec wrote: > Looking at the implementation of wrapped semtimedop() call inside glibc > and kernel, I started to believe, that timeval should be located in > tcp->u_arg[4] and not tcp->u_arg[5]. Yes, in indirect_ipccall non-s390 case its canonical location is tcp->u_arg[4]. > For unknown reason, tcp->u_arg[5] works correctly as well. The reason is decode_ipc_subcall() that makes tcp->u_arg[tcp->u_nargs-1] == tcp->u_arg[tcp->u_nargs]. -- ldv pgpMKcLDi0dFY.pgp Description: PGP signature -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Strace not showing all system calls
On Wed, Jan 09, 2013 at 11:31:57AM +0100, Frits Hoogland wrote: > Hello list, I hope you can help me with an observation I've made with strace > on Oracle Linux 6.3 (latest) X64. > When I strace a process, I only see successful io_getevents() calls, not > non-successful io_getevents() calls with a timeout set to 0s. strace starts to decode io_getevents at the enter of syscall, it prints first three arguments right away, so it would be too late to decide whether to print io_getevents or not depending on its return value. The question is, how do you know there are unsuccessful io_getevents() calls if strace doesn't show them? -- ldv pgpzkjRDIM2f0.pgp Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: improper output when executing program via strace on armhf device
On Sun, Jan 20, 2013 at 02:53:57PM +0100, Rune Kjær Svendsen wrote: > Hi list > > I'm using strace running in Ubuntu on a Samsung ARM chromebook. It's using > the 3.4.0 kernel from here: > http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git (the > one the comes with Chrome OS). > > When I run a program that is executed via strace, I see a lot of "stray > syscall entry/exit" messages, and the paths of the filenames reported by > the -eopen filter aren't present. What's the strace version you are using? -- ldv pgptIv2QoYF9A.pgp Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: improper output when executing program via strace on armhf device
On Sun, Jan 20, 2013 at 11:00:32PM +0100, Rune Kjær Svendsen wrote: > Using strace 4.5.20-2.3ubuntu2 from Ubuntu 12.10. I'm sorry, but strace 4.5.20 was released in April of 2010, please try something more up to date, e.g. the latest release 4.7 or strace.git. -- ldv pgpEb6oqxPoQ0.pgp Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] mmap: decode MAP_UNINITIALIZE
On Mon, Jan 21, 2013 at 02:36:55PM +0100, Bernhard Reutner-Fischer wrote:
> Signed-off-by: Bernhard Reutner-Fischer
> ---
> mem.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mem.c b/mem.c
> index 0279030..53fcf85 100644
> --- a/mem.c
> +++ b/mem.c
> @@ -159,6 +159,9 @@ static const struct xlat mmap_flags[] = {
> #ifdef MAP_STACK
> { MAP_STACK,"MAP_STACK" },
> #endif
> +#ifdef MAP_UNINITIALIZE
> + { MAP_UNINITIALIZE,"MAP_UNINITIALIZE"},
> +#endif
> #ifdef MAP_NOSYNC
> { MAP_NOSYNC, "MAP_NOSYNC"},
> #endif
You mean MAP_UNINITIALIZED?
--
ldv
pgpJJPuthwgcP.pgp
Description: PGP signature
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] mmap: decode MAP_UNINITIALIZE
On Tue, Jan 22, 2013 at 10:16:42AM +0100, Bernhard Reutner-Fischer wrote:
> On 21 January 2013 15:23, Dmitry V. Levin wrote:
> > On Mon, Jan 21, 2013 at 02:36:55PM +0100, Bernhard Reutner-Fischer wrote:
> >> Signed-off-by: Bernhard Reutner-Fischer
> >> ---
> >> mem.c |3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/mem.c b/mem.c
> >> index 0279030..53fcf85 100644
> >> --- a/mem.c
> >> +++ b/mem.c
> >> @@ -159,6 +159,9 @@ static const struct xlat mmap_flags[] = {
> >> #ifdef MAP_STACK
> >> { MAP_STACK,"MAP_STACK" },
> >> #endif
> >> +#ifdef MAP_UNINITIALIZE
> >> + { MAP_UNINITIALIZE,"MAP_UNINITIALIZE"},
> >> +#endif
> >> #ifdef MAP_NOSYNC
> >> { MAP_NOSYNC, "MAP_NOSYNC"},
> >> #endif
> >
> > You mean MAP_UNINITIALIZED?
>
> ugh, it seems that the name changed mid-flight :(
> So yes, i mean MAP_UNINITIALIZED, i will change uClibc to add the 'D'.
OK, is there a chance to get MAP_UNINITIALIZED defined to 0?
If yes, then there needs to be a check for that case, e.g.
#if MAP_UNINITIALIZED > 0
--
ldv
pgpIFf92mhxMH.pgp
Description: PGP signature
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] mmap: decode MAP_UNINITIALIZE
On Tue, Jan 22, 2013 at 06:09:50PM +0100, Bernhard Reutner-Fischer wrote:
> On 22 January 2013 10:35, Dmitry V. Levin wrote:
> > On Tue, Jan 22, 2013 at 10:16:42AM +0100, Bernhard Reutner-Fischer wrote:
> >> On 21 January 2013 15:23, Dmitry V. Levin wrote:
> >> > On Mon, Jan 21, 2013 at 02:36:55PM +0100, Bernhard Reutner-Fischer wrote:
> >> >> Signed-off-by: Bernhard Reutner-Fischer
> >> >> ---
> >> >> mem.c |3 +++
> >> >> 1 file changed, 3 insertions(+)
> >> >>
> >> >> diff --git a/mem.c b/mem.c
> >> >> index 0279030..53fcf85 100644
> >> >> --- a/mem.c
> >> >> +++ b/mem.c
> >> >> @@ -159,6 +159,9 @@ static const struct xlat mmap_flags[] = {
> >> >> #ifdef MAP_STACK
> >> >> { MAP_STACK,"MAP_STACK" },
> >> >> #endif
> >> >> +#ifdef MAP_UNINITIALIZE
> >> >> + { MAP_UNINITIALIZE,"MAP_UNINITIALIZE"},
> >> >> +#endif
> >> >> #ifdef MAP_NOSYNC
> >> >> { MAP_NOSYNC, "MAP_NOSYNC"},
> >> >> #endif
> >> >
> >> > You mean MAP_UNINITIALIZED?
> >>
> >> ugh, it seems that the name changed mid-flight :(
> >> So yes, i mean MAP_UNINITIALIZED, i will change uClibc to add the 'D'.
> >
> > OK, is there a chance to get MAP_UNINITIALIZED defined to 0?
>
> AFAICS no.
linux/include/uapi/asm-generic/mman-common.h contains this:
#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
# define MAP_UNINITIALIZED 0x400/* For anonymous mmap, memory could be
uninitialized */
#else
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
So I'm not quite sure it cannot be defined to 0x0.
> > If yes, then there needs to be a check for that case, e.g.
> > #if MAP_UNINITIALIZED > 0
>
> #if defined MAP_UNINITIALIZED && MAP_UNINITIALIZED + 0 > 0
> for a redundant, exhaustive check but no, it is always 0x400
Is there any need for this " + 0" arithemtics?
--
ldv
pgpfUNe57Fjau.pgp
Description: PGP signature
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/2] mmap: decode MAP_UNINITIALIZE
On Tue, Jan 22, 2013 at 01:10:13PM -0500, Mike Frysinger wrote:
> On Tuesday 22 January 2013 04:16:42 Bernhard Reutner-Fischer wrote:
> > On 21 January 2013 15:23, Dmitry V. Levin wrote:
> > > On Mon, Jan 21, 2013 at 02:36:55PM +0100, Bernhard Reutner-Fischer wrote:
> > >> --- a/mem.c
> > >> +++ b/mem.c
> > >>
> > >> +#ifdef MAP_UNINITIALIZE
> > >> + { MAP_UNINITIALIZE,"MAP_UNINITIALIZE"},
> > >> +#endif
> > >
> > > You mean MAP_UNINITIALIZED?
> >
> > ugh, it seems that the name changed mid-flight :(
> > So yes, i mean MAP_UNINITIALIZED, i will change uClibc to add the 'D'.
> > Do you want me to resend this hunk with the D added or can you take
> > care of this?
>
> we named it MAP_UNINITIALIZE when we first implemented it on the Blackfin
> side,
> but it was tweaked while getting merged to mainline linux. we forgot to
> update the uClibc side and no one noticed because userland provides its own
> defines rather than including kernel headers :).
Shouldn't MAP_UNINITIALIZED be also added to glibc then?
--
ldv
pgpLGZjVwuLZT.pgp
Description: PGP signature
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: improper output when executing program via strace on armhf device
On Tue, Jan 22, 2013 at 07:45:59PM +0100, Rune Kjær Svendsen wrote: > Just built 4.7 and it works like a charm. I've reported the following bug > in Ubuntu to get them to pull in stace 4.7 for Raring. So if anyone else is > experiencing this bug in Ubuntu, then please mark the below bug as > affecting you. > > https://bugs.launchpad.net/ubuntu/+source/strace/+bug/1103114 The problem is that strace package in Ubuntu is essentially the same as strace package in Debian and the latter is de facto orphaned. -- ldv pgpmPOMNx638x.pgp Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] Add tilegx support to strace
On Tue, Feb 05, 2013 at 11:16:31AM -0500, Chris Metcalf wrote: > Ping? > > Would it make sense for me to be able to directly commit tile-specific > changes to strace? The previous tile support for strace was committed by an > strace maintainer on my behalf (commit c8c6698ef7cde in Dec 2009). Somebody, probably myself, has to review the change. -- ldv pgpTYIoqQlY8p.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCHv2 1/2] mmap: decode MAP_UNINITIALIZED
On Tue, Feb 05, 2013 at 07:31:55PM +0100, Bernhard Reutner-Fischer wrote: > mem.c |3 +++ On Tue, Feb 05, 2013 at 07:31:56PM +0100, Bernhard Reutner-Fischer wrote: > system.c |2 ++ Thanks, I've added changelog entries and applied them. -- ldv pgpB64z6BJzsr.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] Improve perf_event_open argument decoding
On Mon, Feb 04, 2013 at 12:04:57AM +0100, Ben Noordhuis wrote: > * configure.ac: Add check. > * desc.c: Add sys_perf_event_open I've added missing bits to the changelog entry, fixed a typo and applied this. Thanks, -- ldv pgpSsgHmwJdQW.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] tile: Fix merge skew with new get_regs architecture
On Tue, Feb 05, 2013 at 01:02:42PM -0500, Chris Metcalf wrote: > Also fix a compiler warning about pt_reg_t in a printf expression. This time it was me who made this patch harder to merge, so I've adjusted it a bit, added a changelog entry and applied. Thanks, -- ldv pgpIWK5RQQ2sr.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] Improve perf_event_open argument decoding
On Wed, Feb 06, 2013 at 12:57:34AM +0100, Ben Noordhuis wrote: > On Wed, Feb 6, 2013 at 12:31 AM, Dmitry V. Levin wrote: > > On Mon, Feb 04, 2013 at 12:04:57AM +0100, Ben Noordhuis wrote: > >> * configure.ac: Add check. > >> * desc.c: Add sys_perf_event_open > > > > I've added missing bits to the changelog entry, fixed a typo and > > applied this. Thanks, > > Are you open to a patch that decodes the perf_event_attr struct? > > I didn't do it in this patch because the struct is pretty big, > something like twenty fields and growing. I'm not sure how to best > present that in the output. Most of big structs are abbreviated by default, it might be reasonable to follow this convention and abbreviate perf_event_attr by default, too. -- ldv pgpqeoNpEOLDz.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Q: drop PTRACE_SEIZE_DEVEL?
On Wed, Feb 06, 2013 at 01:57:46PM +0100, Denys Vlasenko wrote:
> On 10/31/2012 04:37 PM, Dmitry V. Levin wrote:
> > It seems to be working so far, but with annoying addition to the strace
> > output:
> >
> > $ strace true
> > --- stopped by SIGSTOP ---
> > --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=4096, si_uid=512} ---
> > execve("/bin/true", ["true"], [/* 32 vars */]) = 0
> > exit_group(0) = ?
> > +++ exited with 0 +++
> >
> > The child process is actually being stopped and continued, but are these
> > technical details of USE_SEIZE implementation worth seeing?
>
> We did not do any special magic before to hide initial setup.
> It just so happens that with "good old" PTRACE_TRACEME
> method of spawning the child we don't have any stray syscalls:
>
> Child does
> ptrace(PTRACE_TRACEME);
> kill(pid, SIGSTOP);
> Then parent goes into tracing waitpid loop,
> sees SIGSTOP, knows to ignore it, issues PTRACE_SYSCALL(0),
> which unpauses group-stop.
> Then child falls into execve, and parent sees it.
>
> Result: strace reports no "extra" syscalls before execve.
>
> Whereas with SEIZE:
>
> Child does
> kill(pid, SIGSTOP);
> then parent waits for SIGSTOP to take effect on child,
> then parent does PTRACE_SEIZE and PTRACE_INTERRUPT on child,
> then parent sends SIGCONT to it,
> Then parent goes into tracing waitpid loop,
> then child goes through the motions of waking up from group-stop
> and then falls into execve.
>
> All of the above is done to make sure that child doesn't fall
> into execve BEFORE we seize it.
>
> Better ideas how to achieve that?
> Basically: how to stop the child "cleanly"?
No, there seems to be no such way with this new ptrace API.
We have to block the child process to seize it, and after that we will
see its unblocking no matter what kind of blocking method is in use.
> A possible alternative is to bite the bullet and suppress STOP/CONT
> reports for this special child.
> We already have infrastructure to do so (we suppress SIGSTOPs
> from ATTACH on older kernels).
Looks like this is the only alternative available.
--
ldv
pgp2INo1Z7aXr.pgp
Description: PGP signature
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] if we are on a glibc system, assume it's at least glibc 2.1
On Fri, Feb 08, 2013 at 03:22:09PM +0100, Denys Vlasenko wrote: > Hi Dmitry, > > glibc 2.1.1 was released in 1999. > > Is this patch ok with you? Yes. -- ldv pgptQKFXjn4MZ.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] fix decoding of sysctl() when oldval fields are NULL
Applied, thanks. -- ldv pgppapJLMDS8T.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: strace hangs on sigaltstack system call with invalid arguments (hacky patch attached)
Hi, On Fri, Feb 08, 2013 at 06:07:59PM -0700, kawil...@ucalgary.ca wrote: > I've been using strace for a while now, and just found what I would > consider to be a bug in strace. Essentially, if a traced program executes > a particular system call (SYS_sigaltstack) with `invalid' arguments (which > cause the kernel implementation to simply fail immediately), strace hangs > and does not send a ptrace(PTRACE_SYSCALL) to the child. > > Attached is a simple program that reproduces this behaviour for me, > compiled and executed on both 32- and 64- bit x86 Linux using strace 4.7; > the behaviour exists on both my precompiled version from the Arch > repositories as well as one compiled from source. Thanks for reporting, it was print_stack_t() mishandling umove() return code, I've pushed the following commit to fix it: http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=v4.7-58-g338c069 > There's obviously a philosophical issue at stake here as well -- should > stace behave nicely on programs that don't behave nicely? It seems as if > converting everything to conform to this sort of duality of error types > from umoven() would be difficult to me (I'm a newcomer to strace, > obviously!). strace is expected to decode syscalls properly, in particular, it shouldn't complain when syscall arguments are complete nonsense. If you are aware of other cases when strace doesn't follow this rule, please let us know. -- ldv pgpLuBu1HvZ8L.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Suggestion for patch
Hi,
On Thu, Feb 07, 2013 at 03:15:17PM +, Frediano Ziglio wrote:
> I was trying to add support to Xen ioctl to strace. To distinguish
> from other ioctl I used the entire code (not only type and number but
> also size and direction) so I changed sys_ioctl in io.c to call a
> function that check for the entire code and return true if it handled
> the syscall. Is it fine to do it?
It is probably OK, at least I couldn't think up a better alternative yet.
> The ioctl of Xen are quite complicated to decode cause there are single
> ioctls that accept a structure that internally have a command field that
> specify the operation and an union with all data for operations,
> something like
>
> struct my_operation {
> int operation;
> union {
> struct operation1_data operation1;
> struct operation2_data operation2;
> struct operation3_data operation3;
> ...
> } u;
> };
>
> Just to complicate more some field in operationX_data can be for output,
> input or input/output. I found no way to store some informations in tcb
> structure. I'd like to print something when syscall enters (input
> parameters) and something when syscall leaves, somethings like
>
> ioctl(FD, IOCTL, {op=my_op,u={field_inout=5}}->{u={field_inout=3}}) = 0
>
> (->) to separate input and output. Is there a specific syntax to
> separate input and output?
This is uncharted territory, we had nothing like this before.
Anyway, a space before and after this delimiter wouldn't harm.
> +extern int ioctl_decode_exact(struct tcb *tcp);
A declaration would have to go to defs.h
> int
> sys_ioctl(struct tcb *tcp)
> {
> @@ -384,6 +386,12 @@ sys_ioctl(struct tcb *tcp)
> if (entering(tcp)) {
> printfd(tcp, tcp->u_arg[0]);
> tprints(", ");
> + }
> +
> + if (ioctl_decode_exact(tcp))
> + return 0;
> +
> + if (entering(tcp)) {
> iop = ioctl_lookup(tcp->u_arg[1]);
> if (iop) {
> tprints(iop->symbol);
I'd rather put this ioctl_decode_exact() call to both branches.
> +#include
> +#include
> +#include
Availability of these headers has to be checked in configure.ac so that
HAVE_XENCTRL_H and other macros could be used here.
I'd prefer to put this complicated xen ioctl parser to separate xen.c
source file.
> +// hold information on status
> +// need flush if space is not enough
> +typedef struct {
> + char *dest, *dest_end;
> + char buffer[256];
> +} print_status;
> +
> +static inline void
> +status_init(print_status *status)
> +{
> + status->dest = status->buffer;
> + status->dest_end = status->buffer + sizeof(status->buffer);
> +}
> +
> +static void
> +assure_space(print_status *status, size_t needed)
> +{
> + /* assert(needed <= sizeof(status->buffer)); */
> + if (needed > status->dest_end - status->dest) {
> + tprints(status->buffer);
> + status->buffer[0] = 0;
> + status->dest = status->buffer;
> + }
> +}
> +
> +static inline void
> +status_flush(print_status *status)
> +{
> + assure_space(status, sizeof(status->buffer));
> +}
> +
> +static void
> +status_printf(print_status *status, const char *fmt, ...)
> +{
> + int l;
> + va_list ap;
> +
> + assure_space(status, 64);
> + va_start(ap, fmt);
> + l = vsprintf(status->dest, fmt, ap);
> + va_end(ap);
> + status->dest += l;
> +}
Why do we need additional buffering on top of tprintf/tprints?
Does the latter perform so badly?
--
ldv
pgpHUhOumLpL8.pgp
Description: PGP signature
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] new x86 personality detection
On Mon, Feb 11, 2013 at 12:45:48PM +0100, Denys Vlasenko wrote: > Hi, > > Recent addition of AArch64 used a novel way of detecting > 32/64-bitness of the process by looking at the returned size > of ptrace(PTRACE_GETREGSET, NT_PRSTATUS). > > I played with it on x86 and it appears to be working there too. Yes, seems to work on fresh kernels. Unfortunately, on 2.6.18-based kernels PTRACE_GETREGSET returns EIO and strace with your patch applied just silently hangs. Another candidate for a runtime check? -- ldv pgpPyiSgZVW7s.pgp Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH] new x86 personality detection
On Mon, Feb 11, 2013 at 03:12:23PM +0100, Denys Vlasenko wrote:
> On 02/11/2013 01:46 PM, Denys Vlasenko wrote:
> > On 02/11/2013 12:45 PM, Denys Vlasenko wrote:
> >> This patch implements a (hopefully) correct way to check for
> >> syscall bitness on x86.
> >>
> >> I tested it to work when stracing normal 32-bit binaries,
> >> can't test the above example till this evening.
> >> But it should work too (famous last words?).
> >>
> >> Please review.
> >
> > Looks like we had a bug on X32:
> >
> > if (check_errno && is_negated_errno(x86_64_regs.rax)) {
> >
> > If we build in X32 environment, above we check only lower 32 bits of rax
> > - because is_negated_errno() takes _long_ parameter, which is 32-bit
> > on X32. Therefore e.g. llseek returning a valid offset of 0xfffe
> > will be mishandled as returning errno 2.
> >
> > The updated patch also includes fix for this bug.
>
> ...the slight problem that my code... doesn't fix the bug :(
>
> +is_negated_errno_ll(unsigned long long val)
> +{
> + unsigned long long max = -(long long) nerrnos;
> +#if SUPPORTED_PERSONALITIES > 1
> + if (current_wordsize < sizeof(val)) {
> + val = (unsigned int) val;
> + max = (unsigned int) max;
> + }
> +#endif
> + return val > max;
> +}
>
> The above _always_ falls into "if", since current_wordsize == 4
> even for native X32.
> Looks like I'll have to resort to x32-specific checking function:
>
> +static inline int
> +is_negated_errno_x32(unsigned long long val)
> +{
> + unsigned long long max = -(long long) nerrnos;
> + /*
> +* current_wordsize == 4 even in personality 0 (X32)
> +* but truncation _must not_ be done in it.
> +* can't check current_wordsize here!
> +*/
> + if (current_personality != 0) {
> + val = (uint32_t) val;
> + max = (uint32_t) max;
> + }
> + return val > max;
> +}
I suppose this is not necessarily limited to X32, it can happen on any
architecture with ext_arg and u_lrval.
Maybe i's worth introducing some kind of
personality_is_negated_errno[current_personality] and changing
is_negated_errno to a macro.
--
ldv
pgpfebNDBound.pgp
Description: PGP signature
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
