[lttng-dev] userspace-rcu test scripts patches (was: ports/168339: [patch] sysutils/userspace-rcu update to 0.7.2
umq at ueo.co.jp
Mon May 28 19:54:06 EDT 2012
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"
> 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.
> 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.
> . wrapper/seq.sh
> each test script:
> . wrapper/all.sh
> > > > 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.
> > 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
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
umq at ueo.co.jp
More information about the lttng-dev