Re: [Dar-libdar_api] Empty option for testing archives

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill a écrit :
> Hi Denis,

Hello Johnathan,

> 
> On Wednesday 02 May 2007 2:31 pm, Denis Corbin wrote:
>> This now in CVS Trunk.
>>
>> Regards,
>> Denis.
> 
> I've tried the empty option to op_test, and it works okay when running the 
> test in a single thread.

OK,

> 
> But sometimes, not all of the time, I get a SRC_BUG thrown at line 44 of 
> defile.cpp when testing the archive in two threads at once, one real test and 
> one empty test.

This is normal if you use the same object in two different treads (see
the explanation I have just written for further reference
http://dar.linux.free.fr/doc/FAQ.html#threadsafe ).

But this is not normal if you use two different objects in two different
threads or use the same object portected by a Posix Mutex for example.

> 
> Here is a test program that should reproduce the behaviour. You'll need to 
> edit the archive path to open an archive on your system. I compiled it with:
> 
> g++ -DLIBDAR_MODE=64 -fexceptions -L/usr/local/lib -lpthread -lattr -lcrypto -ldar64 -lz -lbz2 
> twothreadtest.cpp -o twothreadtest
> 
> Running "twothreadtest" from the command line several times in a row usually 
> shows the bug.

the archive pointed to by 'a' is passed to both threads thus the same
variable is modified by both threads at the same time. Morevoer, the
archive::op_test method() is not a constant method, but OK, I am not
sure that all const methods of the API can be used without mutex by
different threads on the same object at the same time. I will double
check this right now.

To solve your problem I would create two archive objects (yes, memory
will suffer) or avoid using concurrent thread here.

The problem is that archive::op_test() needs to read the contents of the
archive (this is the libdar::catalogue object stored inside the archive
object). This is done by several call to catalogue::read() method each
returning an inode object to be tested. Thus the libdar::catalogue
object is changed by each call to catalogue::read() for it provides the
next entry at each catalogue::read() call. The defile object stores the
complete path of the object and get confuses by the second thread that
let the catalogue object reach the end of catalogue too soon (the defile
object has several subdirectories to pop, thus expects at least some eod
from the catalogue).

I am just surprised that the problem does not arise every time!

> 
> Any ideas what the problem is?
> 
> Thanks,
> JB
> 

Regards,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGQGRCpC5CI8gYGlIRArmiAJ9+K04bPlfz0ScIXOYrytGQNqwM/ACfQktx
VWS8eRB8vZO6NQmYt/LzgTw=
=uWpt
-----END PGP SIGNATURE-----