Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa
On Fri, Jan 7, 2022 at 3:51 PM Ryan Kavanagh wrote:
> Control: tags -1 + confirmed
> Control: retitle -1 mlton cannot rebuild itself on hppa or i386
>
> On Thu, Jan 06, 2022 at 07:55:00PM +, John David Anglin wrote:
> > It fails with a reproducible segmentation fault.
>
> I can reproduce this even with the latest upstream HEAD on the hppa
> porterbox, using
>
> make BOOTSTRAP_STYLE=3
>
> which makes it this far:
>
> -8<-
> make compiler SELF_COMPILE=true CHECK_FIXPOINT=true # tools2 + mlton2
> -> mlton3; mlton3 == mlton2
> [...]
> chmod -w front-end/mlb.grm.*
> sed \
> -e "s/MLTON_NAME/MLton/" \
> -e "s/MLTON_VERSION//" \
> < control/version_sml.src \
> > control/version.sml
> (cat control/version_sml.src; echo 'MLton' ''; cat
> control/version.sml) | sha1sum | sed 's/.*\([a-z0-9]\{40\}\).*/\1/' >
> control/version_sml.chk
> Compiling mlton
> "/home/rak/mlton/build/bin/mlton" \
> @MLton ram-slop 0.7 gc-summary -- \
> -default-ann 'sequenceNonUnit warn' -default-ann 'warnUnused true'
> -verbose 2 \
> -target self -output mlton-compile \
> mlton.mlb
> MLton starting
>Compile SML starting
> frontend starting
> parseAndElaborate starting
> Segmentation fault
> make[2]: *** [Makefile:72: mlton-compile] Error 139
> make[2]: Leaving directory '/home/rak/mlton/mlton'
> make[1]: *** [Makefile:75: compiler] Error 2
> make[1]: Leaving directory '/home/rak/mlton'
> make: *** [Makefile:29: all] Error 2
> -8<-
>
This looks like the "old" MLton successfully compiled the "new" mlton
(mlton1), which then went on to successfully compile the tools (mllex,
mlyacc, ...) and a second round of self-compilation (mlton2), which itself
went on to successfully compile the tools, but failed when trying to
perform a third round of self-compile (mlton3). That's pretty surprising.
To get some debugging information, I would suggest compiling with
`MLTON_COMPILE_ARGS="-keep g -debug true"`. The "-keep g" instructs MLton
to keep the generated .c files and the "-debug true" instructs MLton to
compile the generated .c files with "-g" and to link to a version of the
runtime system itself compiled with "-g".
On HPPA, MLton doesn't have a native codegen, so the default is `-codegen
c`.
> On Thu, Jan 06, 2022 at 06:04:18PM -0600, Henry Cejtin wrote:
> > ssume that it isn't reproducible on AMD, right?
> > Or better, x86 (32 bit)?
>
> Not reproducible on amd64, but it is reproducible on i386, even with
> codegen c:
>
> make BOOTSTRAP_STYLE=3 MLTON_COMPILE_ARGS='-codegen c'
>
> segfaults at
>
> -8<-
> make compiler CHECK_FIXPOINT=false # tools0 + mlton0
> -> mlton1
> make[1]: Entering directory '/home/rak/i386/mlton-20210117+dfsg'
> make -C "/home/rak/i386/mlton-20210117+dfsg/mlton"
> make[2]: Entering directory '/home/rak/i386/mlton-20210117+dfsg/mlton'
> Compiling mlton
> "mlton" \
> @MLton ram-slop 0.7 gc-summary -- \
> -verbose 2 \
> -target self -output mlton-compile \
> mlton-stubs.mlb
> MLton 20210117+dfsg-3 starting
>Compile SML starting
> frontend starting
> parseAndElaborate starting
> Segmentation fault
> -8<-
>
This looks like the "old" MLton didn't get very far compiling the "new"
MLton. The `MLTON_COMPILE_ARGS="-codegen c"` doesn't have any effect,
because those are only used when the "new" MLton is performing a second or
third round of self-compiling. (You could use `OLD_MLTON_COMPILE_ARGS` to
influence the "old" MLton compiling the "new" MLton; this isn't even
getting to the point where the choice of codegen would have any effect.)
Of course, my understanding is that with Ryan's work, the "old" MLton isn't
even really that old --- it's just a binary package of the current sources,
considered "old" enough to be used as a prereq for building the sources.
Is there any chance that the issue is due to a (potential) mismatch
> between flags involving pic/pie we pass in via -cc-opt $(CFLAGS), and
> the default target-determined default? mlton has the flags -pi-style and
> -native-pic thanks to https://github.com/MLton/mlton/pull/365 that may
> need setting. (I haven't yet investigated this.) Debian used to carry a
> patch that forced PIC to fix a FTBFS on amd64, and I dropped it this
> most recent release because I thought it was no longer required (mlton
> built fine without it).
>
By default (i.e., without explicitly setting the `-pi-style` flag), MLton
should simply follow the behavior of the C compiler (and will not pass any
special flags to the C compiler). Typically, a mismatch involving pic/pie
manifests as a linking error, because one object file isn't using a symbol
in a way compatible with the defining object file.
Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa
Although MLton does understand about running out of memory (when an `mmap` request fails), on recent versions of Linux, I've observed that the OOM killer will sometimes step in before a failing `mmap` request. But, I wouldn't think that that would manifest itself as a seg fault. In any case, I would think that 3G would be enough for a self compile; recent builds on amd64-linux show a max live of 887K. On Thu, Jan 6, 2022 at 3:33 PM Henry Cejtin wrote: > MLton understands about running out of memory, so it shouldn't just > segfault. > If it isn't too hard, could you try it with Linux overcommit turned off? > > On Thu, Jan 6, 2022 at 1:57 PM John David Anglin > wrote: > > > > Source: mlton > > Version: 20130715-3 > > Severity: normal > > > > Dear Maintainer, > > > > Because of dependency problems mlton_20210117+dfsg-3 had to built > > manually on hppa. However, it seems mlton_20210117+dfsg-3 cannot > > rebuild itself on hppa. > > > > See log: > > > https://buildd.debian.org/status/fetch.php?pkg=mlton=hppa=20210117%2Bdfsg-3=1641492022=0 > > > > It fails with a reproducible segmentation fault. I noticed the compiler > > had allocated more than 2G at this point, so there was probably a memory > > allocation issue. hppa is a 32-bit architecture. > > > > Regards, > > Dave Anglin > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers buildd-unstable > > APT policy: (500, 'buildd-unstable'), (500, 'unstable') > > Architecture: hppa (parisc64) > > > > Kernel: Linux 5.16.0-rc8+ (SMP w/4 CPU threads) > > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > > >
Bug#995467: Salvaging status
Great news! I'm going to incorporate some of the bootstrap changes that we identified on the GitHub issue into `master` in the next couple of weeks. Hopefully, I'll also be able to cut a 202201?? release shortly after the new year. -Matthew On Sun, Dec 19, 2021 at 10:33 PM Ryan Kavanagh wrote: > Another status update for those following at home: > > The mlton package (upstream release 20210117) now bootstraps and builds! > > For some reason I can't get the guide to compile (pdflatex spits out a > bunch of errors and then dies, and the tool that calls pdflatex suggests > the docbook input is invalid), so I might just temporarily disable > building/installing it. I figure having an installable mlton package > sans PDF guide is better than having no mlton package whatsoever in the > meantime. > > I have considerably more time to work on this now that the semester is > over, so I'm hoping to get it uploaded in the next week or so. > > Best, > Ryan > > -- > |)|/ Ryan Kavanagh | 4E46 9519 ED67 7734 268F > |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A >
Bug#998156: contains non-DFSG-free files
Henry is correct that the MLton compiler (the runtime, basis library implementation, and compiler proper) do not depend on ckit (or any of the (re)distributed SML/NJ libraries), the benchmarks, or on mlnlffigen, nor are those components required for using MLton (unless, of course, the program being compiled explicitly references them). If Debian wants to carve up the packages for MLton in a different way, then that seems fine, but I'm not inclined to do serious rearrangements of the GitHub repository or of the source releases that we (upstream) package. I appreciate the licensing issue, but consider it fairly low stakes for decades old code. Florian is correct that MLton has packaged mlnlffigen both out of convenience (as we have packaged mllex and mlyacc) for users and because MLton requires the tool to generate slightly different code. On Mon, Nov 1, 2021 at 3:55 PM Henry Cejtin wrote: > Your right, but I think (not on the basis of real knowledge) that > ml-nlffigen isn't used in either the compilation > of the MLton compiler, nor by the MLton compiler in compiling user > code. I thought that it was > for a MLton compiler user to use, and had been tweaked so that the > output was usable by MLton. > > I certainly could be wrong about this. >
Bug#917644: FTBFS: segmentation faults in test suite
On Wed, Feb 20, 2019 at 8:06 AM Thierry fa...@linux.ibm.com < thie...@linux.ibm.com> wrote: > On Tue, 19 Feb 2019 16:50:00 +0100 "Thierry fa...@linux.ibm.com" > wrote: > > On Mon, 7 Jan 2019 16:49:41 + Steve McIntyre > wrote: > > > Hi Matthew, > > > > > > On Sun, Dec 30, 2018 at 05:38:57PM -0500, Matthew Fluet wrote: > > > >If it is just the `world` regression tests that are failing, then it > > > >is almost certainly due to save/restore world being incompatible with > > > >ASLR; see http://mlton.org/MLtonWorld#_notes. Perhaps Debian > > > >arm64-linux has gained ASLR since the last time the regression suite > > > >was run on this platform? In any case, you'll notice that the `world` > > > >regression tests are explicitly whitelisted (i.e., these tests failing > > > >do not cause a failure exit status from the regression script) because > > > >of this issue. > > > > > As this bug is not specifically opened for one arch, I also want to > > mention it fails on ppc64el. I see the sequence > > testing wordn-array > > testing world1 > > 2c2,3 > > < I am the clone > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world1: difference with -type-check true > > testing world2 > > 1c1,2 > > < 30 > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world2: difference with -type-check true > > testing world3 > > 1c1,2 > > < caught foo > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world3: difference with -type-check true > > testing world4 > > 4,6c4,5 > > < between saves > > < after saves > > < after saves > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world4: difference with -type-check true > > testing world5 > > 2c2,3 > > < success > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world5: difference with -type-check true > > testing world6 > > 1,4c1 > > < ./world6 > > < a > > < b > > < c > > --- > > This pad is hosted in Toulouse LTC lab. Created at 2019-02-19 09:45:56. > > Hi, > I have run make check without world tests and result is code 1 because > of failing tests on some architectures > testing mlton.overload > testing mlton.share > 1c1 > < size of a is 1600 > --- > > size of a is 2408 > 102c102 > < size of a is 484 > --- > > size of a is 920 > > testing size2 > 2,23c2,23 > < The size of an int list of length 4 is = 48 bytes. > < The size of a string of length 10 is = 24 bytes. > < The size of an int array of length 10 is = 52 bytes. > < The size of a double array of length 10 is = 92 bytes. > < The size of a (word32 * double) array of length 10 is = 132 bytes. > < The size of a (word32 * word32 * double) array of length 10 is = 172 > bytes. > < The size of a (word64 * double) array of length 10 is = 172 bytes. > < The size of a (word16 * double) array of length 10 is = 132 bytes. > < The size of a word64 array of length 10 is = 92 bytes. > < The size of a (word32 * word64) array of length 10 is = 132 bytes. > < The size of a (word32 * word32 * word64) array of length 10 is = 172 > bytes. > < The size of a (word64 * word64) array of length 10 is = 172 bytes. > < The size of a (word16 * word64) array of length 10 is = 132 bytes. > < The size of an array of length 10 of 2-ples of ints is = 92 bytes. > < The size of an array of length 10 of 2-ples of (shared) ints is = 92 > bytes. > < The size of an array of length 10 of arrays of length 20 of ints is = > 972 bytes. > < The size of an array of length 10 of (shared) arrays of length 20 of > ints is = 144 bytes. > < The size of an array of length 10 of tuples of word16 * (arrays of > length 20 of ints) is = 1012 bytes. > < The size of an array of length 10 of tuples of word32 * (arrays of > length 20 of ints) is = 1012 bytes. > < The size of an array of length 10 of tuples of word64 * (arrays of > length 20 of ints) is = 1052 bytes. > < The size of an array of length 10 of tuples of real32 * (arrays of > length 20 of ints) is = 1012 bytes. > < The size of an array of length 10 of tuples of real64 * (arrays of > length 20 of ints) is = 1052 bytes. > --- > > The size of an int list of length 4 is = 96 bytes. > > The size of a string of leng
Bug#917644: FTBFS: segmentation faults in test suite
If it is just the `world` regression tests that are failing, then it is almost certainly due to save/restore world being incompatible with ASLR; see http://mlton.org/MLtonWorld#_notes. Perhaps Debian arm64-linux has gained ASLR since the last time the regression suite was run on this platform? In any case, you'll notice that the `world` regression tests are explicitly whitelisted (i.e., these tests failing do not cause a failure exit status from the regression script) because of this issue. On Sat, Dec 29, 2018 at 12:57 PM Steve McIntyre wrote: > > Package: src:mlton > Version: 20180207-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > Hi! > > I've been doing a full rebuild of the Debian archive, building all > source packages targeting armel and armhf using arm64 hardware. We are > planning in future to move all of our 32-bit armel/armhf builds to > using arm64 machines, so this rebuild is to identify packages that > might have problems with this configuration. > > I found that mlton is failing with segfaults in its test suite. > Looking further, I can see that the same problem is showing up on our > buildds for at least arm64 and armel too. I was going to try and debug > the problem: > > ... > testing world6 > 1,4c1 > < ./world6 > < a > < b > < c > --- > > Segmentation fault (core dumped) > ... > > (sid-armel)steve@mjolnir:~/debian/build/mlton/mlton-20180207$ find . -name > core > ./regression/core > (sid-armel)steve@mjolnir:~/debian/build/mlton/mlton-20180207$ file > regression/core > regression/core: ELF 32-bit LSB core file, ARM, version 1 (SYSV), SVR4-style, > from './world6 @MLton load-world /tmp/worldW1WpTw -- a b c', real uid: 1000, > effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: './world6', > platform: 'v8l' > > But it appears that the test suite helpfully carries on after crashes > and even deletes the binaries it's made: > > (sid-armel)steve@mjolnir:~/debian/build/mlton/mlton-20180207$ find . -name > world6 > (sid-armel)steve@mjolnir:~/debian/build/mlton/mlton-20180207$ > > So I'm stopping here. > > -- System Information: > Debian Release: 9.6 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) >
Bug#791936: Please support ARM64 (upstream porting work needed)
A patch to build on arm64 (aarch64) Debian unstable was recently submitted via Debian Bug #762143 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762143#15) and has been committed upstream (https://github.com/MLton/mlton/pull/113). On Thu, Jul 9, 2015 at 12:21 PM, Martin Michlmayr t...@hp.com wrote: Package: mlton Version: 20100608-5.1 Severity: wishlist User: debian-...@lists.debian.org Usertags: arm64 port This package fails to build on arm64, but a quick looks suggests this package might be useful on arm64. Do you know if upstream or someone else is working on arm64 support (aarch64) already? -- Martin Michlmayr Linux for HP Helion, Hewlett-Packard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
