Bugs report
deutsch@polyspace.com
deutsch@polyspace.com
Wed, 24 Jan 2001 14:43:42 +0100
--------------FD4C32128F0ED0A0EA7FE63D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Stephen Weeks" wrote:
Thanks for the bug report.
> * using environ crashes: there is a mismatch between its effective
> C type and its declared ML type. The fix is easy.
Yes. We fixed that bug on 2000-12-04. The fix is to change the C code
so
that Posix_ProcEnv_environ is a pointer, not a procedure. There was
also
another bug that requires the basis library implementation to be changed
so that
it converts the C array of strings to a list at each call to
Posix.ProcEnv.environ ().
> * the Main() mfs parameter (used to initialise s->maxFrameSize) is
> sometimes a few bytes less than the maximum of sizes of frames. This
can
> result in a spurious assert() failed in gc.c in debug mode. Do you
have
> a fix ? What are the potential consequences ?
Yes. We fixed that bug on 2000-10-17. It required a small change to
the
backend in the compiler so that the maxFrameSize is correct. The
potential
consequences are a segfault. If you want to run in debug mode without
fixing
the problem, you can comment out the assert, but you may still see the
segfault.
Both of these bugs have been fixed in our internal working version and
will
appear in the next release of MLton. This should appear within the next
few
weeks. If you need a fix sooner, I can patch 20000906-2 and make that
available.
I would appreciate this very much. At this point, the workaround I
implemented consists in changing the Main macro so that we add 32 bytes
to the passed parameter. It seems to do the trick on my application but
this is rather unelegant and fragile.
Thank you. Are you using SML at polyspace? I am familiar with some of
your
previous work and I checked out your website. I guess you have
implemented
parts of your analysis tools in some ML variant? Or are you just
testing them
on MLton's C output?
Yes, we are intensively using SML (/NJ at this point) for our line of
products. At this point we are looking for alternatives to SML/NJ for
several reasons:
* independence from a compiler provider;
* there are several spurious (segfault like) bugs in NJ 110.9.1
and 110.0.7 and other with the Linux code generator (OK on Sparc);
* the prospect of gaining execution speed.
At this point we are in the process of porting a significant subsystem
of our product with your compiler.
Apart from the bugs refered to earlier, there was a third problem which
I fixed: your runtime refuses to swap ! More precisely it prefers
suicide to growing heap beyond actual RAM.
Is your company using MLTON for industrial products ? Are there plans
for selling MLTON ?
Sincerely,
Alain Deutsch.
--------------FD4C32128F0ED0A0EA7FE63D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Stephen Weeks" wrote:
<blockquote TYPE=CITE>Thanks for the bug report.
<p>> * using environ crashes: there is a mismatch
between its effective
<br>> C type and its declared ML type. The fix is easy.
<p>Yes. We fixed that bug on 2000-12-04. The fix is to change
the C code so
<br>that Posix_ProcEnv_environ is a pointer, not a procedure. There
was also
<br>another bug that requires the basis library implementation to be changed
so that
<br>it converts the C array of strings to a list at each call to
<br>Posix.ProcEnv.environ ().
<p>> * the Main() mfs parameter (used to initialise
s->maxFrameSize) is
<br>> sometimes a few bytes less than the maximum of sizes of frames. This
can
<br>> result in a spurious assert() failed in gc.c in debug mode. Do you
have
<br>> a fix ? What are the potential consequences ?
<p>Yes. We fixed that bug on 2000-10-17. It required a small
change to the
<br>backend in the compiler so that the maxFrameSize is correct.
The potential
<br>consequences are a segfault. If you want to run in debug mode
without fixing
<br>the problem, you can comment out the assert, but you may still see
the
<br>segfault.
<p>Both of these bugs have been fixed in our internal working version and
will
<br>appear in the next release of MLton. This should appear within
the next few
<br>weeks. If you need a fix sooner, I can patch 20000906-2 and make
that
<br>available.</blockquote>
I would appreciate this very much. At this point, the workaround I implemented
consists in changing the Main macro so that we add 32 bytes to the passed
parameter. It seems to do the trick on my application but this is rather
unelegant and fragile.
<blockquote TYPE=CITE>Thank you. Are you using SML at polyspace?
I am familiar with some of your
<br>previous work and I checked out your website. I guess you have
implemented
<br>parts of your analysis tools in some ML variant? Or are you just
testing them
<br>on MLton's C output?</blockquote>
Yes, we are intensively using SML (/NJ at this point) for our line of products.
At this point we are looking for alternatives to SML/NJ for several reasons:
<ul>
<li>
independence from a compiler provider;</li>
<li>
there are several spurious (segfault like) bugs in NJ 110.9.1 and 110.0.7
and other with the Linux code generator (OK on Sparc);</li>
<li>
the prospect of gaining execution speed.</li>
</ul>
At this point we are in the process of porting a significant subsystem
of our product with your compiler.
<p>Apart from the bugs refered to earlier, there was a third problem which
I fixed: your runtime refuses to swap ! More precisely it prefers suicide
to growing heap beyond actual RAM.
<p>Is your company using MLTON for industrial products ? Are there plans
for selling MLTON ?
<p> Sincerely,
<p> Alain Deutsch.
<br> </html>
--------------FD4C32128F0ED0A0EA7FE63D--