David,
Sorry for the slightly belated response but I have now tried the latest
release and has fixed the problem.
I must say that when I was setting up the test running 5.2.1 and the
latest version side by side, I found it particularly difficult to know
what version of Poly/ML I was actually running! I currently work with
5.2, 5.2.1 and, now, the latest but all three report '5.2' on the
start-up banner and '520' from PolyML.rtsVersion. (Initially, I found
that the latest version was failing too but after some investigation,
realized that it was due to LD_LIBRARY_PATH being set inappropriately.)
We would certainly find it very useful if the initial banner provided
sufficient version information to determine what behaviour to expect.
Regards,
Phil
David Matthews wrote:
Phil,
I've now looked into this and hopefully fixed it in CVS.
saveState gets a new segment of memory from the system each time it is
called and copies everything that is reachable from the root into
that. As well being written out the segment needs to be retained as
a whole since if a child state is created the child relies on all the
contents of the parent being at a fixed location. If saveState is
called more than once a new segment is created and most, if not all,
of the existing segment is copied into it. It is possible, though,
that some data may not be copied over because it is only reachable
from the stacks of running threads. Rather than delete existing
segments they are turned into "local" heap segments. These local
segments are managed by the normal garbage collector and the GC may
deallocate and return them to the system pool if they are no longer
required. The solution to these "Out of Memory" exceptions is simply
to call FullGC between calls to saveState and that's what I've done.
The segfault was as a result of not handling cleanly the case of being
unable to allocate a new segment part-way through the state saving,
and I've fixed that.
Let me know if there are still problems.
Regards,
David
Philip Clayton wrote:
David,
We have noticed some interesting behaviour with the state saving in
Poly/ML 5.2/5.2.1--- possibly a sign that something isn't quite as
intended.
If poly is started and the command
PolyML.SaveState.saveState "test";
is repeatedly entered, a segmentation fault eventually occurs. On my
machine it always happens after 22 times. With the debug level set
to 2 or 3, we get:
Bad pointer 0x0d479050 found
Aborted
If we enter
PolyML.fullGC ();
just before the 22nd go, there is no segmentation fault. However,
continuing to enter the original save state command results in the
exception
Exception- SysErr ("Out of Memory", SOME ENOMEM) raised
after 8 more goes.
We found this example more by chance. We have had a few other
repeatable segmentation faults when saving the state but on very
large examples and these are hard to reduce down. (They may be
related to the above issue.) In each case, the segmentation fault
could be avoided by executing PolyML.fullGC first. Generally, if we
cannot create an SML script that generates an error, what is the best
way to track down an issue?
Thanks,
Phil
The information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s). The information in this communication may be
confidential and/or legally privileged. Nothing in this e-mail is
intended to conclude a contract on behalf of QinetiQ or make QinetiQ
subject to any other legally binding commitments, unless the e-mail
contains an express statement to the contrary or incorporates a formal Purchase Order.
For those other than the recipient any disclosure, copying,
distribution, or any action taken or omitted to be taken in reliance
on such information is prohibited and may be unlawful.
Emails and other electronic communication with QinetiQ may be
monitored and recorded for business purposes including security, audit
and archival purposes. Any response to this email indicates consent
to this.
Telephone calls to QinetiQ may be monitored or recorded for quality
control, security and other business purposes.
QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom
http://www.qinetiq.com/home/notices/legal.html
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
