Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ponyc-release 0.11.2 run failure without AVX2 #1696

Closed
larkvirtual opened this issue Mar 16, 2017 · 3 comments
Closed

ponyc-release 0.11.2 run failure without AVX2 #1696

larkvirtual opened this issue Mar 16, 2017 · 3 comments

Comments

@larkvirtual
Copy link
Contributor

larkvirtual commented Mar 16, 2017

Hello!
I just upgraded ponyc-release package in Debian:
$ apt-cache policy ponyc-release
ponyc-release:
Installed: 0.11.2-2905.3dc7568
Candidate: 0.11.2-2905.3dc7568
Version table:
*** 0.11.2-2905.3dc7568 500
500 https://dl.bintray.com/pony-language/ponyc-debian pony-language/main amd64 Packages
100 /var/lib/dpkg/status
0.11.1-2870.922bed4 500
500 https://dl.bintray.com/pony-language/ponyc-debian pony-language/main amd64 Packages

$ gdb ponyc
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ponyc...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/ponyc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000000000716f49 in ponyint_next_pow2 ()
(gdb) bt
#0 0x0000000000716f49 in ponyint_next_pow2 ()
#1 0x000000000071708d in ponyint_hashmap_init ()
#2 0x0000000000613fa4 in main ()

$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Model name: Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz
Stepping: 9
CPU MHz: 1822.945
CPU max MHz: 3500.0000
CPU min MHz: 1600.0000
BogoMIPS: 6185.80
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts

No any virtualization is used.

@SeanTAllen
Copy link
Member

I think I found the issue that it was still built with AVX2 because of some sneakiness in how travis works that no one noticed. Verifying now.

@SeanTAllen
Copy link
Member

Ok, yup I know what is wrong.

So if you look at our current .travis.yml

It builds ponyc without any arch set. make test-ci
When we go to deploy, we run make arch=x86_64 ... deploy

The deploy step looks and sees a binary created for make test-ci and uses that.

aka arch changes have no impact. so the last PR would correct Docker issues but not Deb/RPM packages. There are a couple ways to approach this. Weighing my options. Probably going with make clean before doing the deploy build.

SeanTAllen added a commit that referenced this issue Mar 16, 2017
Before this change, when releasing to bintray, we would run

`make deploy arch=x86-64 ... deploy`

with the intent of building a pony compiler and runtime that targets
the x68-64 instruction set. Unfortunately that isn't what would happen.
Because we had previously run

`make test-ci`

Which doesnt specify an architecture and therefore uses features
available on the build machine, we were in fact uploading an arch
specific build- the one created by `make test-ci`.

With this change, we will remove all `make test-ci` related items and
then rebuild for release with the correct make settings.

Fixes #1696
@SeanTAllen
Copy link
Member

#1699 will address this issue.

jemc pushed a commit that referenced this issue Mar 16, 2017
Before this change, when releasing to bintray, we would run

`make deploy arch=x86-64 ... deploy`

with the intent of building a pony compiler and runtime that targets
the x68-64 instruction set. Unfortunately that isn't what would happen.
Because we had previously run

`make test-ci`

Which doesnt specify an architecture and therefore uses features
available on the build machine, we were in fact uploading an arch
specific build- the one created by `make test-ci`.

With this change, we will remove all `make test-ci` related items and
then rebuild for release with the correct make settings.

Fixes #1696
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants