Re: Problem in Thread.c
"Sébastien Adam" <[email protected]> Sun, 16 Apr 2006 22:53:43 +0000
| Newsgroups | gmane.comp.java.vm.sablevm.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============1805592928== Content-Type: multipart/alternative; boundary="----=_Part_7055_31013290.1145228023303" ------=_Part_7055_31013290.1145228023303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Hints for finding the problem: You could scan the heap, at the start of every GC, before copying any object, and verify that all lockwords do have their least significant bit set. You should also scan the heap at the end of GC, and do the same check. This would reveal whether the problem is in GC or elsewhere. It is already done... Everything is ok in the gc. > If not, then you should probably create a "personal tag"[*] by copying the version of your sandbox that exhibits the problem, and send us another message with the instructions to reproduce the problem. The following tag has been created. svn://svn.sablevm.org/developers/sadam/tags/lock_gc_bug To get the segmentation fault, you can use the following: ./autogen.sh ./configure --prefix=3D/usr/ --enable-debugging-features --with-gc=3Dgc make install java -jar sablecc.jar j14.scc Where sablecc.jar is at the version 2.18 and j14.scc is the java 1.4grammar. Both are found on sablecc.org. Seb On 4/16/06, Etienne Gagnon <[email protected]> wrote: > > Hi Sebastien, > > Can you reproduce this problem in a plain version of SableVM 1.13 (i.e. > without your new GC stuff)? If yes, can you submit a bug report at > http://sablevm.org/bugs.html with the instructions (and any required > code example) to reproduce the problem? > > If not, then you should probably create a "personal tag"[*] by copying > the version of your sandbox that exhibits the problem, and send us > another message with the instructions to reproduce the problem. > > [*] e.g. > $ export $SVN=3Dsvn+ssh://svn.sablevm.org/public/developers/sadam > $ svn cp [-r????]\ > $SVN/sandbox/[???] $SVN/tags/lock_gc_bug > > This will create the following tag for others to see: > > svn://svn.sablevm.org/developers/sadam/tags/lock_gc_bug > > The idea is that you can then continue changing your sandbox without > worrying, as others will fetch the "frozen snapshot" of your sandbox > represented by the tag. > > Hints for finding the problem: You could scan the heap, at the start of > every GC, before copying any object, and verify that all lockwords do > have their least significant bit set. You should also scan the heap at > the end of GC, and do the same check. This would reveal whether the > problem is in GC or elsewhere. > > Have fun! > > Etienne > > S=E9bastien Adam wrote: > > I developed a new generational gc in SableVM release 1.13. > > > > I get a segmentation fault at the last instruction in the following > > code. This instruction is found at line 1364 in the method > > _svmf_enter_object_monitor of Thread.c. > >... > > I don't work a lot with the Thread code but I don't think the problem i= s > > in _svmf_enter_object_monitor. Is there somebody that can help me to > > resolve this problem? Where should I look? > > -- > Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ > > > > _______________________________________________ > SableVM-devel mailing list > [email protected] > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > ------=_Part_7055_31013290.1145228023303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Hints for finding the problem: You could scan the heap, at the start of every GC, before copying any object, and verify that all lockwords do have their least significant bit set. You should also scan the heap at the end of GC, and do the same check. This would reveal whether the problem is in GC or elsewhere.<br> <br> It is already done... Everything is ok in the gc.<br> <br> > If not, then you should probably create a "personal tag"[*] = by copying<br> the version of your sandbox that exhibits the problem, and send us<br> another message with the instructions to reproduce the problem.<br> <br> The following tag has been created.<br> <div style=3D"direction: ltr;"><br> svn://svn.sablevm.org/developers/sadam/tags/lock_gc_bug<br> </div> <br> To get the segmentation fault, you can use the following:<br> <br>./autogen.sh <br> ./configure --prefix=3D/usr/ --enable-debugging-features --with-gc=3Dgc&nbs= p; <br> make install<br> java -jar sablecc.jar j14.scc <br> <br> Where sablecc.jar is at the version 2.18 and j14.scc is the java 1.4 gramma= r. Both are found on <a href=3D"http://sablecc.org">sablecc.org</a>.<= br> <br> Seb<br> <br><div><span class=3D"gmail_quote">On 4/16/06, <b class=3D"gmail_senderna= me">Etienne Gagnon</b> <<a href=3D"mailto:[email protected]">egagnon@s= ablevm.org</a>> wrote:</span><blockquote class=3D"gmail_quote" style=3D"= border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddi= ng-left: 1ex;"> Hi Sebastien,<br><br>Can you reproduce this problem in a plain version of S= ableVM 1.13 (i.e.<br>without your new GC stuff)? If yes, can you= submit a bug report at<br><a href=3D"http://sablevm.org/bugs.html">http://= sablevm.org/bugs.html </a> with the instructions (and any required<br>code example) to reproduce = the problem?<br><br>If not, then you should probably create a "persona= l tag"[*] by copying<br>the version of your sandbox that exhibits the = problem, and send us <br>another message with the instructions to reproduce the problem.<br><br>= [*] e.g.<br>$ export $SVN=3Dsvn+ssh://svn.sablevm.org/public/developers/sad= am<br>$ svn cp [-r????]\<br> $SVN/sandbox/[???] $SVN/tags/lock_g= c_bug<br> <br>This will create the following tag for others to see:<br><br> svn://svn= .sablevm.org/developers/sadam/tags/lock_gc_bug<br><br>The idea is that you = can then continue changing your sandbox without<br>worrying, as others will= fetch the "frozen snapshot" of your sandbox <br>represented by the tag.<br><br>Hints for finding the problem: &nbs= p;You could scan the heap, at the start of<br>every GC, before copying any = object, and verify that all lockwords do<br>have their least significant bi= t set. You should also scan the heap at <br>the end of GC, and do the same check. This would reveal whet= her the<br>problem is in GC or elsewhere.<br><br>Have fun!<br><br>Etienne<b= r><br>S=E9bastien Adam wrote:<br>> I developed a new generational gc in = SableVM release=20 1.13.<br>><br>> I get a segmentation fault at the last instruction in= the following<br>> code. This instruction is found at line 1364 in the = method<br>> _svmf_enter_object_monitor of Thread.c.<br>>...<br>> I= don't work a lot with the Thread code but I don't think the problem is <br>> in _svmf_enter_object_monitor. Is there somebody that can help me = to<br>> resolve this problem? Where should I look?<br><br>--<br>Etienne = M. Gagnon, Ph.D.  = ; <a href=3D"http://www.info2.uqam.ca/~egagnon/"> http://www.info2.uqam.ca/~egagnon/</a><br>SableVM: &= nbsp; &nbs= p; &= nbsp; <a href=3D"http://www.sablevm.org/">http://www.sablevm.org/</a><br>SableCC:= &nb= sp; = &nb= sp; <a href=3D"http://www.sablecc.org/">http://www.sablecc.org/</a><br><br><br>= <br>_______________________________________________<br>SableVM-devel mailin= g list<br><a href=3D"mailto:[email protected]">SableVM-devel@sablev= m.org </a><br><a href=3D"http://sablevm.org/lists/control/listinfo/sablevm-devel"= >http://sablevm.org/lists/control/listinfo/sablevm-devel</a><br><br><br><br= ></blockquote></div><br> ------=_Part_7055_31013290.1145228023303-- --===============1805592928== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SableVM-devel mailing list [email protected] http://sablevm.org/lists/control/listinfo/sablevm-devel --===============1805592928==--