Archive from user: Daniel Roe Hi, Recently on the Amber mailing list a user (Robert Molt) reported that do\_x3dna would crash when he tried to run it with a TRR trajectory generated by cpptraj from AmberTools. However, VMD was able to read and display the cpptraj-generated trajectory with no issues. I was able to reproduce this behavior with ‘gmx rms’ and found that when I forced cpptraj to write the TRR trajectory as big-endian, ‘gmx rms’ was able to run successfully. Is this intentional behavior? Should I be forcing cpptraj to write TRR trajectories as big endian by default? Thanks. -Dan GROMACS version: VERSION 5.1.2 Precision: single Memory model: 32 bit MPI library: thread\_mpi OpenMP support: enabled (GMX\_OPENMP\_MAX\_THREADS = 32) GPU support: disabled OpenCL support: disabled invsqrt routine: gmx\_software\_invsqrt(x) SIMD instructions: SSE2 FFT library: fftw-3.3.4-sse2 RDTSCP usage: disabled C++11 compilation: enabled TNG support: enabled Tracing support: disabled Built on: Thu Mar 17 07:30:12 MDT 2016 Built by: droe@choxnuxe \[CMAKE\] Build OS/arch: Linux 3.13.0-83-generic i686 Build CPU vendor: GenuineIntel Build CPU brand: Intel® Atom™ CPU N280 @ 1.66GHz Build CPU family: 6 Model: 28 Stepping: 2 Build CPU features: apic clfsh cmov cx8 htt lahf\_lm mmx msr pdcm pse sse2 sse3 ssse3 C compiler: /usr/bin/cc GNU 4.8.4 C compiler flags: -msse2 -Wundef -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wpointer-arith -Wall -Wno-unused -Wunused-value -Wunused-parameter -O3 -DNDEBUG -funroll-all-loops -fexcess-precision=fast -Wno-array-bounds C<span class="underline"></span> compiler: /usr/bin/c<span class="underline"></span> GNU 4.8.4 C<span class="underline"></span> compiler flags: -msse2 -std=c++0x -Wundef -Wextra -Wno-missing-field-initializers -Wpointer-arith -Wall -Wno-unused-function -O3 -DNDEBUG -funroll-all-loops -fexcess-precision=fast -Wno-array-bounds Boost version: 1.55.0 (internal) *(from redmine: issue id 1926, created on 2016-03-18 by gmxdefault, closed on 2016-07-28)* * Changesets: * Revision f7d4d019eecd733a56cbf4eeb9c936c6bd775eb1 by Mark Abraham on 2016-07-12T14:09:13Z: ``` Fix trr magic number reading The trr header-reading routine returned an "OK" value if the magic number was wrong, which might lead to chaotic results everywhere, because checking of return values tends not to happen (even when they're right). Other GROMACS magic-number reading routines tend to give a fatal error if the the number is wrong, e.g. by reading a file written in wrong endianness. (This should never be a thing for XDR files, which are defined to be big endian, but such code has existed.) This change adds/restores that behaviour to trr reading, along with separating the behaviour of failing to read a magic integer from reading one that doesn't match. Fixes #1926 Change-Id: I3cdd8ae9172e3b95fc232d8fa31a442d239233db ``` * Revision d465ad8beade866e0d3bc6e2545f7429bf171b76 by Mark Abraham on 2016-12-09T21:26:18Z: ``` Fix logic of TRR reading Commit f7d4d019 introduced a bug where TRR reading reaching the end of the file was indistinguishable from a reading error or a magic-number error. This is now fixed, restoring the end-of-file behaviour that existed before f7d4d019, while retaining the wrong-magic-number behaviour that it introduced. Refs #1926 Change-Id: Ic8540846c481f022bc6ae7b774794792c8c7a523 ``` * Uploads: * [GmxAnalysisLittleEndianSegfault.tgz](/uploads/3968dc9a44590219cd7924287da120fa/GmxAnalysisLittleEndianSegfault.tgz)