x86: divide by zero because of invalid CPUID vendor on FreeBSD11.1 with Clang 4.0 #282

outpaddling · 2018-01-13T21:05:21Z

Discovered an issue with slurmd crashing on a few specific machines and traced it back to hwloc.

Running on an old Xeon processor, most hwloc programs produce a SEGV if built with -O2, and a floating exception when compiled with -g and no optimization flags.

root@login:/usr/ports/devel/hwloc # hwloc-info
Segmentation fault (core dumped)

root@login:/usr/ports/devel/hwloc # hwloc-info
Floating exception (core dumped)

The problem occurs with 1.11.7 and later. It does not occur with 1.11.1. I have not tried any versions in between (but I will if we need to pinpoint the commit where the problem appeared).

Compiled with -g and running under gdb provides the location of the problem. Does the output below indicate an obvious cause/solution? Do the arguments to look_proc() seem reasonable? I don't know what cpuid actually means, but this system has only 4 cores.

root@login:/usr/ports/devel/hwloc # gdb hwloc-info
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run
Starting program: /usr/local/bin/hwloc-info

Program received signal SIGFPE, Arithmetic exception.
0x000000080085c01e in look_proc (backend=0x8020380c0, infos=0x80203d000,
highest_cpuid=10, highest_ext_cpuid=2147483656, features=0x7fffffffe750,
cpuid_type=86212608) at topology-x86.c:482
482 cache->cacheid = infos->apicid / cache->nbthreads_sharing;
Current language: auto; currently minimal

Some relevant system info:

FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017
root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz (2992.56-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x6f6 Family=0x6 Model=0xf Stepping=6
Features=0xbfebfbff<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,HTT,TM,PBE>
Features2=0x4e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA>
AMD Features=0x20100800<SYSCALL,NX,LM>
AMD Features2=0x1
VT-x: (disabled in BIOS) HLT,PAUSE
TSC: P-state invariant, performance statistics
real memory = 8589934592 (8192 MB)
avail memory = 8261402624 (7878 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 2 package(s) x 2 core(s)

I'm seeing the problem on 3 identical systems out of 4. All running FreeBSD 11.1 fully updated, same CPUs. Maybe some difference in BIOS settings is the trigger?

Probably related issue with another app:

fireice-uk/xmr-stak#817

bgoglin · 2018-01-13T21:16:16Z

If cache->nbthreads_sharing is 0, we indeed have a problem.

Can you take a git master tarball from https://ci.inria.fr/hwloc/job/master-0-tarball/ , build it, verify that its hwloc-info crashes too, run hwloc-gather-cpuid, and then send the "cpuid" directory that it should generate? It should give me anything I need to debug from here.

bgoglin · 2018-01-13T22:32:50Z

"cpuid_type=86212608" looks strange in your gdb output, and the code would indeed crash if we try to discover both AMD and Intel caches. I can workaround that crash (first patch below), but there's something else going wrong about the vendor reported in cpuid (second patch below).

diff --git a/src/topology-x86.c b/src/topology-x86.c
index 23b0e555..f27c1c1b 100644
--- a/src/topology-x86.c
+++ b/src/topology-x86.c
@@ -250,6 +250,9 @@ static void look_proc(struct hwloc_backend *backend, struct procinfo *infos, uns
   if (cpuid_type != intel && cpuid_type != zhaoxin && has_topoext(features)) {
     unsigned apic_id, node_id, nodes_per_proc;
 
+    /* the code below doesn't want any other cache yet */
+    assert(!infos->numcaches);
+
     eax = 0x8000001e;
     hwloc_x86_cpuid(&eax, &ebx, &ecx, &edx);
     infos->apicid = apic_id = eax;
@@ -357,6 +360,9 @@ static void look_proc(struct hwloc_backend *backend, struct procinfo *infos, uns
    */
   if (cpuid_type != amd && highest_cpuid >= 0x04) {
     unsigned level;
+
+    unsigned oldnumcaches = infos->numcaches; /* in case we got caches above */
+
     for (cachenum = 0; ; cachenum++) {
       unsigned type;
       eax = 0x04;
@@ -386,7 +392,8 @@ static void look_proc(struct hwloc_backend *backend, struct procinfo *infos, uns
       }
     }
 
-    cache = infos->cache = malloc(infos->numcaches * sizeof(*infos->cache));
+    infos->cache = realloc(infos->cache, infos->numcaches * sizeof(*infos->cache));
+    cache = &infos->cache[oldnumcaches];
 
     for (cachenum = 0; ; cachenum++) {
       unsigned long linesize, linepart, ways, sets;

diff --git a/src/topology-x86.c b/src/topology-x86.c
index f27c1c1b..f19019b2 100644
--- a/src/topology-x86.c
+++ b/src/topology-x86.c
@@ -1065,6 +1065,10 @@ int hwloc_look_x86(struct hwloc_backend *backend, int fulldiscovery)
   eax = 0x00;
   hwloc_x86_cpuid(&eax, &ebx, &ecx, &edx);
   highest_cpuid = eax;
+  printf("got vendor %c%c%c%c%c%c%c%c%c%c%c%c\n",
+	 ebx&0xff, (ebx>>8)&0xff, (ebx>>16)&0xff, (ebx>>24)&0xff,
+	 edx&0xff, (edx>>8)&0xff, (edx>>16)&0xff, (edx>>24)&0xff,
+	 ecx&0xff, (ecx>>8)&0xff, (ecx>>16)&0xff, (ecx>>24)&0xff);
   if (ebx == INTEL_EBX && ecx == INTEL_ECX && edx == INTEL_EDX)
     cpuid_type = intel;
   if (ebx == AMD_EBX && ecx == AMD_ECX && edx == AMD_EDX)

bgoglin · 2018-01-13T22:40:51Z

Oh we had a similar issue in OpenMPI on FreeBSD11.1 when using clang 4.0. No problem with GCC.
open-mpi/ompi#3992
We just forgot about it and told users to avoid that clang on that FreeBSD release. Might still be good to apply the above patches and report the printf output, just to verify that clang is buggy. The output of hwloc-gather-cpuid is likely unneeded now.

outpaddling · 2018-01-14T16:56:13Z

I applied your patches to 1.11.7 and the crash is resolved.

Is there anything else we should do to fully verify proper function?

Thanks!

Jason

root@login:/usr/ports/wip/hwloc # hwloc-info
got vendor GenuineIntel
depth 0: 1 Machine (type #1)
depth 1: 2 Package (type #3)
depth 2: 2 L2Cache (type #4)
depth 3: 4 L1dCache (type #4)
depth 4: 4 L1iCache (type #4)
depth 5: 4 Core (type #5)
depth 6: 4 PU (type #6)
Special depth -3: 6 Bridge (type #9)
Special depth -4: 5 PCI Device (type #10)

bgoglin · 2018-01-14T17:01:04Z

The vendor string is correct so the compiler was indeed generating buggy code that failed to recognize that string.
I'll apply the first patch anyway, we'll likely hit the same crash if somebody ever uses that code on non-Intel non-AMD non-Zhaoxin x86 CPUs.
Thanks

The old code increased numcaches in the second case but it added additional caches at the beginning of the array. Uninitialized caches in the array caused a divide by zero (cache->nbthreads_sharing) when used later. Only occurs if the CPUID vendor isn't recognized (neither Intel, nor AMD, nor Zhaoxin) or in case of clang 4.0 bug on FreeBSD11.1 (#282). That's also why the code was crashing on Zhaoxin instead of just reporting wrong topology (#279). Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>

The old code increased numcaches in the second case but it added additional caches at the beginning of the array. Uninitialized caches in the array caused a divide by zero (cache->nbthreads_sharing) when used later. Only occurs if the CPUID vendor isn't recognized (neither Intel, nor AMD, nor Zhaoxin) or in case of clang 4.0 bug on FreeBSD11.1 (#282). That's also why the code was crashing on Zhaoxin instead of just reporting wrong topology (#279). Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr> (cherry picked from commit a6f013c)

outpaddling · 2018-01-14T17:30:09Z

Actually, something else is going on here. If I remove the printf() patch, it crashes again. :-/

outpaddling · 2018-01-14T19:03:20Z

So in my experience, including much of my own code, problems like this almost never turn out to be a compiler bug. Instead, different platforms, compilers, optimization flags, or inputs expose subtle bugs in the code that go unnoticed elsewhere. For that reason I try to test my own code with a variety of tools.

While there isn't a strong motivation to shore up support for 10-year-old processors, I think this is worth a little more examination as it might lead us to an undiscovered hwloc issue.

I'll keep poking around for a bit in an effort to pinpoint this problem, as I seem to be the only one with the magic combination of hardware and software to trigger this. I'd appreciate some feedback along the way. Here's the latest backtrace with the patches (minus the printf) in place. If anything looks odd, please let me know and I'll try to trace it to the cause.

Thanks,

Jason

(gdb) where
#0 0x0000000805238000 in ?? ()
#1 0x000000080084f61b in look_procs (backend=0x80203d0c0,
fulldiscovery=, highest_cpuid=,
highest_ext_cpuid=2147483656, cpuid_type=intel, infos=,
features=, get_cpubind=,
set_cpubind=) at topology-x86.c:932
#2 hwloc_look_x86 (backend=0x80203d0c0, fulldiscovery=)
at topology-x86.c:1091
#3 0x000000080084f037 in hwloc_x86_discover (backend=0x80203d0c0)
at topology-x86.c:1162
#4 0x0000000800833d51 in hwloc_discover (topology=)
at topology.c:2537
#5 hwloc_topology_load (topology=0x802038000) at topology.c:3038
#6 0x00000000004027ad in ?? ()
#7 0x0000000000401b4f in ?? ()
#8 0x000000080062b000 in ?? ()
#9 0x0000000000000000 in ?? ()

bgoglin · 2018-01-14T20:26:53Z

You're not the only one, at least two person running OpenMPI jenkins platforms have seen similar issues without ever understanding what was going on. All of them came from Clang 4.0 on FreeBSD11.1, and the crash moving from one place to another depending on debug printf that we added, and depending on which hwloc release was used. I also had problems with that compiler on my hwloc jenkins 6 months ago, and I quickly switched to gcc but I don't remember what the actual issue was.

I am still convinced this is a compiler bug, possibly caused by lots of inline assembly being used in that file (topology-x86.c). Anyway, first thing to do is to pass --enable-debug on the command-line to get additional debug printf. Then, you should go back to the original report where cpuid_type was set to a crazy value (86212608) according to gdb. Adding some assert() or printf() around the first call to hwloc_x86_cpuid() inside hwloc_look_x86() to check the value of cpuid_type might be a good starting point. It should be unknown before and intel later.

Your backtrace isn't helpful because it crashes when calling a callback that is passed by the caller. However that callback is a function that should be visible to gdb, so you may want to printf() the value of get_cpubind when set in hwloc_look_x86() and later before called in look_procs().

outpaddling · 2018-01-15T02:41:54Z

Oops, I'd already added the config flag but forgot to paste in the output along with the gdb trace:

Let me know if anything looks funny here and I'll try to wrap my head around the code starting from there.

FreeBSD login.wren bacon ~ 24: hwloc-info
hwloc verbose debug enabled, may be disabled with HWLOC_DEBUG_VERBOSE=0 in the environment.

CPU cpusets *

cpu 0 (os 0) has cpuset 0x00000001
cpu 1 (os 1) has cpuset 0x00000002
cpu 2 (os 2) has cpuset 0x00000004
cpu 3 (os 3) has cpuset 0x00000008
Machine#0(local=8352104KB total=0KB Backend=FreeBSD OSName=FreeBSD OSRelease=11.1-RELEASE-p4 OSVersion="FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC" HostName=login.wren.hpc.uwm.edu Architecture=amd64) cpuset 0xf...f complete 0x0000000f online 0xf...f allowed 0xf...f nodeset 0x0 completeN 0x0 allowedN 0xf...f
PU#0 cpuset 0x00000001
PU#1 cpuset 0x00000002
PU#2 cpuset 0x00000004
PU#3 cpuset 0x00000008
Backend x86 forcing a reconnect of levels
--- PU level has number 1

hwloc verbose debug enabled, may be disabled with HWLOC_DEBUG_VERBOSE=0 in the environment.
highest cpuid a, cpuid type 0
highest extended cpuid 80000008
binding to CPU0
Segmentation fault (core dumped)

outpaddling · 2018-01-16T21:06:33Z

Additional info:

I'm able to reproduce the issue on newer hardware, including several Opteron systems and a Core i7.
Compiling with clang 4.0.1 or clang 5.0.0 produces the same issue.
Compiling with -O0 helps on some systems and -O1 helps on another.
The issue starts at hwloc 1.11.3. A diff on topology-x86.c shows major changes to the hwloc_bitmap_*() usage. Interestingly, there are no changes to topology-freebsd.c between those releases. I don't know if that's even relevant, as I'm not familiar with the code, but it caught my eye.
My first guess in a case like this would be that we may be looking at a bug that's dependent on how the compiler maps variables into memory.

A simple example:

int c, list[10];
for (c=0; c<12; ++c) // Oops, too far
list[c] = 0;

If the compiler assigns c the address right after list, c will be corrupted by the loop. If c is placed before list, the bug will go unnoticed. Changing compilers or optimization flags could alter the memory map as the compiler attempts to pack the variables for minimum space and optimal alignment.
Building this with clang -O0, I get an infinite loop. With any other optimization level, it finishes normally (I would guess because c is cached in a register for the duration of the loop).
This is just one simple example, but in my experience, bugs of this nature are very common in the wild and only flushed out by compiling on different platforms, or with different compilers or options.

I'll try inserting more debug output when I have some time. In the meantime, I'd appreciate any comments on the hwloc-info output above.

Thanks.

bgoglin · 2018-01-16T21:49:36Z

There's nothing useful in the hwloc-info output unfortunately :/

topology-freebsd.c is pretty much empty because the FreeBSD kernel doesn't report topology information. That's why hwloc falls back to topology-x86.c on this OS.

There are only 7 commits in topology-x86.c between 1.11.2 and 1.11.3. I went on my FreeBSD11.1 jenkins VM and reenable clang 4.0. I reverted these one by one until the crash disappeared with 316a42f but that doesn't make much sense:
But this patch does nothing in our case (it disables the summarize() call at the end of look_procs() on crazy SGI platforms). Second, the code changed by that patch isn't even called here, the crash occurs in the for() loop above it.

outpaddling · 2018-01-16T23:18:26Z

Well, it's information anyway, that might help us narrow it down.
I'll take a look at the code when I get a chance. I love tracking down squirrely runtime issues. Really...
Thanks for your help,
JB

Jehops · 2018-02-01T21:05:08Z

Running hwloc-info or hwloc-ls on any of our AMD-based cluster nodes works. However, hwloc-info and hwloc-ls core dump on any system I tried with Intel CPUs.

bgoglin · 2018-02-01T21:07:53Z

@Jehops can you get a backtrace from gdb?

Jehops · 2018-02-01T21:34:42Z

root@11amd64-default:/var/tmp # /usr/local/bin/gdb /usr/local/bin/hwloc-info /var/tmp/hwloc-info.core
GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
Copyright (C) 2017 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-portbld-freebsd11.1".
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 /usr/local/bin/hwloc-info...done.
[New LWP 100818]
Core was generated by `hwloc-info'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x000000080085c01e in look_proc (backend=0x8020330c0, infos=0x802016500, highest_cpuid=13, highest_ext_cpuid=2147483656,
    features=0x7fffffffe860, cpuid_type=(unknown: 2784894432)) at topology-x86.c:482
482         cache->cacheid = infos->apicid / cache->nbthreads_sharing;
(gdb) bt
#0  0x000000080085c01e in look_proc (backend=0x8020330c0, infos=0x802016500, highest_cpuid=13, highest_ext_cpuid=2147483656,
    features=0x7fffffffe860, cpuid_type=(unknown: 2784894432)) at topology-x86.c:482
#1  0x000000080085ae69 in look_procs (backend=0x8020330c0, infos=0x802016500, fulldiscovery=1, highest_cpuid=13,
    highest_ext_cpuid=2147483656, features=0x7fffffffe860, cpuid_type=(unknown: 2784894432),
    get_cpubind=0x800859e10 <hwloc_freebsd_get_thisthread_cpubind>, set_cpubind=0x800859dc0 <hwloc_freebsd_set_thisthread_cpubind>)
    at topology-x86.c:929
#2  0x000000080085aafc in hwloc_look_x86 (backend=0x8020330c0, fulldiscovery=1) at topology-x86.c:1080
#3  0x000000080085a61e in hwloc_x86_discover (backend=0x8020330c0) at topology-x86.c:1151
#4  0x0000000800835e86 in hwloc_discover (topology=0x80202e000) at topology.c:2537
#5  0x0000000800835d05 in hwloc_topology_load (topology=0x80202e000) at topology.c:3038
#6  0x00000000004028d2 in main (argc=0, argv=0x7fffffffeba8) at hwloc-info.c:490
(gdb)

bgoglin · 2018-02-01T22:07:19Z

@Jehops That's exactly the same issue as above. "cpuid_type=(unknown: 2784894432)" is just crazy. Try with another compiler until we understand what's going on with Clang.

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@460636 35697150-7ecd-e111-bb59-0022644237b5

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1

devel/hwloc: Fix segfaults on Intel CPUs Details in this Github issue: open-mpi/hwloc#282

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@460636 35697150-7ecd-e111-bb59-0022644237b5

outpaddling · 2018-02-02T01:46:07Z

A couple suggested workarounds are in the ports PR:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225229

You can try them out using the WIP collection:

https://github.com/outpaddling/freebsd-ports-wip

ghost · 2018-02-02T13:33:35Z

I think it appeared in 1.11.3, when I started having this problem, which seems related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221946

bgoglin · 2018-02-02T13:37:30Z

Yes we confirmed above that it started in 1.11.3 with commit 316a42f but that didn't make any sense. See my comment from 17 days ago.

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@460636 35697150-7ecd-e111-bb59-0022644237b5

ghost · 2018-02-03T12:56:09Z

I have a report from a developer at work that this bug was not appearing on an Intel CPU when the FreeBSD OS was running as a KVM VM.

…D 11.1. This caused a crash when compiled with Clang due to a different stack layout compared to GCC. PR: 225229 See also: open-mpi/hwloc#282 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@462617 35697150-7ecd-e111-bb59-0022644237b5

…D 11.1. This caused a crash when compiled with Clang due to a different stack layout compared to GCC. PR: 225229 See also: open-mpi/hwloc#282

…D 11.1. This caused a crash when compiled with Clang due to a different stack layout compared to GCC. PR: 225229 See also: open-mpi/hwloc#282 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@462617 35697150-7ecd-e111-bb59-0022644237b5

devel/hwloc: Fix segfaults on Intel CPUs Details in this Github issue: open-mpi/hwloc#282

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1

…D 11.1. This caused a crash when compiled with Clang due to a different stack layout compared to GCC. PR: 225229 See also: open-mpi/hwloc#282

bgoglin closed this as completed Jan 14, 2018

bgoglin changed the title ~~Multiple programs crash at topology-x86.c: 482~~ x86: divide by zero because of invalid CPUID vendor on FreeBSD11.1 with Clang 4.0 Jan 14, 2018

uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Feb 1, 2018

devel/hwloc: Fix segfaults on Intel CPUs

830346a

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@460636 35697150-7ecd-e111-bb59-0022644237b5

uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Feb 1, 2018

devel/hwloc: Fix segfaults on Intel CPUs

f2e67aa

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1

uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Feb 1, 2018

MFH: r460636

bbd50a4

devel/hwloc: Fix segfaults on Intel CPUs Details in this Github issue: open-mpi/hwloc#282

swills pushed a commit to swills/freebsd-ports that referenced this issue Feb 3, 2018

devel/hwloc: Fix segfaults on Intel CPUs

ac2c530

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@460636 35697150-7ecd-e111-bb59-0022644237b5

Xiche mentioned this issue Feb 20, 2018

Segmentation Fault on FreeBSD 11 snort3/snort3#35

Closed

bgoglin mentioned this issue Jan 14, 2021

FreeBSD12/clang fails to find Core information from CPUID #442

Closed

uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Apr 1, 2021

MFH: r460636

d8a954d

devel/hwloc: Fix segfaults on Intel CPUs Details in this Github issue: open-mpi/hwloc#282

svmhdvn pushed a commit to svmhdvn/freebsd-ports that referenced this issue Jan 10, 2024

devel/hwloc: Fix segfaults on Intel CPUs

c85d622

Details in this Github issue: open-mpi/hwloc#282 MFH: 2018Q1

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

x86: divide by zero because of invalid CPUID vendor on FreeBSD11.1 with Clang 4.0 #282

x86: divide by zero because of invalid CPUID vendor on FreeBSD11.1 with Clang 4.0 #282

outpaddling commented Jan 13, 2018

bgoglin commented Jan 13, 2018 •

edited

Loading

bgoglin commented Jan 13, 2018

bgoglin commented Jan 13, 2018

outpaddling commented Jan 14, 2018

bgoglin commented Jan 14, 2018

outpaddling commented Jan 14, 2018

outpaddling commented Jan 14, 2018

bgoglin commented Jan 14, 2018

outpaddling commented Jan 15, 2018

outpaddling commented Jan 16, 2018

bgoglin commented Jan 16, 2018 •

edited

Loading

outpaddling commented Jan 16, 2018

Jehops commented Feb 1, 2018 •

edited

Loading

bgoglin commented Feb 1, 2018

Jehops commented Feb 1, 2018

bgoglin commented Feb 1, 2018

outpaddling commented Feb 2, 2018

ghost commented Feb 2, 2018

bgoglin commented Feb 2, 2018

ghost commented Feb 3, 2018

x86: divide by zero because of invalid CPUID vendor on FreeBSD11.1 with Clang 4.0 #282

x86: divide by zero because of invalid CPUID vendor on FreeBSD11.1 with Clang 4.0 #282

Comments

outpaddling commented Jan 13, 2018

bgoglin commented Jan 13, 2018 • edited Loading

bgoglin commented Jan 13, 2018

bgoglin commented Jan 13, 2018

outpaddling commented Jan 14, 2018

bgoglin commented Jan 14, 2018

outpaddling commented Jan 14, 2018

outpaddling commented Jan 14, 2018

bgoglin commented Jan 14, 2018

outpaddling commented Jan 15, 2018

outpaddling commented Jan 16, 2018

bgoglin commented Jan 16, 2018 • edited Loading

outpaddling commented Jan 16, 2018

Jehops commented Feb 1, 2018 • edited Loading

bgoglin commented Feb 1, 2018

Jehops commented Feb 1, 2018

bgoglin commented Feb 1, 2018

outpaddling commented Feb 2, 2018

ghost commented Feb 2, 2018

bgoglin commented Feb 2, 2018

ghost commented Feb 3, 2018

bgoglin commented Jan 13, 2018 •

edited

Loading

bgoglin commented Jan 16, 2018 •

edited

Loading

Jehops commented Feb 1, 2018 •

edited

Loading