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