Re: Important bug fix in current trunk

Hi Etienne,

Thank-you for working on this, I'm sure it has bitten me in the past.  I 
looked at your changes and they really touch a lot of code.  Perhaps a 
less far-reaching solution is possible.  Can you detail the unsafe 
interleaving between threads that you discovered?  Can you explain 
exactly how your solution fixes it and what happens if two threads 
compete now?  I see the changes in prepare_code.c but I don't really see 
the difference in execution semantics.

Also, please note, that if you are depending on an ordering between 
reads/writes in different threads, your solution isn't valid on SMP 
machines unless the variables you are writing to are volatile OR the 
reads/writes are protected by a lock (pthread_mutex or simple CAS 
spinlock).  So if you are depending on a simple one-time "single-value 
replacement trick" it won't work out of the box.

Finally, it would be good to have a test-case shell script.  It is 
useful to have such a script because it can fairly easily be automated 
with Autotest later on, and because it is easier for other developers to 
run the test-case when asked to test the bugfix :)  I would suggest 
sablevm/tests as the directory for the script.

I'm assuming I can test and reproduce the bug with 
sablevm/branches/sablevm-lgpl (I am using x86_64 SMP), 
sablevm-classpath/trunk, and --enable-debugging-features.

Cheers,
Chris

Etienne Gagnon wrote:
> Hi all,
> 
> 1- Please test the current trunk and report back any problem you have.
> 2- It might be a good idea to refresh your sandbox with trunk code if
>    you are testing multi-threaded applications.
> 
> I have started, yesterday, to attack bug 172, a bug where an assertion
> was raised when copying an object during GC.  This seems weird, as it
> happened even with --enable-magic.  After a long debugging session
> involving core dump investigation, I finally found that the problem was
> due to a concurrency bug when threads competed on preparing a method.
> 
> To solve the problem, I had to change the content of stack frames, which
> lead to widespread changes.  I suspect that this should also solve some
> other problems that Greg, Chris, and Sebastien V. were experiencing with
> random crashes sometime, when starting multi-threaded applications.
> 
> Have fun, and thanks for your help testing the code!
> 
> Etienne
> 
> PS:  For those working on non-x86 platforms, I have created a temporary
> branch /sablevm/branches/sablevm-lgpl which include the fix (my primary
> development platform being Debian/PowerPC).  [The AL20 license change
> lead to removal of license-incompatible non-86 port code.  This should
> be eventually resolved using the atomic_ops library.]
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> SableVM-devel mailing list
> [email protected]
> http://sablevm.org/lists/control/listinfo/sablevm-devel