[MLton-user] mlton on sparc-solaris10 ?

Stephen Weeks MLton-user@mlton.org
Thu, 3 Nov 2005 15:54:58 -0800


> Applying pstack to the core generated, or calling mlton of the
> applications by truss says that the failure occurs very early, in
> the initialization phase of mlton.

I found the same thing.

> I suspect a problem when linking dynamic libraries. It looks like
> the mlton heap or some other mlton area is overwritten by the
> dynamically linked libraries (or the converse ...).

With some print statements, I found that the error occurs before the
MLton heap is allocated.  I was then able to whittle things down to
the following C program.

----------------------------------------------------------------------
#include <sys/resource.h>

int main () {
  uint    result;
  struct rusage   ru;

  getrusage (RUSAGE_SELF, &ru);
  result = 1000 * ru.ru_utime.tv_sec;
  return 0;
}
----------------------------------------------------------------------

This program, when compiled with "gcc -o z z.c", runs fine.  However,
when compiled with "gcc -fcall-used-g7 -o z z.c", the program
segfaults, and pstack shows:

core 'core' of 15829:   z
 7fb3ac20 _ti_bind_guard (0, 0, 0, 7fbec964, 29dc0, 0)
 7fbcad8c elf_bndr (7fbeedb4, 3c, 10510, 0, 7fbee67c, 0) + 28
 7fbb378c elf_rtbndr (10510, 0, 0, 7fba2000, 4, 0) + 10
 00020778 ???????? (0, ffbffaac, ffbffab4, 20908, 7fba00c0, 7fba0100)
 00010510 _start   (0, 0, 0, 0, 0, 0) + 64

which is the same error that Bernard saw.

So, I recompiled the runtime and a simple hello-world.sml, dropping
the -fcall-used-g[57] options.  Everything then worked perfectly.

Bernard, please try this out on your apps and let us know if it works
for you too.