James,
It's Wheezy (old stable?) with gcc version 4.6.
I've just been running Poly/ML under the debugger and I've found
something that might account for the crashes. I need to look more
closely at this.
Regards,
David
On 18/01/2016 19:34, James Clarke wrote:
Hi David,
Is this on Debian Jessie (current stable)? I've been doing all my work on Sid
(new package versions are always built on unstable unless they are backports),
which has GCC 5 (I believe it built fine under GCC 4.x, though I never ran the
test suite); I had forgotten to mention this important fact, sorry about that!
As this is for the Debian package, it's using their default compiler flags,
although I think it breaks with either. Thanks for taking time to look at this
though; I will continue to experiment as well.
Regards,
James
On 18 Jan 2016, at 18:54, David Matthews <[email protected]> wrote:
James,
I've managed to set up a big-endian mips debian virtual machine using qemu
inside a virtual debian machine in virtualbox on Windows. Despite all the
layers of virtualisation it works and more importantly Poly/ML actually builds
successfully. It does crash with some larger examples, such as
Tests/Succeed/Test133.ML, and I've seen some other crashes in the
garbage-collector. I suspect that there is a problem with endian-ness
somewhere but it may be possible to narrow this down with gdb.
Regards,
David
On 16/01/2016 17:01, James Clarke wrote:
Hi David,
I just tried building on mipsel, and that compiles and passes the test suite
with the same compiler flags. Endianness is looking like a strong candidate,
given that the only architectures it fails on are big-endian, although compiler
optimisations are “responsible”. I shall see if a very old version works on
big-endian mips; if so, I will try and do a git bisect, otherwise it might have
to be some painful debugging.
Regards,
James
On 15 Jan 2016, at 11:59, James Clarke <[email protected]> wrote:
They are all big-endian. I haven't tried mipsel; that could help narrow it
down. One thing making me not so sure it's an endianness issue is that you
support 32-bit PowerPC, and that runs properly. Also the mips builds are broken
by GCC's optimisations; adding -fno-omit-frame-pointer made it work for some
reason, if I remember correctly.
James
On 15 Jan 2016, at 11:29, David Matthews <[email protected]> wrote:
I wish I could help but there's not much I can suggest. The only idea that
occurs to me is that there is some endian-ness issue that has crept in. Are
these little-endian or big-endian? In theory the interpreter should work on
both big-endian and little-endian but I've only tested the most recent version
on X86. Have a look at an earlier version of Poly/ML and see if you have any
more success with that.
David
On 12/01/2016 14:52, James Clarke wrote:
Hi,
I’ve been trying to port Poly/ML to mips and IBM’s S/390 (the 64-bit version, often
referred to as s390x). For both, I tried just adding an extra case in configure.ac, along
with corresponding HOSTARCHITECTURE macros and cases in libpolyml/elfexport.cpp. However,
these all seem to segfault when polyimport is run when building (both with 5.5.2 and git
commit ee26375, "Merge branch ‘PICTest’"). I can’t seem to get a meaningful
stack trace out of the mips segfault, but it crashes just after “Use: basis/Socket.sml”
is printed. However, on s390x, it crashes before anything is printed, and valgrind gave
me the following (with no errors before this point) when running ee26375’s polyimport:
==16138== Thread 3:
==16138== Invalid read of size 8
==16138== at 0x489EA50: Offset (globals.h:315)
==16138== by 0x489EA50: GetConstSegmentForCode (globals.h:344)
==16138== by 0x489EA50: GetConstSegmentForCode (globals.h:350)
==16138== by 0x489EA50: ConstPtrForCode (globals.h:355)
==16138== by 0x489EA50: buildStackList(TaskData*, PolyWord*, PolyWord*)
(run_time.cpp:413)
==16138== by 0x489EC87: exceptionToTraceException(TaskData*, SaveVecEntry*)
(run_time.cpp:471)
==16138== by 0x48AC9ED: IntTaskData::SwitchToPoly() (interpret.cpp:877)
==16138== by 0x48ACC33: IntTaskData::EnterPolyCode() (interpret.cpp:1428)
==16138== by 0x489324D: NewThreadFunction(void*) (processes.cpp:1128)
==16138== by 0x48E591D: start_thread (pthread_create.c:335)
==16138== by 0x4C8CEA9: ??? (in /lib/s390x-linux-gnu/libc-2.21.so)
==16138== Address 0xe000000005ab5b38 is not stack'd, malloc'd or (recently)
free'd
==16138==
==16138==
==16138== Process terminating with default action of signal 11 (SIGSEGV)
==16138== Access not within mapped region at address 0xE000000005AB5000
==16138== at 0x489EA50: Offset (globals.h:315)
==16138== by 0x489EA50: GetConstSegmentForCode (globals.h:344)
==16138== by 0x489EA50: GetConstSegmentForCode (globals.h:350)
==16138== by 0x489EA50: ConstPtrForCode (globals.h:355)
==16138== by 0x489EA50: buildStackList(TaskData*, PolyWord*, PolyWord*)
(run_time.cpp:413)
==16138== by 0x489EC87: exceptionToTraceException(TaskData*, SaveVecEntry*)
(run_time.cpp:471)
==16138== by 0x48AC9ED: IntTaskData::SwitchToPoly() (interpret.cpp:877)
==16138== by 0x48ACC33: IntTaskData::EnterPolyCode() (interpret.cpp:1428)
==16138== by 0x489324D: NewThreadFunction(void*) (processes.cpp:1128)
==16138== by 0x48E591D: start_thread (pthread_create.c:335)
==16138== by 0x4C8CEA9: ??? (in /lib/s390x-linux-gnu/libc-2.21.so)
==16138== If you believe this happened as a result of a stack
==16138== overflow in your program's main thread (unlikely but
==16138== possible), you can try to increase the size of the
==16138== main thread stack using the --main-stacksize= flag.
==16138== The main thread stack size used in this run was 8388608.
(the ??? for libc is because valgrind does not yet understand compressed debug
info; I removed a whole load of warnings to that effect)
Have you ever come across anything like this? Do you have any thoughts for
where to start with hunting this down?
Regards,
James Clarke
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
