Re: [ESPResSo-devel] Bond-deleting strangeness

[Axel Arnold]

Hi!

> On 08.01.2015, at 10:01, Rudolf Weeber <address@hidden> wrote:
> 
> Thanks guys. I wouldn't have figured that one out any time soon.

Well, didn’t take too long. I just put in printfs to see that the parameters 
were ok, then of course the problem is in the function. Well, and the manpage 
warns pretty directly about memcpy not being stable…

> Two points:
> 1. The same issue probably also affects exclusions, as they are also intlist 
> based.

Yes, it did, see my full patch. The simples thing would be to replace all 
memcpy by memmove, but there so many, and most really just copy from one 
segment to another. We also have only very few lists that actually can be 
shorted, so should be more or less ok now (crossing fingers). The particle 
lists are ok, because if I delete particles there, I just move particles from 
the end of the list into the gap, rather than shifting as in the bond list.

> 2. Might this be a reason for a bugfix release of the stable Espresso? As I 
> understand it, this issue will affect all existing users, who happen to use a 
> new enough linux distro?

There is actually a number of other bugfixes in the master that would be 
worthwhile to cherry-pick. Whoever maintainer jumps at it…

Cheers,
Axel

> On Wed, Jan 07, 2015 at 11:26:53PM +0100, Florian Weik wrote:
>> Actually simply switching to memmove does the trick... Now its even
>> standard conform, so it will never break again *cough*
>> 
>> On Wed, Jan 7, 2015 at 11:24 PM, Ulf Schiller <address@hidden> wrote:
>> 
>>> Maybe a bit dirty, but could playing around with something like
>>> 
>>> __asm__(".symver memcpy,...
>>> 
>>> do the trick?
>>> 
>>> On 01/07/2015 10:20 PM, Axel Arnold wrote:
>>>> Well, I was more polite about this change than Linus...
>>>> 
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129
>>>> 
>>>> But I do like his statement about standards :-). The other funny thing
>>>> is that he thinks they just forgot to handle overlapping in early memcpy
>>>> and therefore introduced memmove with guaranteed behavior. I just wrote
>>>> try_delete_bond in the golden window when both were the same...
>>>> 
>>>> Cheers,
>>>> Axel
>>>> 
>>>>> On 07.01.2015, at 23:10, Florian Weik <address@hidden
>>>>> <mailto:address@hidden>> wrote:
>>>>> 
>>>>> This is a joke, right?
>>>>> 
>>>>> On Wed, Jan 7, 2015 at 10:56 PM, Axel Arnold
>>>>> <address@hidden <mailto:address@hidden>>
>>>>> wrote:
>>>>> 
>>>>>   Hi!
>>>>> 
>>>>>   No, that problem is more subtle, and will probably stick around
>>>>>   for a while. glibc < 2.14 aliased memcpy to memmove, which allows
>>>>>   for overlapping memory regions, while memcpy doesn't. The current
>>>>>   glibc versions have a more efficient memcpy, that does not allow
>>>>>   for overlap, which in this case however occurs.
>>>>> 
>>>>>   I can’t test on my Mac, since Apple decided wisely that an
>>>>>   unmeasurable speed gain (according to Linus) isn’t worth breaking
>>>>>   hundreds of applications, but most Linux distros seem to have this
>>>>>   problem. Shooting yourself (or others) in the foot seems to be
>>>>>   great fun...
>>>>> 
>>>>>   Best,
>>>>>   Axel
>>>>> 
>>>>>>   On 07.01.2015, at 15:52, Florian Weik <address@hidden
>>>>>>   <mailto:address@hidden>> wrote:
>>>>>> 
>>>>>>   Hi,
>>>>>>   the function looks suspicious to me, might be an off by one
>>>>>>   error. I'll get back to you if I've got it figured out.
>>>>>> 
>>>>>>   Florian
>>>>>> 
>>>>>>   On Wed, Jan 7, 2015 at 3:45 PM, Rudolf Weeber
>>>>>>   <address@hidden
>>>>>>   <mailto:address@hidden>> wrote:
>>>>>> 
>>>>>>       Hi,
>>>>>>       On Wed, Jan 07, 2015 at 02:42:27PM +0100, Rudolf Weeber wrote:
>>>>>>> I encountered very strange behaviour when deleting
>>> individual bonds from particles which have more than one bond.
>>>>>>> In some cases, the code works correctly, in some cases, the
>>> wrong bond seems to be deleted and in some cases, the bond list gets
>>> screwed up completely.
>>>>>>> The code, which is supposed to delete the bond is in
>>> particle_data.cpp:try_delete_bond()
>>>>>>       And here is a case, where the bond list is screwed up entirely:
>>>>>> 
>>>>>> 
>>>>>>       {0 FENE 47.396 2.5 1.0} {1 angle_harmonic 473.96000000000004
>>>>>>       1.0471975512} {2 FENE 473960.0 2.0 1.0} {3 FENE 473960.0 0.1
>>>>>>       0.0} {1 1 lennard-jones 1000.0 2.672696154421018 3.0 0.25 0.0
>>>>>>       0.0 0.0 } {magnetic 1.0  dawaanr }
>>>>>>       I.e., bond 0 and 2 have one partner, bond 1 has two partners
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>       Initial bond configurations
>>>>>>       { {0 21746} {0 21747} {0 22047} {1 22047 21746} {1 22049
>>>>>>       21747} {1 22348 22047} {1 22349 22049} }
>>>>>>         Del: 0 21746
>>>>>>       { {0 21747} {0 22047} {1 22047 21746} {1 22049 21747} {22047
>>>>>>       1} {22047 1} {22349 22049} }
>>>>>> 
>>>>>>       ---------------------------------
>>>>>> 
>>>>>>       The relevant code is
>>>>>>       proc makeBondRigid { id bond} {
>>>>>>       global bondMeshPairSoft 0
>>>>>>       global bondMeshAngleSoft 1
>>>>>>       global bondMeshPairStiff 2
>>>>>>       global bondParticleMesh 3
>>>>>> 
>>>>>>        puts "$id: Making bond rigid: $bond"
>>>>>>        # First delete the old bond
>>>>>>        puts "[part $id print bond]"
>>>>>>        puts "  Del: $bond"
>>>>>>        eval "part $id bond delete $bond"
>>>>>>        puts "[part $id print bond]"
>>>>>> 
>>>>>>        # Make new bond with changed type
>>>>>>        lset bond 0 $bondMeshPairStiff
>>>>>>        # Add
>>>>>>        puts "  Add: $bond"
>>>>>>        eval "part $id bond $bond"
>>>>>>        puts "[part $id print bond]"
>>>>>>       }
>>>>>> 
>>>>>> 
>>>>>>       Regards, Rudolf
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>   --
>>>>>>   Florian Weik
>>>>>> 
>>>>>>   address@hidden <mailto:address@hidden>
>>>>>>   ++49 157 85939252 <tel:%2B%2B49%20157%2085939252>
>>>>>> 
>>>>> 
>>>>>   ------------------------------------------------
>>>>>   JP Dr. Axel Arnold
>>>>>   ICP, Universität Stuttgart
>>>>>   Allmandring 3
>>>>>   70569 Stuttgart, Germany
>>>>>   Email: address@hidden
>>>>>   <mailto:address@hidden>
>>>>>   Phone: +49 711 685 67609 <tel:%2B49%20711%20685%2067609>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Florian Weik
>>>>> 
>>>>> address@hidden <mailto:address@hidden>
>>>>> ++49 157 85939252
>>>>> 
>>>> 
>>>> ------------------------------------------------
>>>> JP Dr. Axel Arnold
>>>> ICP, Universität Stuttgart
>>>> Allmandring 3
>>>> 70569 Stuttgart, Germany
>>>> Email: address@hidden <mailto:address@hidden
>>>> 
>>>> Phone: +49 711 685 67609
>>>> 
>>> 
>>> 
>>> --
>>> Ulf D. Schiller
>>> Centre for Computational Science
>>> University College London
>>> 20 Gordon Street
>>> London WC1H 0AJ
>>> United Kingdom
>>> 
>>> Phone: +44 (0)20 7679 5300
>>> 
>>> 
>> 
>> 
>> -- 
>> Florian Weik
>> 
>> address@hidden
>> ++49 157 85939252

------------------------------------------------
JP Dr. Axel Arnold
ICP, Universität Stuttgart
Allmandring 3
70569 Stuttgart, Germany
Email: address@hidden
Phone: +49 711 685 67609