Closed alexmyczko closed 6 years ago
Issue197
, Transform-mulargs_1
: the example input is not sutable for 32-bit systems.
Issue154
, OutputOptimization_1
: may be real bugs.
The log for ParFORM is really strange:
Check /var/www/debian/form/form-4.2.0/sources/parform
ParFORM 4.2.0 (Jul 6 2017, v4.2.0) 32-bits -1 workers Run: Mon Jul 10 22:04:00 2017
which looks like MPI is not working properly.
thanks for looking into it! i can test build it on amd64, will post results if it asks to...
The build on amd64 just looks fine: https://people.phys.ethz.ch/~myczko/debian/form/form_4.2.0-1_amd64.build
Have you seen the bugs @debian? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835138 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853404
I was a bit playing with a 32-bit build on a Docker container by i686/ubuntu on my Windows laptop. There I got failures for Issue197
, Transform-mulargs_1
and OutputOptimization_1
with FORM and TFORM, but not for Issue154
. Valgrind gave me no errors for Issue154
with vorm
.
Here is a Valgrind log for the optimization bug
FORM 4.2.0 (Jul 11 2017, v4.2.0-6-g795bb56) 32-bits Run: Wed Jul 12 08:37:12 2017
S x;
L F = x;
Format O1;
P;
.end
Time = 0.09 sec Generated terms = 1
F Terms in output = 1
Bytes used = 18
==8898== Invalid read of size 4
==8898== at 0x80BC44D: Optimize (optimize.cc:4585)
==8898== by 0x812AAC2: WriteAll (sch.c:2500)
==8898== by 0x807E834: DoExecute (execute.c:838)
==8898== by 0x80967E2: ExecModule (module.c:274)
==8898== by 0x80FEADE: PreProcessor (pre.c:962)
==8898== by 0x8139C23: main (startup.c:1605)
==8898== Address 0x1d4 is not stack'd, malloc'd or (recently) free'd
==8898==
Program terminating at test.frm Line 4 -->
Somehow cbuf
is NULL
at optimize.cc:4585.
Now all the tests pass in my environment.
For the record, I managed to build form within Termux (https://github.com/termux) for Android. I cannot build from the git repo (something to do with autotools or such) but I can build v.4.2.0, and the latest commit's files copied into the v4.2.0 directory.
EDIT: I was able to get autoreconf -i
working by adding square brackets around FORM_VERSION
on configure.ac:74
.
I had to modify tools.c
to use <sys/time.h>, gettimeofday
instead of <sys/timeb.h>, ftime
(doesn't exist in Termux, removed in POSIX 2008), and also install boost-dev
for unordered_map
etc and also zlib1g-dev
. Also I had to change the shell location in a few places in configure
to /data/data/com.termux/files/usr/bin/bash
.
Here are the test log files, with the latest commit Issue154
fails (just a timeout, it seems), as well as ExtComm_1
(strange environment issue, I guess).
What was the problem when you didn't remove the square brackets around FORM_VERSION
? (at configure.ac:70?) I'm not sure why FORM_VERSION
is not quoted: maybe it should be expanded before the expansion of AC_INIT
, maybe was with an old version of autoconf
, maybe I was just wrong.
It gave AC_INIT should be called with package and version arguments
Yes, I feel the reason why I removed the square brackets was to force the version number to be expanded before being passed into AC_INIT
to avoid such an error... Or maybe you got some error during expanding FORM_VERSION
? Do you have cat
in your environment??
Yes I have cat
, I am not sure why Test_ExtComm_1
fails. Likely not form's fault...
Maybe it is helpful to provide the full output:
configure.ac:74: error: AC_INIT should be called with package and version arguments
/data/data/com.termux/files/usr/share/aclocal-1.15/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:74: the top level
autom4te: /data/data/com.termux/files/usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
autoreconf --version
is 2.69
, m4 --version
is 1.4.18
.
I am not suggesting that this environment should be supported, I am just reporting in case any of this is real bugs and not strange environment effects.
If it is not a problem with the environment, probably it should be reproducible in other environments somehow. But I haven't succeeded to reproduce it... I'm wondering if esyscmd
(calling the shell from m4) is working correctly or not.
This could be the problem, esyscmd(`echo foo')
in m4
returns nothing.
Resolving the esyscmd
problem on the specific system may require non-trivial tricks. Probably we can close this issue for now.
you'll find all output at http://sid.ethz.ch/debian/form/form_4.2.0-1_i386.build