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
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
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
Philip Clayton wrote:
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.
Phil, The start-up banner for Poly/ML only shows the compiler version, not the RTS version. If you want to find the full version as well as the RTS version simply type "poly -v" $ poly -v Poly/ML 5.2 Release RTS version: I386-5.2.1
David
-
David.Matthews＠prolingua.co.uk -
pclayton＠taz.qinetiq.com