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

[Mathieu Desnoyers]

* Hirohisa Yamaguchi (umq at ueo.co.jp) wrote:
> 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.

Agreed.

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

commit dee093381aa4f642a707fb4b28dbb9df0b8ad155
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>

Thanks!

Mathieu


> 
> 
> 
> Regards,
> --
> 
> 	Hirohisa Yamaguchi
> 	  umq at ueo.co.jp

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com