[Octopus-devel] [Octopus-notify] svn commit: r5294 - trunk/src/states by xavier (fwd)

Wed Apr 22 00:05:42 WEST 2009

ok I'll propagate to modelmb_null, that should do it. Cheers Al

Matthieu

On Wed, Apr 22, 2009 at 12:50 AM,  <alberto.castro at tddft.org> wrote:
>
> But I thought that you had solved it in #5304 and #5305 (at least I
> stopped having the segfaults after those two changes). And then Xavier
> also said that the problem disappeared with #5306 (eliminating the "=>
> NULL"). However you still get the problem in your machine? In my
> machine the run does not crash.
>
> If the problem really persists somewhere after #5306, it probably is,
> I think, that the call to states_null(hm%st) in hamiltonian_init does
> not nullify everything in hm%st, because states_null does not do its
> job properly (all the pointers in st should be nullified, and also
> recursively all the pointers in its derived data types by
> corresponding whatever_null subroutines).
>
> As I said in a previous mail, by setting consistently "=> NULL()" in
> all the pointers in hamiltonian_t, states_t, and in all the derived
> data types included in those (such as modelmb_particle_t), I don't get
> any segfault, such things as "states_null" is not needed, and the
> program runs gracefully. But it seems that some compilers/machines
> have problems with this feature.
>
> Cheers, Alberto.
>
>
>
> On Tue, 21 Apr 2009, matthieu verstraete wrote:
>
>> Ok - I'm pissed off. No solution but I can explain what is happening
>> to produce my segfault:
>>
>> the hm%st is not being initialized (in some cases at least) neither
>> through the states_init nor states_copy, and as a result the
>> hm%st%modelmb_particles is not initialized, and ends up associated
>> randomly (really randomly), which of course crashes when you try to
>> destroy it all.
>>
>> I don't know how this hm%st comes about (it should not! this should be
>> impossible), and I have spent hours looking at the octopus workflow,
>> and I cannot find a thing. For the GS of the first test the sys%st
>> instance is always fine, initialized correctly. Then after the unocc
>> run on 01H everything in hm%st is deallocated in hamiltonian_end ->
>> states_end -> modelmbstuff_end which crashes.
>>
>> Can _anyone_ get to the bottom of this "£$£$&$%&* thing?
>>
>> Matthieu
>>
>> On Tue, Apr 21, 2009 at 10:18 PM, Micael Oliveira <micael at teor.fis.uc.pt>
>> wrote:
>>>
>>> Hi Alberto,
>>>
>>>  I tried to reproduce the problem I encountered some years ago with the
>>> NULL() initializer and it seems the problem has been solved (at least
>>> with the compilers I tried). So, unless Xavier knows some specific
>>> problems that could put us in trouble, I would say using this feature
>>> could be a good idea.
>>>
>>>  The alternative is to have routines to "nullify" all the derived data
>>> types and make sure you call those routines whenever you declare one
>>> such derived data type. This is obviously more cumbersome and error
>>> prone...
>>>
>>>  Cheers,
>>>
>>> Micael
>>>
>>> alberto.castro at tddft.org wrote:
>>>>
>>>> I also get the segfault. I think it is the usual problem of attempting
>>>> to query the status of a pointer that has never been nullified,
>>>> associated or allocated. If I put the pointer components of
>>>> modelmb_particle_t with the "=> NULL()" default initialization, the
>>>> segfault disappears. But, as we discussed a couple of days ago, what
>>>> should we do about this "=> NULL()" business: should we keep them at a
>>>> minimum, or we try them and see if they create trouble?
>>>>
>>>> On Mon, 20 Apr 2009, octopus-notify at tddft.org wrote:
>>>>
>>>>>      Author: xavier
>>>>>        Date: Mon Apr 20 23:34:04 2009
>>>>> New Revision: 5294
>>>>>   Changeset: http://www.tddft.org/trac/octopus/changeset/5294
>>>>>
>>>>> Modified:
>>>>>   trunk/src/states/states.F90
>>>>>
>>>>> Log:
>>>>> The call to modelmb_particles_end causes a segmentation fault, I don't
>>>>> know how to fix it so I commented the line.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Octopus-notify mailing list
>>>>> Octopus-notify at tddft.org
>>>>> http://www.tddft.org/mailman/listinfo/octopus-notify
>>>>>
>>>> _______________________________________________
>>>> Octopus-devel mailing list
>>>> Octopus-devel at tddft.org
>>>> http://www.tddft.org/mailman/listinfo/octopus-devel
>>>>
>>>
>>> _______________________________________________
>>> Octopus-devel mailing list
>>> Octopus-devel at tddft.org
>>> http://www.tddft.org/mailman/listinfo/octopus-devel
>>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dr. Matthieu Verstraete
>>
>> European Theoretical Spectroscopy Facility (ETSF)
>> Dpto. Fisica de Materiales,
>> U. del Pais Vasco,
>> Centro Joxe Mari Korta, Av. de Tolosa, 72,   Phone: +34-943018393
>> E-20018 Donostia-San Sebastian, Spain        Fax  : +34-943018390
>>
>> Mail : matthieu.jean.verstraete at gmail.com
>> http://www-users.york.ac.uk/~mjv500
>>
>> _______________________________________________
>> Octopus-devel mailing list
>> Octopus-devel at tddft.org
>> http://www.tddft.org/mailman/listinfo/octopus-devel
>>
>
> ======================================================================
> Dr. Alberto Castro
>
> Institut fur Theoretisch Physik, Freie Universitat Berlin.
> Arnimallee, 14, Berlin 14195 (Deutschland)
>
> Tel:   +49 30 83853028
> Fax:   +49 30 83855258
> skype: alberto_c_barrigon
> email: alberto at physik.fu-berlin.de
> ======================================================================

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Matthieu Verstraete

European Theoretical Spectroscopy Facility (ETSF)
Dpto. Fisica de Materiales,
U. del Pais Vasco,
Centro Joxe Mari Korta, Av. de Tolosa, 72,   Phone: +34-943018393
E-20018 Donostia-San Sebastian, Spain        Fax  : +34-943018390

Mail : matthieu.jean.verstraete at gmail.com
http://www-users.york.ac.uk/~mjv500