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

Tue Apr 21 23:50:34 WEST 2009

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
======================================================================