[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.