On Wed, Aug 30, 2017 at 12:42 PM, Andreas Schwab wrote:
> The strace-k test always fails if getpid is implemented as a vsyscall:
Can you please provide some information about the environment in order
to reproduce it? It's quite unusual to me that vsyscall is used
somewhere.
--
Eugene Syromyatni
_start_main+0xf3) [0x182c3]
> unexpected_backtracing_error [0x56607000]
+++ exited with 0 +++
strace-k.test: failed test: ../../strace -e getpid -k ../stack-fcall output
mismatch
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EE
On Tue, 17 Jun 2014 04:16:27 +0400, "Dmitry V. Levin" wrote:
> On Mon, Jun 16, 2014 at 12:07:32PM +0900, Masatake YAMATO wrote:
>> How about x86_64?
>>
>> I guess testing on x86_64 is failed, too.
>
> No, on x86_64 the test always succeeds.
>
> On armv7hl it is unreliable: sometimes it succeeds
On Mon, Jun 16, 2014 at 12:07:32PM +0900, Masatake YAMATO wrote:
> How about x86_64?
>
> I guess testing on x86_64 is failed, too.
No, on x86_64 the test always succeeds.
On armv7hl it is unreliable: sometimes it succeeds
(e.g. https://koji.fedoraproject.org/koji/taskinfo?taskID=7043723),
someti
atake YAMATO wrote:
>> strace-k.test is failed on i386 GNU/Linux. I inspect the reason and it
>> seems that libunwind does not have enough ability to unwinding the
>> stack when pc is at [vdso]. However, I think stacktrace feature is
>> still useful even on i386 GNU/Linux. So t
On Thu, Jun 12, 2014 at 03:44:54AM +0900, Masatake YAMATO wrote:
> strace-k.test is failed on i386 GNU/Linux. I inspect the reason and it
> seems that libunwind does not have enough ability to unwinding the
> stack when pc is at [vdso]. However, I think stacktrace feature is
> still
strace-k.test is failed on i386 GNU/Linux. I inspect the reason and it
seems that libunwind does not have enough ability to unwinding the
stack when pc is at [vdso]. However, I think stacktrace feature is
still useful even on i386 GNU/Linux. So this patch relaxes the pass
condition of strace
