GC bugs reference
David Banks
I figure there have been some bugs found recently that prompted the
move from libgc 7.1 to the CVS version. What were the bugs that
caused this?
Reason I ask is, I am trying to get Mosh 0.2.7 into Debian. It
probably won't be accepted with a bundled libgc, but if I can backport
the GC fixes from the CVS version to 7.1, I can build a mosh specific
patched libgc with DONT_ADD_BYTE_AT_END etc and it may be accepted.
Cheers,
--
David Banks <amo...@gmail.com>
okuoku
- snip -
> Reason I ask is, I am trying to get Mosh 0.2.7 into Debian. It
> probably won't be accepted with a bundled libgc, but if I can backport
> the GC fixes from the CVS version to 7.1, I can build a mosh specific
> patched libgc with DONT_ADD_BYTE_AT_END etc and it may be accepted.
Another Scheme interpreter, Gauche also needs DONT_ADD_BYTE_AT_ENDed BoehmGC.
and his Debian package includes statically linked libgc like Mosh.
So I think we can do the same as Gauche.
http://packages.qa.debian.org/g/gauche.html
Anyway, huge thank you to packaging effort and I'd love to bug-busting
for this activity.
Please drop a note here if any progress on this.
-- oku
David Banks
On 14 July 2011 13:06, okuoku <oku...@gmail.com> wrote:
> Another Scheme interpreter, Gauche also needs DONT_ADD_BYTE_AT_ENDed BoehmGC.
> and his Debian package includes statically linked libgc like Mosh.
> So I think we can do the same as Gauche.
I wish this was possible also, but Gauche has been in the archive
since 2003-ish, and was probably uploaded by a Debian developer. As I
am not an 'official' developer I need to find someone to sponsor the
package, and I think the requirements are a bit more strict now.
Here's what Michael Tautschnig wrote to me:
http://lists.debian.org/debian-mentors/2011/07/msg00326.html
So he suggests that I gather patches from 7.1 to CVS version, and
apply them to vanilla libgc at package build time. Note that mosh
would still end up with a statically linked libgc, but in the case of
security issues for libgc Mosh can be automatically rebuilt by the
libgc maintainer.
I know that having two slightly different environments like this can
cause bugs that are hard to track down, but I think this will be the
only way Mosh will go into Debian. Even if this doesn't work, I think
I will need to _prove_ that it does not work before using the Mosh
libgc will be considered.
> Anyway, huge thank you to packaging effort and I'd love to bug-busting
> for this activity.
> Please drop a note here if any progress on this.
If you are interested, I have a working package.
http://lists.debian.org/debian-mentors/2011/06/msg00227.html
It's the two issues mentioned that are stopping it from being
sponsored and uploaded.
okuoku
> Hi okuoku,
- snip -
> Here's what Michael Tautschnig wrote to me:
>
> http://lists.debian.org/debian-mentors/2011/07/msg00326.html
>
> So he suggests that I gather patches from 7.1 to CVS version, and
> apply them to vanilla libgc at package build time. Note that mosh
> would still end up with a statically linked libgc, but in the case of
> security issues for libgc Mosh can be automatically rebuilt by the
> libgc maintainer.
>
> I know that having two slightly different environments like this can
> cause bugs that are hard to track down, but I think this will be the
> only way Mosh will go into Debian. Even if this doesn't work, I think
> I will need to _prove_ that it does not work before using the Mosh
> libgc will be considered.
The reasons why I'm suggesting to embed Boehm GC into Mosh source tree are:
1) To support SystemTap (DTrace in Darwin/Solaris/FBSD)
I have several patch to introduce DTrace/SystemTap profiler
support.(But still not arrived to our git)
These patch inserts some code into BoehmGC and we cannot use these
probe in Darwin
unless we don't create any (intermediate, static) library. (This is
why 0.2.7 dropped libtool and directly build and link against embedded
Boehm GC.)
2) Use of C++ interface
As you stated, we use C++ interface of Boehm GC and it's quite error
prone part..
We disabled some code within C++ interface to fix Cygwin build.
(Both are not affects Linux builds but Debian is not the Linux only OS..)
For bootstrapping problem, Nmosh already supports bootstrapping
(rebuild-over-the-top).
I will include official support for this soon to allow users to
customize embedded library in nmosh binary.
Psyntax-mosh should be able to bootstrapped from Nmosh. So I think we
can take rebuild-over-the-top strategy.
-- oku
David Banks
On 14 July 2011 23:05, okuoku <oku...@gmail.com> wrote:
> 2011/7/15 David Banks <amo...@gmail.com>:
>> So he suggests that I gather patches from 7.1 to CVS version, and
>> apply them to vanilla libgc at package build time. Note that mosh
>> would still end up with a statically linked libgc, but in the case of
>> security issues for libgc Mosh can be automatically rebuilt by the
>> libgc maintainer.
>
> The reasons why I'm suggesting to embed Boehm GC into Mosh source tree are:
<snip>
> (Both are not affects Linux builds but Debian is not the Linux only OS..)
Hmm, ok - so it would be possible to build Mosh against a vanilla
libgc 7.1? This version of libgc is already in Debian, so it would be
easier to convince the maintainer to provide a source package so that
the mosh package could build against a DONT_ADD_BYTE_AT_END version.
I have built Mosh against 7.1 today and it is passing all tests.
So is it true that under Linux there's no known difference between
Mosh using libgc 7.1 and Mosh using libgc CVS version?
> For bootstrapping problem, Nmosh already supports bootstrapping
> (rebuild-over-the-top).
> I will include official support for this soon to allow users to
> customize embedded library in nmosh binary.
>
> Psyntax-mosh should be able to bootstrapped from Nmosh. So I think we
> can take rebuild-over-the-top strategy.
Cool. I have tried this out for psyntax-mosh today, building Mosh
once using the provided 'psyntax.scm' file, then rebuilding
'psyntax.scm' using the psyntax build script. That worked fine.
However I don't know about nmosh - as far as I can see, nmosh doesn't
have any precompiled parts shipped in the "mosh-0.2.7.tar.gz",
therefore it doesn't need to be built with the bootstrapping approach.
Am I right, or have I missed something?
okuoku
- snip -
> Hmm, ok - so it would be possible to build Mosh against a vanilla
> libgc 7.1? This version of libgc is already in Debian, so it would be
> easier to convince the maintainer to provide a source package so that
> the mosh package could build against a DONT_ADD_BYTE_AT_END version.
> I have built Mosh against 7.1 today and it is passing all tests.
>
> So is it true that under Linux there's no known difference between
> Mosh using libgc 7.1 and Mosh using libgc CVS version?
No. They occasionally brake if you stress the VM in amd64..
(In our observation, tests/thread.scm.)
It's somewhat hard to reproduce though.
> However I don't know about nmosh - as far as I can see, nmosh doesn't
> have any precompiled parts shipped in the "mosh-0.2.7.tar.gz",
> therefore it doesn't need to be built with the bootstrapping approach.
> Am I right, or have I missed something?
src/nmosh_image.cpp contains some precompiled R6 libraries and nmosh
expander in FASL format.
The contents of that is controlled by
boot/runtimes/srfi-mosh/layout.scm and I'll add some configure option
like --enable-bootstrap[=layout.scm] in the next version (0.2.8? or 0.3.0).
-- oku
David Banks
On 18 July 2011 18:52, okuoku <oku...@gmail.com> wrote:
>> So is it true that under Linux there's no known difference between
>> Mosh using libgc 7.1 and Mosh using libgc CVS version?
>
> No. They occasionally brake if you stress the VM in amd64..
> (In our observation, tests/thread.scm.)
> It's somewhat hard to reproduce though.
Hmm. I haven't been able to reproduce this using test_thread
(OSCompatThreadTest.cpp).
Do you have any idea of what code changes introduced in libgc CVS
fixed these stress issues?
>> However I don't know about nmosh - as far as I can see, nmosh doesn't
>> have any precompiled parts shipped in the "mosh-0.2.7.tar.gz",
>> therefore it doesn't need to be built with the bootstrapping approach.
>> Am I right, or have I missed something?
>
> src/nmosh_image.cpp contains some precompiled R6 libraries and nmosh
> expander in FASL format.
> The contents of that is controlled by
> boot/runtimes/srfi-mosh/layout.scm and I'll add some configure option
> like --enable-bootstrap[=layout.scm] in the next version (0.2.8? or 0.3.0).
Cool, this looks like it won't be a problem as all the stuff to
bootstrap nmosh was included in the tarball. Thanks for the info.
okuoku
> Hi okuoku,
>
> On 18 July 2011 18:52, okuoku <oku...@gmail.com> wrote:
>>> So is it true that under Linux there's no known difference between
>>> Mosh using libgc 7.1 and Mosh using libgc CVS version?
>>
>> No. They occasionally brake if you stress the VM in amd64..
>> (In our observation, tests/thread.scm.)
>> It's somewhat hard to reproduce though.
>
> Hmm. I haven't been able to reproduce this using test_thread
> (OSCompatThreadTest.cpp).
> Do you have any idea of what code changes introduced in libgc CVS
> fixed these stress issues?
I had no luck in finding particular GC commit(s)..
Bisecting gave me no meaningful result.
Anyway, I'm still not convinced using Debian's libGC instead of our
patched version.
Our GC(7.2) supports MIPS32 and plays well in other OS kernels like kFreeBSD.
(IIRC,) There is no language implementation which relies system provided libGC.
ie.) Is there any Debian's libgc user other than w3m or inkscape..?
I think maintaing mosh VM compatible for both GC 7.1 and GC 7.2 is not
so easy thing.
Especially when I adding profiling support with DTrace/SystemTap.
Of course, in general, software parts should be shared with other
software as many as possible.
In spite of this, for Mosh, GC is the only exception for this rule and
we have to use our own variant of GC to leave some room for future
improvement.
-- oku