[lttng-dev] userspace-rcu test scripts patches (was: ports/168339: [patch] sysutils/userspace-rcu update to 0.7.2
mathieu.desnoyers at efficios.com
Mon May 28 22:09:46 EDT 2012
* Hirohisa Yamaguchi (umq at ueo.co.jp) wrote:
> At Mon, 28 May 2012 11:00:36 -0400,
> Mathieu Desnoyers wrote:
> > > I think there're two different purposes of tests:
> > > 1. for developers to ensure the implementations are correct
> > > 2. for users to see his/her environment is safe to use the feature
> > > -- built without an error does not mean it runs okay
> > > I think bashisms do not suit for latter purpose.
> > I agree that we should not depend on "bash" for any script installed
> > into the system.
> > However, the "tests/" subdirectory is not currently installed on the
> > user system. It's only used for in-tree testing, and "make check"
> > execution.
> > There might come a point where we want to deploy some tests into the
> > system so the library users can run them, I don't know. Maybe not yet
> > though, as we would need to clean them up first.
> I meant `users' to be a person who wants to port the product to
> his/her environment or maintain package of the product.
> I doubt that end users such as one who brings binaries from the OS's
> package repository would run the test scripts when they're installed
> into the system.
> > So at this stage, I would be fine with specifying in the README that
> > running tests depends on bash.
> I understand.
> > However, if we can provide a wrapper for
> > all the commands we need, which would be sourced by all scripts in the
> > tests/ directory, which implements all wrappers into per-wrapper files,
> > sourced by one toplevel wrapper file, I would be open to that too, given
> > that it would make deployment of tests simpler for systems lacking bash
> > support. e.g.
> > tests/wrapper/all.sh
> > . wrapper/seq.sh
> > .....
> > tests/wrapper/seq.sh
> > tests/wrapper/....
> > each test script:
> > #!/bin/sh
> > . wrapper/all.sh
> > .....
Although I don't personally have the resources to create these wrappers,
I would be willing to take a patch that implements them. ;-)
> > > > > 5. NUM_CPUS might be determined at runtime:
> > > > So I would recommend making this a
> > > > parameter, and autodetect only if no parameter is provided. The
> > > > autodetect would indeed have to be OS-specific. We could implement a
> > > > get_nr_cpu.sh script within tests/ that detects the number of CPUs on
> > > > the current OS.
> > >
> > > That sounds good.
> > Can you prepare a patch for this ?
> I'll try next weekend.
Thanks! I look forward to see it.
> > > At Sun, 27 May 2012 15:44:12 -0400,
> > > Mathieu Desnoyers wrote:
> > > > > > # btw, test_perthreadlock under FreeBSD 10-CURRENT always fails
> > > > > > # (releases prior to 9.0 are okay).
> > OK, so it seems to be reproducible on both AMD and Intel, that's good
> > news.
> I observed the error on both 32bits and 64bits, to add.
> > You might want to compile userspace rcu with:
> > make CFLAGS=-g
> > to get debug symbols for the library. It will provide a more helpful
> > backtrace. We should consider that the issue can come from a race
> > between pthread_create and pthread_mutex_lock too.
> Here's another log file.
> I've built urcu with -g flag but, there still seems to be some problem
> getting backtrace.
Ah, I got it. It's a simple uninitialized mutex. The "0x5a5a5a5a"
pattern caught my attention. Fixed by upstream commit:
Author: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
Date: Mon May 28 22:10:54 2012 -0400
Test fix: test_perthreadlock uninitialized mutex
- Initialize the per thread mutexes. (fix)
- Remove unused count_reader/count_writer variables. (cleanup)
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> Hirohisa Yamaguchi
> umq at ueo.co.jp
Operating System Efficiency R&D Consultant
More information about the lttng-dev