View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000302 | LDMud 3.5 | Runtime | public | 2004-11-27 01:04 | 2018-01-30 04:59 |
| Reporter | Assigned To | zesstra | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
| Summary | 0000302: Memory usage as runtime limit | ||||
| Description | ort: Memory usage as runtime limit From: Menaures Date: 2002-09-16 Type: Feature State: New -- Since not all memory use is under control of the wizard (loading objects, swapping, activities by called objecs), this is tricky. It would be necessary to experiment first to see if we can actually track the memory usage, and maybe store it on a uid/object basis (like the eval costs). Wäre es möglich, eine Speichergrenze einzuführen? Ich stelle mir das ähnlich vor wie die Evalgrenze. Man darf während einer Ausführung nur eine bestimmte Anzahl Bytes belegen. Hintergrund: Bisher ist es möglich, mit den simpelsten Einzeilern in kürzester Zeit den gesamten MUD-Speicher vollzumüllen. Besonders ärgerlich wird das, wenn es aus Versehen passiert, z.B. das Abbruchkriterium einer Schleife fehlt und man addiert fröhlich strings solange, bis der Speicher voll ist (und hält dafür nebenbei das MUD für 15 Minuten an, bis es sich danach verabschiedet). Mit einer Speichergrenze von bleistiftsweise 4 Megabytes (oder ähnlich hohe Zahl, die nie jemand braucht), würde bei erreichen dieses Limits ein RTE geworfen werden, ähnlich einer Too Long Evaluation. Damit könnten solche Fälle wenigstens nicht mehr 'aus Versehen' eintreten. | ||||
| Tags | No tags attached. | ||||
|
|
Uh, seems to me quite complex and/or costly and probably also in parts undeterministic for wizards (e.g. might a string consume quite different amounts of memory depending it whether it is already a shared string). That will make it difficult to safe-guard critical code against abortions in the wrong moment. At least, without introducing transactions as well... |
|
|
As Lars already pointed out, a memory limit per execution thread might be very unpredictable. Therefore such a limit must be very broad, but that might be feasible. A limit per uid is expensive to track (each mapping, array, string must then store their list of uids they belong to, which must be updated on each assignment). So I'd rather not do that. |
|
|
I agree. The part with the max consumption per execution thread might be done by monitoring the difference in allocated memory between execution start and now for allocators which support it. It is crude, but if the limit should be very broad... |
|
|
The current suggestion then would be: simply monitor the difference between currently allocated memory and allocated memory at execution start and abort if that exceeds a certain value? Or should be just abandon the idea? |
|
|
I like the idea and it seems simple enough. |
|
|
Fix committed in revision 2540c460af23372b707a59b779e59b11faa60bde to master branch (see changeset 764 for details). Thank you for reporting! |
|
|
Fix committed in revision 2540c460af23372b707a59b779e59b11faa60bde to master branch (see changeset 1585 for details). Thank you for reporting! |
|
|
Fix committed in revision 2540c460af23372b707a59b779e59b11faa60bde to master branch (see changeset 2916 for details). Thank you for reporting! |
|
|
Fix committed in revision 2540c460af23372b707a59b779e59b11faa60bde to master branch (see changeset 3998 for details). Thank you for reporting! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-27 01:04 |
|
New Issue | |
| 2009-09-26 17:52 | zesstra | Note Added: 0001294 | |
| 2009-09-29 05:31 | Gnomi | Note Added: 0001329 | |
| 2009-10-05 18:55 | zesstra | Project | LDMud => LDMud 3.5 |
| 2009-10-05 18:59 | zesstra | Note Added: 0001480 | |
| 2011-02-14 17:24 | zesstra | Note Added: 0001984 | |
| 2011-02-14 17:24 | zesstra | Status | new => feedback |
| 2011-02-14 18:02 | zesstra | Target Version | => 3.5.0 |
| 2011-02-14 18:29 | Gnomi | Note Added: 0001989 | |
| 2011-02-15 00:55 | zesstra | Assigned To | => zesstra |
| 2011-02-15 00:55 | zesstra | Status | feedback => assigned |
| 2011-02-16 00:17 | zesstra | Source_changeset_attached | => ldmud.git master 2540c460 |
| 2011-02-16 00:17 | zesstra | Note Added: 0001995 | |
| 2011-02-16 00:17 | zesstra | Status | assigned => resolved |
| 2011-02-16 00:17 | zesstra | Resolution | open => fixed |
| 2017-10-04 20:56 | zesstra | Product Version | 3.2.10 => |
| 2017-10-04 20:56 | zesstra | Fixed in Version | => 3.5.0 |
| 2018-01-29 19:59 | zesstra | Source_changeset_attached | => ldmud.git master 2540c460 |
| 2018-01-29 19:59 | zesstra | Note Added: 0002332 | |
| 2018-01-29 22:57 | zesstra | Source_changeset_attached | => ldmud.git master 2540c460 |
| 2018-01-29 22:57 | zesstra | Note Added: 0002383 | |
| 2018-01-30 04:59 | zesstra | Source_changeset_attached | => ldmud.git master 2540c460 |
| 2018-01-30 04:59 | zesstra | Note Added: 0002434 |
