This issue tracker is closed. Please visit UPPAAL issue tracker at Github instead.

Bug 398 - Memory leak when generating shortest or fastest traces
Summary: Memory leak when generating shortest or fastest traces
Alias: None
Product: UPPAAL
Classification: Unclassified
Component: Engine (show other bugs)
Version: 4.0.5
Hardware: All All
: P2 major
Assignee: Gerd Behrmann
Depends on:
Reported: 2007-02-27 15:19 CET by Egon Pedersen
Modified: 2007-05-13 18:09 CEST (History)
0 users

See Also:

The model (6.10 KB, text/xml)
2007-02-28 10:23 CET, Egon Pedersen
The query (96 bytes, application/octet-stream)
2007-02-28 10:23 CET, Egon Pedersen
The model (6.10 KB, text/xml)
2007-02-28 10:35 CET, Egon Pedersen

Note You need to log in before you can comment on or make changes to this bug.
Description Egon Pedersen 2007-02-27 15:19:33 CET
When running a uppaal server on, the memory does not get flushed when a certain property is satisfied.  In my model which currently uses about 25%  of the memory to complete a property, will when i check another property start with using 25% memory. However this does not happen if the connection to the server is lost, then it will start from 0% memory.
Comment 1 Gerd Behrmann 2007-02-28 07:57:44 CET
Without a model, the queries and instructions on how to reproduce the problem, there is not much we can do to resolve the problem... Please attach the missing files.
Comment 2 Egon Pedersen 2007-02-28 10:23:32 CET
Created attachment 147 [details]
The model
Comment 3 Egon Pedersen 2007-02-28 10:23:56 CET
Created attachment 148 [details]
The query
Comment 4 Egon Pedersen 2007-02-28 10:26:04 CET
Its best to use DFS and shortest in diagnostic trace to reproduce the problem, as it will use a lot of memmory then.
Comment 5 Egon Pedersen 2007-02-28 10:35:10 CET
Created attachment 149 [details]
The model

new version
Comment 6 Gerd Behrmann 2007-02-28 16:22:38 CET
Do you also see this behavior when the reuse option is turned off?
Comment 7 Gerd Behrmann 2007-02-28 21:46:08 CET
The problem is not related to checking multiple properties. It is in fact a memory leak in the pruning logic used when optimizing trace length.
Comment 8 Gerd Behrmann 2007-02-28 21:56:35 CET
Fixed on the 4.0 branch from rev. 2981.