ediloren
commented
6 years ago Thank you Matthew for the issue report.
I'm not sure we can replicate the issue. If this is systematic, would you mind running a modified code on your side to catch the error? (I'm assuming you are not compiling and debugging - otherwise this would be the preferred way)
Is there any additional information if you run FasterCap in verbose mode (-v)?
Best Regards, Enrico
Enrico Di Lorenzo General Manager Phone: +39.349.6114040 Skype: enrico.dilorenzo.nounderscore mailto: Enrico.Di_Lorenzo@fastfieldsolvers.com FastFieldSolvers S.R.L. Via de Castillia, 7 - 20871 Vimercate (MB) Italy Numero REA / REA number: MB - 1885192 P.IVA/VAT No. IT 07931440965 http://www.fastfieldsolvers.com
From: "Matthew Clapp" notifications@github.com To: "ediloren/FasterCap" FasterCap@noreply.github.com Cc: "Subscribed" subscribed@noreply.github.com Date: Fri, 06 Apr 2018 19:54:58 +0000 (UTC) Subject: [ediloren/FasterCap] FasterCap gets bogus free memory in console mode, stops early (#2)
Centos 7, system with
FasterCap v6.0.0 In console mode (-b), it appears that there is a problem in
Solver/Autorefine.cpp
That causes it to not catch the fact that wxGetFreeMemory(); has returned a -1. Perhaps there is some error in casting the value to wxLongLong or Long? It always works fine on the same input files when run in GUI mode, and always fails with the same memory error in console mode. Here is the output from console mode when it stops early on a very simple model:
Computing the links..
Number of panels after refinement: 529
Number of links to be computed: 18126
Estimated memory required for storing panel interaction links is: 0 Mbytes
Available free memory left is: 18446743936487993968 Mbytes
Estimated links memory is more than 20% of the available free memory. Going out-of-core.
Out-of-core temporary files folder: '/tmp'
Done computing links
Total allocated memory: 252 kilobytes
Total time: 0.335048s (0 days, 0 hours, 0 mins, 0 s) Error: Out of memory, program execution stopped!
As close as I can tell, 18446743936487993968 is all 1's in unsigned binary. (i.e. -1 in signed binary) And here I show I have plenty of memory:
fs02:mqws$ free -m
total used free shared buff/cache available
Mem: 128529 3076 56253 66 69198 124331
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
itsayellow
Centos 7, system with FasterCap v6.0.0
In console mode (-b), it appears that there is a problem in Solver/Autorefine.cpp That causes it to not catch the fact that wxGetFreeMemory(); has returned a -1. Perhaps there is some error in casting the value to wxLongLong or Long?
It always works fine on the same input files when run in GUI mode, and always fails with the same memory error in console mode.
Here is the output from console mode when it stops early on a very simple model:
As close as I can tell, 18446743936487993968 is all 1's in unsigned binary. (i.e. -1 in signed binary)
And here I show I have plenty of memory: fs02:mqws$ free -m total used free shared buff/cache available Mem: 128529 3076 56253 66 69198 124331