linuxtuples-devel

[Linuxtuples-devel] race condition in dump op

[Bram S. <br...@sa...>]

Hello,


To initiate this mailing list:
I stumbled upon another race condition.
It is less serious, as it only happens when doing a dump operation.

What happens is this:
For the dump op, the server locks the tspace to create a list of
its contents.
Then it releases the lock.
After the release it sends the tuples.
However... when tuples are removed between unlock and sending, their
memory can be freed, causing a 'Bad address' in the send() syscall.

The fix is to move the YIELDACCESS down (and do it twice: also in
early return).

I cannot commit to cvs, as cvs is now completely gone: both
developer cvs and user cvs are not working.



  Bram


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."

Re: [Linuxtuples-devel] race condition in dump op

[Will W. <ww...@al...>]

On 5/10/06, Bram Stolk <br...@sa...> wrote:
> I stumbled upon another race condition.
> when tuples are removed between unlock and sending, their
> memory can be freed, causing a 'Bad address' in the send() syscall.
> The fix is to move the YIELDACCESS down (and do it twice: also in
> early return).

Alternatively, we could do reference counting on tuples, so that we
didn't have to lock the whole space for all that time. Dumping is
something you'd do when debugging the space, and hopefully an
infrequent occurrence, so the effort of adding reference counts is
probably not warranted.

> I cannot commit to cvs, as cvs is now completely gone: both
> developer cvs and user cvs are not working.

It doesn't work for me either. Sourceforge also offers Subversion as
an alternative to CVS. I understand that Subversion has many features
and improvements that make it better than CVS, but I think the problem
we are both having at the moment is due to server downtime, not
deficiencies in CVS. Switching to Subversion wouldn't guarantee more
server uptime.

Info about Subversion on Sourceforge
http://sourceforge.net/docman/display_doc.php?docid=3D31070&group_id=3D1

I think I'll need some time to wrap my brain around Subversion. It's
one of those things I've intended to learn about for a while. I have
no problem with migrating from CVS to Subversion but I am not prepared
to do it immediately.

Will Ware

Re: [Linuxtuples-devel] race condition in dump op

[Bram S. <br...@sa...>]

Will Ware wrote:

> and improvements that make it better than CVS, but I think the problem
> we are both having at the moment is due to server downtime, not
> deficiencies in CVS. Switching to Subversion wouldn't guarantee more
> server uptime.

Oh.. but in practice, it does!
SF's SVN is much more reliable.
It is the cvs service that keeps breaking down.

I do a lot of work for opende.sf.net and since this project switched
from cvs to svn, the reliability is so much better.
 
> Info about Subversion on Sourceforge
> http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1
> 
> I think I'll need some time to wrap my brain around Subversion. It's
> one of those things I've intended to learn about for a while. I have
> no problem with migrating from CVS to Subversion but I am not prepared
> to do it immediately.

Ok,

There is a specific 'svn for cvs users' tutorial out there that may
help.

The basics are pretty simple: version nrs (revisions) are designated
to entire source trees. If you change a single README, the rev goes
up for the tree.

Commits are done on a collection of files. If you change a .h, a .c
and a README and commit in 1 go, the change is a single entity that
brings the tree to a new revision nr.

You typically work with the mainbranch of the repository, which is called
'trunk'.

Other than that, the cmds are very similar:

cvs co -> svn co
cvs commit -> svn commit
cvs update -> svn update
cvs update -n -> svn status
cvs annotate -> svn annotate
..etc..

Also: history is preserved when going from SF cvs to SF svn.

Bonus: passwds are only req'd when needed (committing) and not
for simple stuff like diff, update, annotate, etc.

    bram

> 
> Will Ware
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642
> _______________________________________________
> Linuxtuples-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxtuples-devel


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."