yade-users team mailing list archive

[Nejib Hadda <nejib.hadda@xxxxxxxxxxx>]

Hi Luc,

I think you have a memory problem when loading the xml file, I don't
know why yade developpers changed the craft in the xml file so that evry
almost evry word takes one line. At first (when generating) your file
can be loaded, but since interactions take place the xml file will
increase in lines and system can not load it easily anymore.

Another thing is that may be you made change on the xml file, but you
did not wait untill it is fully loaded, then you saved a corrupted file,
but I think it's not the because yade will crash.

May be you can try something, launch YADE and then Go to the system
monitor (equivalent to task manager on windows), click on the processus
tab, and then right clik on yade and click on change priority, take a
small value (hight priority), and click ok.

load your file, once loaded, before running reset the priority to normal
and then run your simulation.

Hope this would be helpful !


Le jeudi 25 novembre 2010 à 18:52 +0100, Luc Sibille a écrit :
> Hi everyone,
> 
> After some Yade iterations (more than about 600 000) I save a xml. Then 
> when I reload this xml all is fine, but when I run the simulation, Yade 
> is not able to iterates: the ram memory used increases until having the 
> following message:
> 
> Yade [1]: O.load('on_va_voir.xml')
> Yade [2]: O.run()
> Yade [3]: 117953 FATAL yade.ThreadRunner 
> /home/luc/Sim_DEM2/YADE_lbm/yade-0.50-lbm-dev_mainrepo/core/ThreadRunner.cpp:31 
> run: Exception occured:
> std::bad_alloc
> 
> 
> I use Yade 0.50, I tried to run Yade throught Valgrind and here is the 
> result below. Have you got an idea where to look for to solve this problem?
> 
> Thank you in advance,
> 
> Luc
> 
> 
> Yade [6]: O.run()
> Yade [7]: **8588** new/new[] failed and should throw an exception, but 
> Valgrind
> ==8588==    at 0x402513F: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4214)
> ==8588==    by 0x40256CC: operator new(unsigned int) 
> (vg_replace_malloc.c:255)
> ==8588==    by 0xC4F9325: 
> boost::shared_ptr<Interaction>::shared_ptr<Interaction>(Interaction*) 
> (shared_count.hpp:87)
> ==8588==    by 0xC4D7B20: 
> InsertionSortCollider::handleBoundInversion(int, int, 
> InteractionContainer*, Scene*) (InsertionSortCollider.cpp:45)
> ==8588==    by 0xC4DD9B8: InsertionSortCollider::action() 
> (InsertionSortCollider.cpp:282)
> ==8588==    by 0x5E93276: Scene::moveToNextTimeStep() (Scene.cpp:87)
> ==8588==    by 0x5E958D6: SimulationFlow::singleAction() 
> (SimulationFlow.cpp:18)
> ==8588==    by 0x5E8ABCB: ThreadWorker::callSingleAction() 
> (ThreadWorker.cpp:71)
> ==8588==    by 0x5E8E2DC: ThreadRunner::call() (ThreadRunner.cpp:53)
> ==8588==    by 0x5E92FB5: ThreadRunner::run() (ThreadRunner.cpp:27)
> ==8588==    by 0x5E9C41C: 
> boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, 
> boost::_mfi::mf0<void, ThreadRunner>, 
> boost::_bi::list1<boost::_bi::value<ThreadRunner*> > >, 
> void>::invoke(boost::detail::function::function_buffer&) 
> (mem_fn_template.hpp:49)
> ==8588==    by 0x5EEAD65: 
> boost::detail::thread_data<boost::function0<void> >::run() 
> (function_template.hpp:1013)
> **8588**    cannot throw exceptions and so is aborting instead.  Sorry.
> ==8588==    at 0x402513F: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4214)
> ==8588==    by 0x40256DA: operator new(unsigned int) 
> (vg_replace_malloc.c:255)
> ==8588==    by 0xC4F9325: 
> boost::shared_ptr<Interaction>::shared_ptr<Interaction>(Interaction*) 
> (shared_count.hpp:87)
> ==8588==    by 0xC4D7B20: 
> InsertionSortCollider::handleBoundInversion(int, int, 
> InteractionContainer*, Scene*) (InsertionSortCollider.cpp:45)
> ==8588==    by 0xC4DD9B8: InsertionSortCollider::action() 
> (InsertionSortCollider.cpp:282)
> ==8588==    by 0x5E93276: Scene::moveToNextTimeStep() (Scene.cpp:87)
> ==8588==    by 0x5E958D6: SimulationFlow::singleAction() 
> (SimulationFlow.cpp:18)
> ==8588==    by 0x5E8ABCB: ThreadWorker::callSingleAction() 
> (ThreadWorker.cpp:71)
> ==8588==    by 0x5E8E2DC: ThreadRunner::call() (ThreadRunner.cpp:53)
> ==8588==    by 0x5E92FB5: ThreadRunner::run() (ThreadRunner.cpp:27)
> ==8588==    by 0x5E9C41C: 
> boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, 
> boost::_mfi::mf0<void, ThreadRunner>, 
> boost::_bi::list1<boost::_bi::value<ThreadRunner*> > >, 
> void>::invoke(boost::detail::function::function_buffer&) 
> (mem_fn_template.hpp:49)
> ==8588==    by 0x5EEAD65: 
> boost::detail::thread_data<boost::function0<void> >::run() 
> (function_template.hpp:1013)
> ==8588==
> ==8588== HEAP SUMMARY:
> ==8588==     in use at exit: 761,091,121 bytes in 14,178,786 blocks
> ==8588==   total heap usage: 139,013,366 allocs, 124,834,577 frees, 
> 5,365,970,720 bytes allocated
> ==8588==
> ==8588==
> ==8588==     Valgrind's memory management: out of memory:
> ==8588==        newSuperblock's request for 56717312 bytes failed.
> ==8588==        2883981312 bytes have already been allocated.
> ==8588==     Valgrind cannot continue.  Sorry.
> ==8588==
> ==8588==     There are several possible reasons for this.
> ==8588==     - You have some kind of memory limit in place.  Look at the
> ==8588==       output of 'ulimit -a'.  Is there a limit on the size of
> ==8588==       virtual memory or address space?
> ==8588==     - You have run out of swap space.
> ==8588==     - Valgrind has a bug.  If you think this is the case or you are
> ==8588==     not sure, please let us know and we'll try to fix it.
> ==8588==     Please note that programs can take substantially more 
> memory than
> ==8588==     normal when running under Valgrind tools, eg. up to twice or
> ==8588==     more, depending on the tool.  On a 64-bit machine, Valgrind
> ==8588==     should be able to make use of up 32GB memory.  On a 32-bit
> ==8588==     machine, Valgrind should be able to use all the memory 
> available
> ==8588==     to a single process, up to 4GB if that's how you have your
> ==8588==     kernel configured.  Most 32-bit Linux setups allow a maximum of
> ==8588==     3GB per process.
> ==8588==
> ==8588==     Whatever the reason, Valgrind cannot continue.  Sorry.
> luc@pc-calc-luc2:~$
> 
>