From: Dmitry V. L. <ld...@al...> - 2014-04-02 16:12:51
|
Hi, There is quite enough good stuff accumulated in strace.git since v4.8 to release a new version. If you have pending patches to include before the release, please submit them. -- ldv |
From: enh <en...@go...> - 2014-04-02 16:49:01
|
intel says i screwed up the struct stat64 change, and i think they're right. i'll try to look at this today and get something that's right for both x86/x86-64 and arm/aarch64. (sorry for the delay in reporting this; i've was on vacation for two weeks.) other than that, we've been running at ToT (though we're missing any changes from the last two weeks; i'll rectify that today too), and i've heard no other complaints. On Wed, Apr 2, 2014 at 9:12 AM, Dmitry V. Levin <ld...@al...> wrote: > Hi, > > There is quite enough good stuff accumulated in strace.git since v4.8 > to release a new version. If you have pending patches to include > before the release, please submit them. > > > -- > ldv > > ------------------------------------------------------------------------------ > > _______________________________________________ > Strace-devel mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/strace-devel > -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer. |
From: enh <en...@go...> - 2014-04-04 01:03:50
|
okay, i had a look at this today and my patch for aarch64 decoding of struct stat64 in 32-bit arm processes was wrong. i've just mailed a corrected patch to the list, tested against both 32-bit and 64-bit processes. (a corresponding change to the Android makefile is needed to _not_ define HAVE_STAT64 when building for aarch64, but i assume your configure script already doesn't define HAVE_STAT64 for LP64 architectures so you should be fine.) On Wed, Apr 2, 2014 at 9:43 AM, enh <en...@go...> wrote: > intel says i screwed up the struct stat64 change, and i think they're > right. i'll try to look at this today and get something that's right > for both x86/x86-64 and arm/aarch64. > > (sorry for the delay in reporting this; i've was on vacation for two weeks.) > > other than that, we've been running at ToT (though we're missing any > changes from the last two weeks; i'll rectify that today too), and > i've heard no other complaints. > > On Wed, Apr 2, 2014 at 9:12 AM, Dmitry V. Levin <ld...@al...> wrote: >> Hi, >> >> There is quite enough good stuff accumulated in strace.git since v4.8 >> to release a new version. If you have pending patches to include >> before the release, please submit them. >> >> >> -- >> ldv >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Strace-devel mailing list >> Str...@li... >> https://lists.sourceforge.net/lists/listinfo/strace-devel >> > > > > -- > Elliott Hughes - http://who/enh - http://jessies.org/~enh/ > Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer. |
From: Luca C. <luc...@gm...> - 2014-04-09 14:35:31
|
On Wed, Apr 2, 2014 at 9:12 AM, Dmitry V. Levin <ld...@al...> wrote: > Hi, > > There is quite enough good stuff accumulated in strace.git since v4.8 > to release a new version. If you have pending patches to include > before the release, please submit them. > > Hey Dmitry, are you interested in the stack tracing patch set (what you have on your ldv/unwind branch)? If so I can try to resurrect the patch set from Masatake re-base it on top of the current master and send you a pull request. Luca |
From: Dmitry V. L. <ld...@al...> - 2014-04-09 14:51:46
|
Hi Luca, On Wed, Apr 09, 2014 at 07:35:25AM -0700, Luca Clementi wrote: > On Wed, Apr 2, 2014 at 9:12 AM, Dmitry V. Levin <ld...@al...> wrote: > > > There is quite enough good stuff accumulated in strace.git since v4.8 > > to release a new version. If you have pending patches to include > > before the release, please submit them. > > > Hey Dmitry, > are you interested in the stack tracing patch set (what you have on your > ldv/unwind branch)? I wouldn't push it to ldv/unwind if I wasn't interested. > If so I can try to resurrect the patch set from Masatake re-base it on top > of the current master and send you a pull request. If the libunwind API used by this patch set is stable, then it makes sense. -- ldv |
From: Masatake Y. <ya...@re...> - 2014-04-09 15:21:24
|
I'm very sorry but I'm still working on it. I've been doing two things: 1. bug fixing 2. improve libunwind cache and use it from strace 3. prepare elfutils backend, alternative to the libunwind elfutils may show the better performance. However, I have no time for working on it now. 2. also takes longger time than I expected. So, I'd like to submit bug fixing to the current implementation as soon as possible. Sorry again to be late. Masatake YAMATO > On Wed, Apr 2, 2014 at 9:12 AM, Dmitry V. Levin <ld...@al...> wrote: > >> Hi, >> >> There is quite enough good stuff accumulated in strace.git since v4.8 >> to release a new version. If you have pending patches to include >> before the release, please submit them. >> >> > Hey Dmitry, > are you interested in the stack tracing patch set (what you have on your > ldv/unwind branch)? > If so I can try to resurrect the patch set from Masatake re-base it on top > of the current master and send you a pull request. > > > Luca |
From: Masatake Y. <ya...@re...> - 2014-04-09 17:09:42
|
Hi Luca, I've just submmited bug fix patches. (Please, ignore the patches which include line: Ready-to-Merge: yes) These bug fix patches are applicable on [PATCH 01/25] ldv/unwind: improve stacktrace feature(v3) which I submitted last year. ldv wrote: > If the libunwind API used by this patch set is stable, then it makes sense. All patches depends only on stable libunwind API. Could you look at them? I can send a full set of patches again. Tell me if they are convenient for you. Masatake YAMATO |
From: Dmitry V. L. <ld...@al...> - 2014-06-18 16:58:28
|
On Wed, Apr 02, 2014 at 08:12:43PM +0400, Dmitry V. Levin wrote: > There is quite enough good stuff accumulated in strace.git since v4.8 > to release a new version. If you have pending patches to include > before the release, please submit them. Looks like this new -k option is not going to produce a reliable output on all supported configurations so far, even basic strace-k.test is known to fail on x86 and arm. I'd rather document -k as an experimental option and make a release without further delays because of it. So please test HEAD on all supported architectures you can lay hands on. -- ldv |
From: Dmitry V. L. <ld...@al...> - 2014-07-01 00:23:34
|
On Mon, Jun 30, 2014 at 12:57:43AM +0900, Masatake YAMATO wrote: > I would like to inspect the failure on x86. Could you the test binary > somewhere I can download? I would like to fix it till v4.9. Locally I have no problems with strace-k.test on x86, the test fails on fedora koji and the latter is a black box for me. -- ldv |
From: Masatake Y. <ya...@re...> - 2014-07-04 07:30:39
|
> On Mon, Jun 30, 2014 at 12:57:43AM +0900, Masatake YAMATO wrote: >> I would like to inspect the failure on x86. Could you the test binary >> somewhere I can download? I would like to fix it till v4.9. > > Locally I have no problems with strace-k.test on x86, > the test fails on fedora koji and the latter is a black box for me. I see. I'll inspect vdso of i386 more. Masatake YAMATO > > -- > ldv |
From: Masatake Y. <ya...@re...> - 2014-06-29 15:57:59
|
I would like to inspect the failure on x86. Could you the test binary somewhere I can download? I would like to fix it till v4.9. Masatake YAMATO > On Wed, Apr 02, 2014 at 08:12:43PM +0400, Dmitry V. Levin wrote: >> There is quite enough good stuff accumulated in strace.git since v4.8 >> to release a new version. If you have pending patches to include >> before the release, please submit them. > > Looks like this new -k option is not going to produce a reliable output > on all supported configurations so far, even basic strace-k.test is > known to fail on x86 and arm. > > I'd rather document -k as an experimental option and make a release > without further delays because of it. > > So please test HEAD on all supported architectures you can lay hands on. > > > -- > ldv |
From: Dmitry V. L. <ld...@al...> - 2014-07-01 00:49:57
|
On Wed, Jun 18, 2014 at 08:58:20PM +0400, Dmitry V. Levin wrote: > On Wed, Apr 02, 2014 at 08:12:43PM +0400, Dmitry V. Levin wrote: > > There is quite enough good stuff accumulated in strace.git since v4.8 > > to release a new version. If you have pending patches to include > > before the release, please submit them. > > Looks like this new -k option is not going to produce a reliable output > on all supported configurations so far, even basic strace-k.test is > known to fail on x86 and arm. > > I'd rather document -k as an experimental option and make a release > without further delays because of it. > > So please test HEAD on all supported architectures you can lay hands on. Has anybody had a chance to test it on something less widespread than x86_64, x86, and arm? -- ldv |
From: enh <en...@go...> - 2014-07-01 17:41:44
|
mips and aarch64 (for both 32- and 64-bit processes) have been fine for me. i've just updated Android to your ToT, but we were only a few of the -k cleanup patches behind anyway (and we're not turning that on right now). On Mon, Jun 30, 2014 at 5:49 PM, Dmitry V. Levin <ld...@al...> wrote: > On Wed, Jun 18, 2014 at 08:58:20PM +0400, Dmitry V. Levin wrote: >> On Wed, Apr 02, 2014 at 08:12:43PM +0400, Dmitry V. Levin wrote: >> > There is quite enough good stuff accumulated in strace.git since v4.8 >> > to release a new version. If you have pending patches to include >> > before the release, please submit them. >> >> Looks like this new -k option is not going to produce a reliable output >> on all supported configurations so far, even basic strace-k.test is >> known to fail on x86 and arm. >> >> I'd rather document -k as an experimental option and make a release >> without further delays because of it. >> >> So please test HEAD on all supported architectures you can lay hands on. > > Has anybody had a chance to test it on something less widespread than > x86_64, x86, and arm? > > > -- > ldv > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Strace-devel mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/strace-devel > |
From: Mike F. <va...@ge...> - 2014-08-06 00:45:17
Attachments:
signature.asc
|
On Tue 01 Jul 2014 04:49:49 Dmitry V. Levin wrote: > On Wed, Jun 18, 2014 at 08:58:20PM +0400, Dmitry V. Levin wrote: > > On Wed, Apr 02, 2014 at 08:12:43PM +0400, Dmitry V. Levin wrote: > > > There is quite enough good stuff accumulated in strace.git since v4.8 > > > to release a new version. If you have pending patches to include > > > before the release, please submit them. > > > > Looks like this new -k option is not going to produce a reliable output > > on all supported configurations so far, even basic strace-k.test is > > known to fail on x86 and arm. > > > > I'd rather document -k as an experimental option and make a release > > without further delays because of it. > > > > So please test HEAD on all supported architectures you can lay hands on. > > Has anybody had a chance to test it on something less widespread than > x86_64, x86, and arm? testing commit 1cd3f5f844d58b1ced8d3f6dc431688ed94d008e native: vFAIL: test; ia64 linux-3.12.13-gentoo kernel-headers-3.13.0 glibc-2.19 gcc-4.7. vPASS: alpha linux-3.15.6 kernel-headers-3.15.0 glibc-2.19 gcc-4.8.3 vPASS: armv7l linux-3.4.0-vapier kernel-headers-3.13.0 glibc-2.19 gcc-4.7.3 vPASS: i686 linux-3.14.2 kernel-headers-3.3.0 glibc-2.17 gcc-4.7.2 vPASS: parisc linux-3.8.0 kernel-headers-3.13.0 glibc-2.17 gcc-4.7.3 vPASS: ppc64 linux-3.12.20-gentoo kernel-headers-3.9.0 glibc-2.17 gcc-4.7.3 vPASS: ppc linux-3.12.20-gentoo kernel-headers-3.13.0 glibc-2.18 gcc-4.8.2 vPASS: s390 linux-3.14.0 kernel-headers-3.13.0 glibc-2.17 gcc-4.7.3 vPASS: s390x linux-3.14.0 kernel-headers-3.13.0 glibc-2.19 gcc-4.7.3 vPASS: sh4 linux-2.6.30.9 kernel-headers-3.13.0 glibc-2.17 gcc-4.7.3 vPASS: sparc linux-3.15.6 kernel-headers-3.9.0 glibc-2.17 gcc-4.7.3 vPASS: x86_64/x32 linux-3.14.2 kernel-headers-3.12.0 glibc-2.19 gcc-4.8.2 vPASS: x86_64/x64 linux-3.14.2 kernel-headers-3.12.0 glibc-2.19 gcc-4.8.2 cross (build only): vPASS: aarch64 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.8.2 vPASS: armv4 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.8.0 vPASS: bfin cross kernel-headers-3.5.0 uclibc-0.9.33 gcc-4.5.3 vPASS: bfin-fdpic cross kernel-headers-3.5.0 uclibc-0.9.33 gcc-4.5.3 vPASS: m68k cross kernel-headers-3.16.0 glibc-2.19 gcc-4.8.0 vPASS: mips-n32 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.6.4 vPASS: mips-n64 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.6.4 vPASS: mips-o32 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.6.4 vPASS: sparc64 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.6.4 vPASS: tilegx cross kernel-headers-3.16.0 glibc-2.19 gcc-4.8.0 -mike ia64 log: ====================================== strace 4.8: tests/test-suite.log ====================================== # TOTAL: 5 # PASS: 1 # SKIP: 1 # XFAIL: 0 # FAIL: 3 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 SKIP: strace-f ============== strace-f: framework skip: /usr/bin/time is not available FAIL: qual_syscall ================== +++ exited with 0 +++ qual_syscall: failed test: strace -e execve does not work FAIL: stat ========== 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000221487 s, 0.0 kB/s +++ exited with 0 +++ stat: failed test: strace -edesc failed to trace ftruncate/ftruncate64 properly FAIL: net ========= 28049 00:06:38.178587 +++ exited with 0 +++ 28048 00:06:38.178841 +++ exited with 0 +++ net: failed test: strace -enetwork failed to trace "socket" properly |
From: Mike F. <va...@ge...> - 2014-08-06 00:46:42
Attachments:
signature.asc
|
On Tue 05 Aug 2014 20:45:14 Mike Frysinger wrote: > vFAIL: test; ia64 linux-3.12.13-gentoo kernel-headers-3.13.0 glibc-2.19 actually disregard this ... ia64 has a general bug atm where ptrace is completely broken :) -mike |
From: Dmitry V. L. <ld...@al...> - 2014-08-06 13:05:12
|
On Tue, Aug 05, 2014 at 08:45:14PM -0400, Mike Frysinger wrote: > On Tue 01 Jul 2014 04:49:49 Dmitry V. Levin wrote: > > On Wed, Jun 18, 2014 at 08:58:20PM +0400, Dmitry V. Levin wrote: > > > On Wed, Apr 02, 2014 at 08:12:43PM +0400, Dmitry V. Levin wrote: > > > > There is quite enough good stuff accumulated in strace.git since v4.8 > > > > to release a new version. If you have pending patches to include > > > > > before the release, please submit them. > > > > > > Looks like this new -k option is not going to produce a reliable output > > > on all supported configurations so far, even basic strace-k.test is > > > > known to fail on x86 and arm. > > > > > > I'd rather document -k as an experimental option and make a release > > > > without further delays because of it. > > > > > > So please test HEAD on all supported architectures you can lay hands on. > > > > Has anybody had a chance to test it on something less widespread than > > > x86_64, x86, and arm? > > testing commit 1cd3f5f844d58b1ced8d3f6dc431688ed94d008e $ git describe 1cd3f5f844d58b1ced8d3f6dc431688ed94d008e v4.8 I suppose it's a bit too late to test v4.8. Could you test commit 212287c56c81c0bbe57f182e063d4b1e3bf850d3 instead, please? -- ldv |
From: Mike F. <va...@ge...> - 2014-08-07 03:43:51
Attachments:
signature.asc
logs.tar.bz2
|
On Thu 07 Aug 2014 05:04:33 Dmitry V. Levin wrote: > On Wed, Aug 06, 2014 at 06:49:04PM -0400, Mike Frysinger wrote: > > On Wed 06 Aug 2014 17:05:04 Dmitry V. Levin wrote: > > > On Tue, Aug 05, 2014 at 08:45:14PM -0400, Mike Frysinger wrote: > > > > testing commit 1cd3f5f844d58b1ced8d3f6dc431688ed94d008e > > > > > > $ git describe 1cd3f5f844d58b1ced8d3f6dc431688ed94d008e > > > v4.8 > > > > > > I suppose it's a bit too late to test v4.8. > > > > ugh, most of my checkouts are still using the old sf.net git location > > which is alive, but stuck at that rev. so you don't notice :x. guess > > i'll update my script to explicitly set the remote. > > How it could be dealt with on the old sf.net side? I suppose strace.git > is not unique in this respect, there must be a better way to handle > changing URLs. i don't think it's anything individual projects can handle if sf wants to deprecate the URLs, then delete the dns and/or turn off the git ports. people will notice it no longer works then. > I've just pushed commit 3c49b02e98af0aabfffd20fd8b34b1f71b8cffb9 > that should fix this: > $ grep -l '^FAIL: uio' tests/remote-test.*.log > tests/remote-test.hake.log > tests/remote-test.lgentoo3.log > tests/remote-test.ppc.log > tests/remote-test.sparc.log hmm, still no workie. updated logs attached. > These seem to be real rt_sigaction decoding bugs that remain to be fixed: > $ grep '^FAIL: sigaction' tests/remote-test.*.log > tests/remote-test.alpha.log:FAIL: sigaction > tests/remote-test.hake.log:FAIL: sigaction > tests/remote-test.sparc.log:FAIL: sigaction i'll take a peek > These are odd: > $ grep '^FAIL: detach' tests/remote-test.*.log > tests/remote-test.lantank.log:FAIL: detach-sleeping > tests/remote-test.lantank.log:FAIL: detach-stopped > tests/remote-test.lantank.log:FAIL: detach-running > tests/remote-test.polyp.log:FAIL: detach-sleeping > tests/remote-test.polyp.log:FAIL: detach-stopped > tests/remote-test.polyp.log:FAIL: detach-running > > I've seen failing detach-stopped when strace failed to leave tracee > stopped after detaching on 2.x kernels, but empty log is something new. maybe because they're old kernels ... -mike |
From: Dmitry V. L. <ld...@al...> - 2014-08-07 12:10:50
|
On Wed, Aug 06, 2014 at 11:43:49PM -0400, Mike Frysinger wrote: > > I've just pushed commit 3c49b02e98af0aabfffd20fd8b34b1f71b8cffb9 > > that should fix this: > > $ grep -l '^FAIL: uio' tests/remote-test.*.log > > tests/remote-test.hake.log > > tests/remote-test.lgentoo3.log > > tests/remote-test.ppc.log > > tests/remote-test.sparc.log > > hmm, still no workie. updated logs attached. Hopefully fixed with commit 20b84a676939cd0c4769626b88a55400d28dfe67. -- ldv |
From: Mike F. <va...@ge...> - 2014-08-07 13:04:31
Attachments:
signature.asc
|
On Thu 07 Aug 2014 16:10:42 Dmitry V. Levin wrote: > On Wed, Aug 06, 2014 at 11:43:49PM -0400, Mike Frysinger wrote: > > > I've just pushed commit 3c49b02e98af0aabfffd20fd8b34b1f71b8cffb9 > > > that should fix this: > > > $ grep -l '^FAIL: uio' tests/remote-test.*.log > > > tests/remote-test.hake.log > > > tests/remote-test.lgentoo3.log > > > tests/remote-test.ppc.log > > > tests/remote-test.sparc.log > > > > hmm, still no workie. updated logs attached. > > Hopefully fixed with commit 20b84a676939cd0c4769626b88a55400d28dfe67. yep, those 4 arches now pass the UIO test -mike |
From: Mike F. <va...@ge...> - 2014-08-09 13:36:53
Attachments:
signature.asc
|
On Wed 06 Aug 2014 23:43:49 Mike Frysinger wrote: > On Thu 07 Aug 2014 05:04:33 Dmitry V. Levin wrote: > > These seem to be real rt_sigaction decoding bugs that remain to be fixed: > > $ grep '^FAIL: sigaction' tests/remote-test.*.log > > tests/remote-test.alpha.log:FAIL: sigaction > > tests/remote-test.hake.log:FAIL: sigaction > > tests/remote-test.sparc.log:FAIL: sigaction > > i'll take a peek there were multiple bugs here. should be fixed now though with the patches i posted. once they're merged, i'll re-run the suite on all the boxes. -mike |
From: Dmitry V. L. <ld...@al...> - 2014-08-09 16:06:39
|
On Sat, Aug 09, 2014 at 09:36:41AM -0400, Mike Frysinger wrote: > On Wed 06 Aug 2014 23:43:49 Mike Frysinger wrote: > > On Thu 07 Aug 2014 05:04:33 Dmitry V. Levin wrote: > > > These seem to be real rt_sigaction decoding bugs that remain to be fixed: > > > $ grep '^FAIL: sigaction' tests/remote-test.*.log > > > tests/remote-test.alpha.log:FAIL: sigaction > > > tests/remote-test.hake.log:FAIL: sigaction > > > tests/remote-test.sparc.log:FAIL: sigaction > > > > i'll take a peek > > there were multiple bugs here. should be fixed now though with the patches i > posted. once they're merged, i'll re-run the suite on all the boxes. Merged, thanks! -- ldv |
From: Mike F. <va...@ge...> - 2014-08-10 02:13:07
Attachments:
signature.asc
|
i guess we're where we expected -- everything is passing except for the detach tests on older kernels. ia64 is still a toolchain problem. testing 6d18872b7b27352848c260875c840f20f864ffd4 (+ my thinko fix) vFAIL: test; armv7l linux-3.4.0-vapier kernel-headers-3.13.0 glibc-2.19 gcc-4.7. vFAIL: test; ia64 linux-3.12.13-gentoo kernel-headers-3.13.0 glibc-2.19 gcc-4.7. vFAIL: test; sh4 linux-2.6.30.9 kernel-headers-3.13.0 glibc-2.17 gcc-4.7.3 vPASS: alpha linux-3.16.0 kernel-headers-3.16.0 glibc-2.19 gcc-4.8.3 vPASS: i686 linux-3.14.2 kernel-headers-3.3.0 glibc-2.17 gcc-4.7.2 vPASS: parisc linux-3.8.0 kernel-headers-3.13.0 glibc-2.17 gcc-4.7.3 vPASS: ppc64 linux-3.12.20-gentoo kernel-headers-3.9.0 glibc-2.17 gcc-4.7.3 vPASS: ppc linux-3.12.20-gentoo kernel-headers-3.13.0 glibc-2.18 gcc-4.8.2 vPASS: s390 linux-3.14.0 kernel-headers-3.13.0 glibc-2.17 gcc-4.7.3 vPASS: s390x linux-3.14.0 kernel-headers-3.13.0 glibc-2.19 gcc-4.7.3 vPASS: sparc linux-3.15.6 kernel-headers-3.9.0 glibc-2.17 gcc-4.7.3 vPASS: x86_64 linux-3.14.2 kernel-headers-3.12.0 glibc-2.19 gcc-4.8.2 vPASS: aarch64 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.8.2 vPASS: armv4 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.8.0 vPASS: bfin cross kernel-headers-3.5.0 uclibc-0.9.33 gcc-4.5.3 vPASS: bfin-fdpic cross kernel-headers-3.5.0 uclibc-0.9.33 gcc-4.5.3 vPASS: m68k cross kernel-headers-3.16.0 glibc-2.19 gcc-4.8.0 vPASS: mips-n32 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.6.4 vPASS: mips-n64 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.6.4 vPASS: mips-o32 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.6.4 vPASS: sparc64 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.6.4 vPASS: tilegx cross kernel-headers-3.16.0 glibc-2.19 gcc-4.8.0 vPASS: x86_64 cross kernel-headers-3.16.0 glibc-2.19 gcc-4.9.0 -mike |
From: Mike F. <va...@ge...> - 2014-08-11 05:38:48
Attachments:
signature.asc
|
On Thu 07 Aug 2014 05:04:33 Dmitry V. Levin wrote: > These are odd: > $ grep '^FAIL: detach' tests/remote-test.*.log > tests/remote-test.lantank.log:FAIL: detach-sleeping > tests/remote-test.lantank.log:FAIL: detach-stopped > tests/remote-test.lantank.log:FAIL: detach-running > tests/remote-test.polyp.log:FAIL: detach-sleeping > tests/remote-test.polyp.log:FAIL: detach-stopped > tests/remote-test.polyp.log:FAIL: detach-running > > I've seen failing detach-stopped when strace failed to leave tracee > stopped after detaching on 2.x kernels, but empty log is something new. empty logs were due to bugs in the test scripts themselves :) with the fixes i posted, arm now passes. sh fails detach-stopped in the way you describe: $ cat tests/detach-stopped.log Process 10130 attached --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=0, si_uid=0} --- --- stopped by SIGSTOP --- brk(0) = 0x417000 brk(0x438000) = 0x438000 nanosleep({120, 0}, Process 10130 detached <detached ...> State: S (sleeping) detach-stopped.test: failed test: tracee is not group-stopped after detach should we just mark this as XFAIL on old kernels ? -mike |
From: Dmitry V. L. <ld...@al...> - 2014-08-11 18:00:50
|
On Mon, Aug 11, 2014 at 01:38:42AM -0400, Mike Frysinger wrote: [...] > empty logs were due to bugs in the test scripts themselves :) Looks like I haven't tested these scripts with a shell that doesn't disable "set -e" in the caller scope of a function that disables "set -e". > with the fixes i posted, arm now passes. > > sh fails detach-stopped in the way you describe: > $ cat tests/detach-stopped.log > Process 10130 attached > --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=0, si_uid=0} --- > --- stopped by SIGSTOP --- > brk(0) = 0x417000 > brk(0x438000) = 0x438000 > nanosleep({120, 0}, Process 10130 detached > <detached ...> > State: S (sleeping) > detach-stopped.test: failed test: tracee is not group-stopped after detach > > should we just mark this as XFAIL on old kernels ? If I only could find out what's the first kernel version that has no such issues, I'd certainly do it. -- ldv |
From: Mike F. <va...@ge...> - 2014-08-12 02:10:37
Attachments:
signature.asc
|
On Mon 11 Aug 2014 22:00:43 Dmitry V. Levin wrote: > On Mon, Aug 11, 2014 at 01:38:42AM -0400, Mike Frysinger wrote: > > sh fails detach-stopped in the way you describe: > > $ cat tests/detach-stopped.log > > Process 10130 attached > > --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=0, si_uid=0} --- > > --- stopped by SIGSTOP --- > > brk(0) = 0x417000 > > brk(0x438000) = 0x438000 > > nanosleep({120, 0}, Process 10130 detached > > > > <detached ...> > > > > State: S (sleeping) > > detach-stopped.test: failed test: tracee is not group-stopped after detach > > > > should we just mark this as XFAIL on old kernels ? > > If I only could find out what's the first kernel version that has no such > issues, I'd certainly do it. let's see what x86+qemu has to say for this test 2.6.34: skip 2.6.39.4: skip 3.0.101: skip 3.1.1: skip 3.2.62: skip 3.3.8: skip 3.4.91: pass 3.6.5: pass 3.10.49: pass so i guess your update to check for PTRACE_SEIZE is working :) i noticed that uio compiled fine (because i had a glibc that provided preadv/pwritev), but the unittest can abort at runtime (not entirely sure under what circumstances like kernel config): $ cat tests/uio.log uio: uio.c:24: main: Assertion `pwrite(fd, buf, sizeof buf, offset) == 4' failed. ./uio.test: line 16: 1378 Aborted ./uio uio.test: failed test: uio failed strace of uio itself shows: open("/dev/null", O_WRONLY|O_LARGEFILE) = 3 pwrite64(3, "\0\0\0\0", 4, 1004211379570065135) = -1 EFBIG (File too large) -mike |