Menu
▾
▴
#191 gretl 1.10.1 crashes right after start
Dear all,
I got a bug report, that the new gretl 1.10.1 fails directly during startup. That happens on fedora 20. I only tested fedora 21, when updating the package. [1]
Don't know exactly, how to get more meaningful coredumps to see where the crash happens.
All the best,
Johannes
We had a very similar report from the deb-based galaxy (originally happened on Mint, but then was traced back to Debian).
It wasn't very much a bug per se: the problem is that default configure checks for the availability of the sse2 and avx instructions at compile time. Then, of course, if you build the package with those on and then you run it on an older processor, you get a crash.
I wouldn't know what the best course of action is. Perhaps build two binary packages?
This changed only from 1.10.0 to 1.10.1?
Hi,
no, I agree that if downgrading to 1.10.0 solves the problem, then this
seems to indicate that this is not the same problem. Also from looking
at the bug report this seems to be in a 64bit environment, whereas the
other problem was about a 32bit environment I think.
Is the Fedora 1.10.0 package really based on the released version 1.10.0
or on some pre-release source snapshot?
When you say "I only tested fedora 21", do you mean that the bug is not
present on fedora 21, only exists on fedora 20?
thanks,
sven
Am 22.04.2015 um 09:10 schrieb johannes lips:
Hello,
the package was based on the official tarballs and I can't reproduce the problem on fedora 21, that's why I pushed the update, since I thought it's fine.
If the crash is due to "Illegal instruction" (this should be evident
on stderr), then it's the same as the Debian issue: the binary has
been built with AVX instructions and is being run on a non-AVX
machine.
Please note that this cuts across the 32- vs 64-bit distinction
and gretl version numbers. The config-time check for AVX was
introduced in November 2013 and has been in releases since
gretl 1.9.14. The problem will be seen if and only if (a) the
build host is AVX-capable and (b) one then attempts to run the
binary on a non-AVX host. In the Debian case it so happened that
the 32-bit build had this problem while the 64-bit build did not.
By looking at the build logs I could see that this was because
the 32-bit build was done on an AVX machine and the 64-bit build
on a non-AVX machine.
The "fix" (that is, if you need to build a binary that will run
on non-AVX machines) is to use --disable-avx with configure.
Allin, but that would mean that Fedora changed their build process in
the few days between 1.10.0 and 1.10.1? Or do you mean that whether the
build environment has certain hardware features is basically random and
that up to 1.10.0 the Fedora people just got lucky?
Confused,
Sven
Am 22.04.2015 um 14:25 schrieb Allin Cottrell:
On Wed, 22 Apr 2015, Sven S. wrote:
The latter, I think. I guess that Fedora and Debian both have a bunch
of build hosts and which one gets used on any particular occasion may
be random: there would be no problem if a non-AVX host got picked.
You can tell this from the build logs: in response to ./configure you
either see
checking whether to use AVX... yes
or
checking whether to use AVX... no
and that will be machine-dependent unless --disable-avx is passed.
Allin
The latter, I think. I guess that Fedora and Debian both have a bunch of
build hosts and which one gets used on any particular occasion may be
random: there would be no problem if a non-AVX host got picked.
You can tell this from the build logs: in response to ./configure you either
see
checking whether to use AVX... yes
or
checking whether to use AVX... no
and that will be machine-dependent unless --disable-avx is passed.
Ok, thanks a lot for the help. It's fixed now with a new build, which disables AVX during configure.
Ok, I'm a little late in closing this, but it's not a gretl bug, and also a solution is known, so all's well.