Hi, Thank you so much for quickly responding to the bug. So should I reinstall SUMO or should I download the git repo and build it from there. I am working on both windows and linux systems.
On Wed, Apr 7, 2021 at 2:44 AM Jakob Erdmann <[email protected]> wrote: > Thank you for the excellent analysis. With the latest fix, valgrind > log-size stays constant when varying the number of loadState-calls. > > Am Mi., 7. Apr. 2021 um 09:09 Uhr schrieb Harald Schaefer < > [email protected]>: > >> Hi, >> >> here is the github issue https://github.com/eclipse/sumo/issues/8450 >> >> for this problem >> Am 31.03.21 um 19:50 schrieb . Abdullah: >> >> Thank you. So is there a possibility of it getting fixed in the next >> update? >> >> On Wed, Mar 31, 2021 at 1:12 AM Harald Schaefer <[email protected]> >> wrote: >> >>> This bug should be handled by the SUMO developers >>> Am 30.03.21 um 23:02 schrieb . Abdullah: >>> >>> Hi Harald, >>> >>> Thank you for pointing that out. But how would I fix it, since the >>> xml-files are created and read by sumo. >>> >>> On Tue, Mar 30, 2021 at 2:09 PM Harald Schaefer <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> there seems to be memory leaks in the context of reading of xml-files. >>>> >>>> I have run the scenario twice with a simulation time of 5 resp. 10 >>>> seconds: >>>> >>>> The output of valgrind (a memory checker under linux) shows an >>>> increasing number of lost bytes: >>>> >>>> valgrind28244.log (5 sceonds) >>>> ==28244== LEAK SUMMARY: >>>> ==28244== definitely lost: 19,592 bytes in 202 blocks >>>> ==28244== indirectly lost: 161,667 bytes in 1,437 blocks >>>> ==28244== possibly lost: 0 bytes in 0 blocks >>>> ==28244== still reachable: 48 bytes in 1 blocks >>>> ==28244== suppressed: 0 bytes in 0 blocks >>>> ==28244== Reachable blocks (those to which a pointer was found) are not >>>> shown. >>>> ==28244== To see them, rerun with: --leak-check=full >>>> --show-leak-kinds=all >>>> ==28244== >>>> ==28244== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0) >>>> >>>> valgrind28615.log (10 seconds) >>>> ==28615== LEAK SUMMARY: >>>> ==28615== definitely lost: 38,792 bytes in 402 blocks >>>> ==28615== indirectly lost: 257,667 bytes in 2,437 blocks >>>> ==28615== possibly lost: 0 bytes in 0 blocks >>>> ==28615== still reachable: 48 bytes in 1 blocks >>>> ==28615== suppressed: 0 bytes in 0 blocks >>>> ==28615== Reachable blocks (those to which a pointer was found) are not >>>> shown. >>>> ==28615== To see them, rerun with: --leak-check=full >>>> --show-leak-kinds=all >>>> ==28615== >>>> ==28615== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0) >>>> >>>> Attached is the modified py script and the output of valgrind for the >>>> last run >>>> >>>> Greetings, Harald >>>> >>>> >>>> Am 30.03.21 um 19:55 schrieb . Abdullah: >>>> >>>> Hi, >>>> >>>> I have attached both the .py and .txt files below. >>>> >>>> On Tue, Mar 30, 2021 at 4:50 AM <[email protected]> wrote: >>>> >>>>> Hi Abdullah, >>>>> >>>>> >>>>> >>>>> I cannot see your .py file. Would you please send it as a .txt file? >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Giuliana >>>>> >>>>> >>>>> >>>>> *Von:* sumo-user <[email protected]> *Im Auftrag von *. >>>>> Abdullah >>>>> *Gesendet:* Montag, 29. März 2021 16:50 >>>>> *An:* Sumo project User discussions <[email protected]> >>>>> *Betreff:* [sumo-user] Using traci.simulation.loadState increases >>>>> memory usage >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I have noticed that if I use traci.simulation.loadState multiple times >>>>> then my memory usage increases significantly. I have attached a simple >>>>> code >>>>> below, where cars are being added to the network and after every 5 >>>>> seconds, >>>>> a state is being saved and loaded back up. If I do this multiple times, it >>>>> increases my memory usage. You can try the same code again by commenting >>>>> out line 47 and it will drastically reduce the memory usage. Is there >>>>> something I am doing wrong and is there a way around this? >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thank you. >>>>> >>>>> Abdullah >>>>> _______________________________________________ >>>>> sumo-user mailing list >>>>> [email protected] >>>>> To unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/sumo-user >>>>> >>>> >>>> >>>> -- >>>> Thank you. >>>> Abdullah >>>> >>>> _______________________________________________ >>>> sumo-user mailing [email protected] >>>> To unsubscribe from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/sumo-user >>>> >>>> _______________________________________________ >>>> sumo-user mailing list >>>> [email protected] >>>> To unsubscribe from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/sumo-user >>>> >>> >>> >>> -- >>> Thank you. >>> Abdullah >>> >>> _______________________________________________ >>> sumo-user mailing [email protected] >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/sumo-user >>> >>> _______________________________________________ >>> sumo-user mailing list >>> [email protected] >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/sumo-user >>> >> >> >> -- >> Thank you. >> Abdullah >> >> _______________________________________________ >> sumo-user mailing [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user >> >> _______________________________________________ >> sumo-user mailing list >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user >> > _______________________________________________ > sumo-user mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > -- Thank you. Abdullah
_______________________________________________ sumo-user mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
