yade-users team mailing list archive

[Luc Sibille <luc.sibille@xxxxxxxxxxxxxx>]

Hi Nejib thank you for your reply.

I don't make any modification of the xml. I just run a simulation, stop 
it and save the xml file. Then reload the xml file and it is there that 
Yade can't iterate with this reloaded xml file. I checked the xml file, 
it is complete with the good lines at the end, at the beginning and so 
on. Of course the xml is quite big: about 250 MB but it should not be a 
problem. I verified this problem on several computers with different 
configurations (Ubuntu, fedora ...) and I get it each time.

There are several things like that quite strange when you save and 
reload a xml file. As long as you don't reload a xml file the simulation 
works fine. But when you reload a xml file, you can have as I explained 
memory problems, or previous contact normal with one of the component 
being nan whereas none of the current contact normal has a nan ...

Luc

Nejib Hadda a écrit :
> 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:~$

--
Luc Sibille

Université de Nantes - Laboratoire GeM UMR CNRS

IUT de Saint Nazaire
58, rue Michel-Ange - BP 420
44606 Saint-Nazaire Cedex, France

Tel: +33 (0)2 40 17 81 78