[lttng-dev] userspace-rcu test scripts patches (was: ports/168339: [patch] sysutils/userspace-rcu update to 0.7.2

[Hirohisa Yamaguchi]

Hi,

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

> .....

> > > >  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
> 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.
 https://gist.github.com/2821618

I've built urcu with -g flag but, there still seems to be some problem
getting backtrace.



Regards,
--

	Hirohisa Yamaguchi
	  umq at ueo.co.jp