View previous topic :: View next topic |
Author |
Message |
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54098 Location: 56N 3W
|
Posted: Fri May 26, 2017 1:56 pm Post subject: |
|
|
drizzt,
All blank silicon starts out as Ryzen X1700 Pro. ( I don't think AMD have made any yet)
They are badged as one thing or another, or scrap, during testing.
AMD may drop cores and cache at the outset, to get more product per wafer, or they may disable faulty cores and areas of cache.
We have seen both from AMD and Intel. Its a way of generating some revenue from items that would otherwise be scrap. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
drizzt Guru
Joined: 21 Jul 2002 Posts: 428
|
Posted: Fri May 26, 2017 1:59 pm Post subject: |
|
|
NeddySeagoon wrote: | drizzt,
All blank silicon starts out as Ryzen X1700 Pro. ( I don't think AMD have made any yet)
They are badged as one thing or another, or scrap, during testing.
AMD may drop cores and cache at the outset, to get more product per wafer, or they may disable faulty cores and areas of cache.
We have seen both from AMD and Intel. Its a way of generating some revenue from items that would otherwise be scrap. |
I know, I just wanted to share all things I have tested so far... _________________ People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect... |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Fri May 26, 2017 2:00 pm Post subject: |
|
|
the entire components industry does it.
Make the parts, test against the toughest ATP. If it passes great, if not move to the next ATP _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54098 Location: 56N 3W
|
Posted: Fri May 26, 2017 2:23 pm Post subject: |
|
|
Naib,
I'm aware :)
I suspect many readers here are not. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Fri May 26, 2017 2:26 pm Post subject: |
|
|
NeddySeagoon wrote: | Naib,
I'm aware
I suspect many readers here are not. | oh I know you know
Start with a RYZEN" die... test it at the max RYZEN7
If pass --> 1800X
IF major fail --> quarantine
lower spec ATP
If pass --> 1700X
IF major fail --> quarantine
lower spec ATP
IF pass --> 1700
IF major fail --> quarantine
Once say 10,000 of each are ready --> SHIP
start re-testing quarantined chips:
Can 6cores function? Identify which 6 and enable RYZEN5
Quarantine those that fail
If pass --> 1600X
IF major fail --> quarantine
lower spec ATP
If pass --> 1600
IF major fail --> quarantine
lower spec ATP
If pass --> 1500X
IF major fail --> quarantine
lower spec ATP
If pass --> 1400
IF major fail --> quarantine
lower spec ATP
Once say 10,000 of each are ready --> SHIP
can 4cores function?
...RYZEN3 _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
likewhoa l33t
Joined: 04 Oct 2006 Posts: 778 Location: Brooklyn, New York
|
Posted: Fri May 26, 2017 8:07 pm Post subject: |
|
|
Naib wrote: | my system is working fine
If you are using a kernel < 4.10 you will have potential issues
If you are using gcc < 5.x you will have potential issues (6.3 starts being good, 7.1 is nice)
If you are not using the latest BIOS you will have potential issues
If your BIOS has set the wrong RAM info (voltage & timing) you will have issues |
On hardened-sources so limited to 4.9.x
Can confirm 6.3 starts to be nice... (chromium,llvm,thunderbird segfault for me)
first thing I always do with a new motherboard is flash the bios, w.r.t RAM I use XMP settings as starting point
then disable and tweak from there. We both have same board I believe. I have two CPUs now, one made in
China the other from Malaysia and the latter seems to OC better at 3.9 1.35vcore RAM (F4-3200C14-8GTZ) 3200Mhz 14-14-14-30 1.37v.
I am currently on gcc-7 -e @world compiled just fine minus latest ~arch chromium which seems to be an issue with
newer gcc and not a segfault like others are reporting and ive noticed in gcc-6.
Quote: | dmesg | grep -i carbon; echo; uname -a; echo; /lib/libc.so.6
[ 0.000000] DMI: Micro-Star International Co., Ltd MS-7A32/X370 GAMING PRO CARBON (MS-7A32), BIOS 1.50 04/27/2017
[ 8.438324] Hardware name: Micro-Star International Co., Ltd MS-7A32/X370 GAMING PRO CARBON (MS-7A32), BIOS 1.50 04/27/2017
Linux lisa 4.8.17-hardened-r2 #5 SMP PREEMPT Thu May 11 16:18:34 EDT 2017 x86_64 AMD Ryzen 7 1700 Eight-Core Processor AuthenticAMD GNU/Linux
GNU C Library (Gentoo 2.23-r3 p7) stable release version 2.23, by Roland McGrath et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.1.0.
Available extensions:
C stubs add-on version 2.1.2
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>. |
Quote: | emerge --info|egrep '(^CFLAGS|LDFLAGS|EMERGE_DEFAULT_OPTS|MAKEOPTS)'
CFLAGS="-O2 -pipe -march=znver1"
EMERGE_DEFAULT_OPTS="-a --jobs=16 --keep-going --with-bdeps=y"
LDFLAGS="-Wl,-O1 -Wl,--as-needed,--sort-common -Wl,-fuse-ld=bfd"
MAKEOPTS="-j16"
|
I plan on staying at 1.35v for vcore as I don't want to be above that for 24/7 use unless I can monitor temps in Linux which we currently can't. Once temp sensors drivers are released, I will go back to tweaking as my goal was 4GHz. |
|
Back to top |
|
|
nitm n00b
Joined: 27 Dec 2004 Posts: 63
|
Posted: Sat May 27, 2017 8:39 am Post subject: |
|
|
Same problem - random crashes of sh/head during compilation with high -j values).
Asus Prime x370 pro, ryzen 7 1700 @ auto/defualt, g.skill flarex F4-2400C15-16GFX @ default.
GCC 5.4, kernel 4.11.1, -march=x86-64 -O2 -pipe, -j8 most of the time.
This is an upgrade from my old core2quad system to amd.
The segfaults are not caused by illegal instructions. I've inspected several core files and there isn't anything repeating. All random memory read, write errors.
Have someone tried to contact kernel developers? The suspect is some problem in the MMU.
List of all errors since last boot:
Code: | [Wed May 24 00:03:58 2017] sh[27338]: segfault at ffffffffa8fca916 ip 00007f2a063a2366 sp 00007ffd4290f8d0 error 7 in libc-2.24.so[7f2a0632b000+18d000]
[Wed May 24 01:09:04 2017] sh[10586]: segfault at 0 ip (null) sp 00007ffd895cb920 error 14 in bash[400000+b5000]
[Wed May 24 03:23:55 2017] sh[6014]: segfault at 7264a0 ip 00000000007264a0 sp 00007ffc06756d78 error 15
[Wed May 24 20:11:55 2017] sh[7182]: segfault at 1 ip 0000000000000001 sp 00007ffd354acdd8 error 14 in bash[400000+b4000]
[Wed May 24 22:06:11 2017] traps: sh[1766] trap invalid opcode ip:43feb0 sp:7ffe12049548 error:0 in bash[400000+b5000]
[Wed May 24 23:21:04 2017] sh[12018]: segfault at 6e3570 ip 00000000006e3570 sp 00007fffc808fbc8 error 15
[Thu May 25 02:34:52 2017] sh[3436]: segfault at 6e1a60 ip 00000000006e1a60 sp 00007fff7a4cb458 error 15
[Thu May 25 22:06:25 2017] sh[9331]: segfault at 4900001e ip 00007f4856d25abe sp 00007fff566b51e0 error 4 in libc-2.24.so[7f4856cae000+18d000]
[Fri May 26 03:24:24 2017] traps: head[19185] general protection ip:7f9431b6f200 sp:7ffee67e4b18 error:0 in ld-2.24.so[7f9431b54000+23000] |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sat May 27, 2017 9:03 am Post subject: |
|
|
[quote="likewhoa"] Naib wrote: |
On hardened-sources so limited to 4.9.x
Can confirm 6.3 starts to be nice... (chromium,llvm,thunderbird segfault for me)
first thing I always do with a new motherboard is flash the bios, w.r.t RAM I use XMP settings as starting point
then disable and tweak from there. We both have same board I believe. I have two CPUs now, one made in
China the other from Malaysia and the latter seems to OC better at 3.9 1.35vcore RAM (F4-3200C14-8GTZ) 3200Mhz 14-14-14-30 1.37v.
I am currently on gcc-7 -e @world compiled just fine minus latest ~arch chromium which seems to be an issue with
newer gcc and not a segfault like others are reporting and ive noticed in gcc-6.
|
chears,
at least one more posting "it works"... Having just failed results does not indicate commonality.
So far people that have been having issues tend to have the B350 chipset (we both have X370). COuld this be a clue? dunno
I have exported the present info to a spreadsheet so people can see.( https://docs.google.com/spreadsheets/d/1gzniXYcXm1uACXGoBLpbpq54KE6SlHxQ6M_wPnTkub8/edit?usp=sharing)
One person has haswell with GCC-5.x and that has been shown to be bad.
Like you I used XMP RAM settings. I noticed all my RAM timings were off until I enabled XMP which then set them correctly. I still think those running into random segfaults have RAM related issues as it has been shown as well Ryzen is very RAM dependent due to the CXX.
I should put an option on to see if people are setting their RAM to the ramstick settings OR what the bios thinks it should be. I am 99% sure this is the issue (assuming hte hardware is good)
AGESA 1.0.0.6 is due out now-2weeks so that should sort some more RAM issues (ie defaults as well as overclocking) _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
frinnst n00b
Joined: 27 May 2017 Posts: 5
|
Posted: Sat May 27, 2017 10:33 am Post subject: |
|
|
ASUS has posted a new BIOS for x370-pro (0612) that seems to have solved my segfault issues. I've been rebuilding heavy stuff for a few hours now without problems. |
|
Back to top |
|
|
nitm n00b
Joined: 27 Dec 2004 Posts: 63
|
Posted: Sat May 27, 2017 11:06 am Post subject: |
|
|
@frinnst: What RAM are you using? What frequency and timings have you set? |
|
Back to top |
|
|
frinnst n00b
Joined: 27 May 2017 Posts: 5
|
Posted: Sat May 27, 2017 12:16 pm Post subject: |
|
|
nitm wrote: | @frinnst: What RAM are you using? What frequency and timings have you set? |
CMK32GX4M2A2400C14 (Corsair 32GB (2x16GB) DDR4 2400MHz CL14 Vengeance) and default settings relating to cpu and ram. It passed a few rounds of memtest even with an old bios. |
|
Back to top |
|
|
frinnst n00b
Joined: 27 May 2017 Posts: 5
|
Posted: Sat May 27, 2017 12:33 pm Post subject: |
|
|
Guess I spoke too soon:
/tmp/firefox-54.0b11-rust-work/src/firefox-54.0b11/firefox-shared/dist/include/nsTArray.h:2194:14: internal compiler error: Segmentation fault
self_type& operator=(const nsTArray_Impl<E, Allocator>& aOther)
:( |
|
Back to top |
|
|
drizzt Guru
Joined: 21 Jul 2002 Posts: 428
|
Posted: Sat May 27, 2017 12:50 pm Post subject: |
|
|
[quote="Naib"] likewhoa wrote: | Naib wrote: |
On hardened-sources so limited to 4.9.x
Can confirm 6.3 starts to be nice... (chromium,llvm,thunderbird segfault for me)
first thing I always do with a new motherboard is flash the bios, w.r.t RAM I use XMP settings as starting point
then disable and tweak from there. We both have same board I believe. I have two CPUs now, one made in
China the other from Malaysia and the latter seems to OC better at 3.9 1.35vcore RAM (F4-3200C14-8GTZ) 3200Mhz 14-14-14-30 1.37v.
I am currently on gcc-7 -e @world compiled just fine minus latest ~arch chromium which seems to be an issue with
newer gcc and not a segfault like others are reporting and ive noticed in gcc-6.
|
chears,
at least one more posting "it works"... Having just failed results does not indicate commonality.
So far people that have been having issues tend to have the B350 chipset (we both have X370). COuld this be a clue? dunno
I have exported the present info to a spreadsheet so people can see.( https://docs.google.com/spreadsheets/d/1gzniXYcXm1uACXGoBLpbpq54KE6SlHxQ6M_wPnTkub8/edit?usp=sharing)
One person has haswell with GCC-5.x and that has been shown to be bad.
Like you I used XMP RAM settings. I noticed all my RAM timings were off until I enabled XMP which then set them correctly. I still think those running into random segfaults have RAM related issues as it has been shown as well Ryzen is very RAM dependent due to the CXX.
I should put an option on to see if people are setting their RAM to the ramstick settings OR what the bios thinks it should be. I am 99% sure this is the issue (assuming hte hardware is good)
AGESA 1.0.0.6 is due out now-2weeks so that should sort some more RAM issues (ie defaults as well as overclocking) |
One of my three answers contained "haswell" as this was my initial starting point.
B350 and (IO-)MMU could be a candidate as I read somewhere else(could have been anandtech) that at least some PCI-E related functionality has been messed up with B350 chipsets and is planned to be fixed with AGESA 1.0.0.6.
Btw. both RAM sets I tested where listed on the OVL of the respected mobo manufacturer and set to XMP as XMP was suggested on the OVL. So if the segfaults should be RAM related, two manufacturers can be sure to get a "nice" e-mail from me _________________ People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect... |
|
Back to top |
|
|
dryatu n00b
Joined: 26 May 2017 Posts: 2
|
Posted: Sat May 27, 2017 12:52 pm Post subject: |
|
|
[quote="Naib"] likewhoa wrote: | Naib wrote: |
On hardened-sources so limited to 4.9.x
Can confirm 6.3 starts to be nice... (chromium,llvm,thunderbird segfault for me)
first thing I always do with a new motherboard is flash the bios, w.r.t RAM I use XMP settings as starting point
then disable and tweak from there. We both have same board I believe. I have two CPUs now, one made in
China the other from Malaysia and the latter seems to OC better at 3.9 1.35vcore RAM (F4-3200C14-8GTZ) 3200Mhz 14-14-14-30 1.37v.
I am currently on gcc-7 -e @world compiled just fine minus latest ~arch chromium which seems to be an issue with
newer gcc and not a segfault like others are reporting and ive noticed in gcc-6.
|
chears,
at least one more posting "it works"... Having just failed results does not indicate commonality.
So far people that have been having issues tend to have the B350 chipset (we both have X370). COuld this be a clue? dunno
I have exported the present info to a spreadsheet so people can see.( https://docs.google.com/spreadsheets/d/1gzniXYcXm1uACXGoBLpbpq54KE6SlHxQ6M_wPnTkub8/edit?usp=sharing)
One person has haswell with GCC-5.x and that has been shown to be bad.
Like you I used XMP RAM settings. I noticed all my RAM timings were off until I enabled XMP which then set them correctly. I still think those running into random segfaults have RAM related issues as it has been shown as well Ryzen is very RAM dependent due to the CXX.
I should put an option on to see if people are setting their RAM to the ramstick settings OR what the bios thinks it should be. I am 99% sure this is the issue (assuming hte hardware is good)
AGESA 1.0.0.6 is due out now-2weeks so that should sort some more RAM issues (ie defaults as well as overclocking) |
Manual or XMP, didn't make a difference for me. Set the timings and voltage according to the G.Skill Flare X product spreadsheet. Segfaults keep happening.
Ryzen 1700
MSI Mortar B350M
G.Skill Flare X 3200
gcc-6.3, march znver1 and rebuilt my toolchain. |
|
Back to top |
|
|
nitm n00b
Joined: 27 Dec 2004 Posts: 63
|
Posted: Sat May 27, 2017 2:20 pm Post subject: |
|
|
frinnst wrote: | Guess I spoke too soon:
/tmp/firefox-54.0b11-rust-work/src/firefox-54.0b11/firefox-shared/dist/include/nsTArray.h:2194:14: internal compiler error: Segmentation fault
self_type& operator=(const nsTArray_Impl<E, Allocator>& aOther)
|
Can you show the line for this event in the dmseg log? |
|
Back to top |
|
|
frinnst n00b
Joined: 27 May 2017 Posts: 5
|
Posted: Sat May 27, 2017 3:19 pm Post subject: |
|
|
[/quote]
Can you show the line for this event in the dmseg log?[/quote]
It's a userspace segfault, not kernel. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sat May 27, 2017 3:32 pm Post subject: |
|
|
frinnst wrote: | Quote: |
Can you show the line for this event in the dmseg log? |
It's a userspace segfault, not kernel. | should still cause an entry in dmesg as it is the kernel that acts on it _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
frinnst n00b
Joined: 27 May 2017 Posts: 5
|
Posted: Sat May 27, 2017 4:00 pm Post subject: |
|
|
Nothing there. besides, the output was not very interesting I dont have any logs saved |
|
Back to top |
|
|
bgamari n00b
Joined: 11 Apr 2017 Posts: 9
|
Posted: Sat May 27, 2017 6:02 pm Post subject: |
|
|
I opened a support request with AMD a bit over a month ago. The issue was quickly escalated and has been in the engineering group for several weeks now. While it's hard to get any concrete details out of support, all of the representatives that I've spoken to have said that AMD is actively investigating the issue. One has remarked that this must be a particularly tricky issue given how long the engineering group has been looking at it.
I also recently discovered a thread (https://community.amd.com/thread/215773) on AMD's support forum which contains more reports of crashes. The support representative who responded essentially reiterated what I was told personally.
It sounds to me like there is a rather nasty bug in the silicon that has shipped. |
|
Back to top |
|
|
trippels Tux's lil' helper
Joined: 24 Nov 2010 Posts: 137 Location: Berlin
|
Posted: Sat May 27, 2017 6:09 pm Post subject: |
|
|
Naib wrote: | frinnst wrote: | Quote: |
Can you show the line for this event in the dmseg log? |
It's a userspace segfault, not kernel. | should still cause an entry in dmesg as it is the kernel that acts on it |
gcc has its own segfault handler, so normally you see nothing in dmesg when gcc crashes. |
|
Back to top |
|
|
trippels Tux's lil' helper
Joined: 24 Nov 2010 Posts: 137 Location: Berlin
|
Posted: Sat May 27, 2017 6:20 pm Post subject: |
|
|
bgamari wrote: | I opened a support request with AMD a bit over a month ago. The issue was quickly escalated and has been in the engineering group for several weeks now. While it's hard to get any concrete details out of support, all of the representatives that I've spoken to have said that AMD is actively investigating the issue. One has remarked that this must be a particularly tricky issue given how long the engineering group has been looking at it.
I also recently discovered a thread (https://community.amd.com/thread/215773) on AMD's support forum which contains more reports of crashes. The support representative who responded essentially reiterated what I was told personally.
It sounds to me like there is a rather nasty bug in the silicon that has shipped. |
It would be helpful to send some coredump files to the AMD engineering group.
That would at least tell them what the corruption looks like. |
|
Back to top |
|
|
nitm n00b
Joined: 27 Dec 2004 Posts: 63
|
Posted: Sat May 27, 2017 6:30 pm Post subject: |
|
|
If there is interest by someone at AMD about corefile, I can gather them.
But I doubt they'll be of much use - it is totally random.
And I've never seen an ICE in GCC, all my crashes are in bash and head. |
|
Back to top |
|
|
drizzt Guru
Joined: 21 Jul 2002 Posts: 428
|
Posted: Sat May 27, 2017 6:47 pm Post subject: |
|
|
ruby crashed rather nasty during emerge:
Code: | ./template/verconf.h.tmpl:3: [BUG] Segmentation fault at 0x00000000000000
ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0009 p:---- s:0052 e:000051 CFUNC :module_eval
c:0008 p:0012 s:0047 e:000046 BLOCK ./template/verconf.h.tmpl:3 [FINISH]
c:0007 p:---- s:0045 e:000044 CFUNC :initialize
c:0006 p:---- s:0043 e:000042 CFUNC :new
c:0005 p:0048 s:0040 E:000940 EVAL ./template/verconf.h.tmpl:3 [FINISH]
c:0004 p:---- s:0032 e:000031 CFUNC :eval
c:0003 p:0050 s:0025 e:000024 METHOD /var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/lib/erb.rb:864
c:0002 p:0384 s:0021 E:0002a8 EVAL ./tool/generic_erb.rb:38 [FINISH]
c:0001 p:0000 s:0002 E:0026f0 *** Error in `./miniruby': malloc(): memory corruption: 0x00007ffc0ea749d8 ***
(none) [FINISH]
-- Ruby level backtrace information ----------------------------------------
./tool/generic_erb.rb:38:in `<main>'
/var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/lib/erb.rb:864:in `result'
/var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/lib/erb.rb:864:in `eval'
./template/verconf.h.tmpl:3:in `<main>'
./template/verconf.h.tmpl:3:in `new'
./template/verconf.h.tmpl:3:in `initialize'
./template/verconf.h.tmpl:3:in `block in <main>'
./template/verconf.h.tmpl:3:in `module_eval'
-- Machine register context ------------------------------------------------
RIP: 0x00007f58baaa9eac RBP: 0x00007f58badbfb38 RSP: 0x00007ffe4934e290
RAX: 0x0000000000000000 RBX: 0x00000000023ff7d0 RCX: 0x000000000000000a
RDX: 0x0000000000000400 RDI: 0x00007f58badbfbc8 RSI: 0x0000000000000440
R8: 0x00007f58badbfbc8 R9: 0x0000000002133a10 R10: 0x0000000000000000
R11: 0x00000000024052f0 R12: 0x3939313a39393839 R13: 0x0000000000000130
R14: 0x00007f58badbfae0 R15: 0x000000000000270d EFL: 0x0000000000010202
-- C level backtrace information -------------------------------------------
======= Backtrace: =========
/lib64/libc.so.6(+0x6ffda)[0x7f0b1ee0ffda]
/lib64/libc.so.6(+0x760f5)[0x7f0b1ee160f5]
/lib64/libc.so.6(+0x78029)[0x7f0b1ee18029]
/lib64/libc.so.6(__libc_malloc+0x54)[0x7f0b1ee19de4]
./miniruby[0x47c718]
./miniruby[0x4b9584]
./miniruby[0x4ccae0]
./miniruby[0x4cf9a9]
./miniruby[0x58e0cc]
./miniruby(rb_iseq_compile_with_option+0x1c1)[0x56a641]
./miniruby[0x58139a]
./miniruby[0x581b4e]
./miniruby[0x57647a]
./miniruby[0x5795c2]
./miniruby[0x57ff4f]
./miniruby(rb_yield+0x388)[0x585048]
./miniruby(rb_ary_each+0x3b)[0x41b0fb]
./miniruby[0x57647a]
./miniruby[0x585c5f]
./miniruby[0x586ccb]
./miniruby[0x5796a7]
./miniruby[0x57ff4f]
./miniruby[0x462d59]
./miniruby[0x464d60]
./miniruby(rb_require_safe+0x9)[0x464eb9]
./miniruby[0x57647a]
./miniruby[0x585c5f]
./miniruby[0x586ccb]
./miniruby[0x5795c2]
./miniruby[0x57ff4f]
./miniruby[0x462d59]
./miniruby[0x4633bd]
./miniruby[0x463499]
./miniruby[0x57647a]
./miniruby[0x585c5f]
./miniruby[0x586ccb]
./miniruby[0x5795c2]
./miniruby[0x57ff4f]
./miniruby[0x45e06a]
./miniruby(ruby_exec_node+0x1d)[0x45fa7d]
./miniruby(ruby_run_node+0x1e)[0x461cde]
./miniruby[0x4192cb]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f0b1edc01c1]
./miniruby(_start+0x2a)[0x4192fa]
======= Memory map: ========
00400000-00669000 r-xp 00000000 00:22 865631 /var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/miniruby
00869000-0086e000 r--p 00269000 00:22 865631 /var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/miniruby
0086e000-0086f000 rw-p 0026e000 00:22 865631 /var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/miniruby
0086f000-00880000 rw-p 00000000 00:00 0
01a20000-01db3000 rw-p 00000000 00:00 0 [heap]
7f0b18000000-7f0b18021000 rw-p 00000000 00:00 0
7f0b18021000-7f0b1c000000 ---p 00000000 00:00 0
7f0b1e7e1000-7f0b1e7f7000 r-xp 00000000 08:03 7876151 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/libgcc_s.so.1
7f0b1e7f7000-7f0b1e9f6000 ---p 00016000 08:03 7876151 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/libgcc_s.so.1
7f0b1e9f6000-7f0b1e9f7000 r--p 00015000 08:03 7876151 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/libgcc_s.so.1
7f0b1e9f7000-7f0b1e9f8000 rw-p 00016000 08:03 7876151 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/libgcc_s.so.1
7f0b1e9f8000-7f0b1eda0000 r--p 00000000 08:03 7869426 /usr/lib64/locale/locale-archive
7f0b1eda0000-7f0b1ef29000 r-xp 00000000 08:03 4590444 /lib64/libc-2.24.so
7f0b1ef29000-7f0b1f129000 ---p 00189000 08:03 4590444 /lib64/libc-2.24.so
7f0b1f129000-7f0b1f12d000 r--p 00189000 08:03 4590444 /lib64/libc-2.24.so
7f0b1f12d000-7f0b1f12f000 rw-p 0018d000 08:03 4590444 /lib64/libc-2.24.so
7f0b1f12f000-7f0b1f133000 rw-p 00000000 00:00 0
7f0b1f133000-7f0b1f22b000 r-xp 00000000 08:03 4588589 /lib64/libm-2.24.so
7f0b1f22b000-7f0b1f42a000 ---p 000f8000 08:03 4588589 /lib64/libm-2.24.so
7f0b1f42a000-7f0b1f42b000 r--p 000f7000 08:03 4588589 /lib64/libm-2.24.so
7f0b1f42b000-7f0b1f42c000 rw-p 000f8000 08:03 4588589 /lib64/libm-2.24.so
7f0b1f42c000-7f0b1f434000 r-xp 00000000 08:03 4590445 /lib64/libcrypt-2.24.so
7f0b1f434000-7f0b1f634000 ---p 00008000 08:03 4590445 /lib64/libcrypt-2.24.so
7f0b1f634000-7f0b1f635000 r--p 00008000 08:03 4590445 /lib64/libcrypt-2.24.so
7f0b1f635000-7f0b1f636000 rw-p 00009000 08:03 4590445 /lib64/libcrypt-2.24.so
7f0b1f636000-7f0b1f664000 rw-p 00000000 00:00 0
7f0b1f664000-7f0b1f666000 r-xp 00000000 08:03 4590429 /lib64/libdl-2.24.so
7f0b1f666000-7f0b1f866000 ---p 00002000 08:03 4590429 /lib64/libdl-2.24.so
7f0b1f866000-7f0b1f867000 r--p 00002000 08:03 4590429 /lib64/libdl-2.24.so
7f0b1f867000-7f0b1f868000 rw-p 00003000 08:03 4590429 /lib64/libdl-2.24.so
7f0b1f868000-7f0b1f8df000 r-xp 00000000 08:03 6573335 /usr/lib64/libgmp.so.10.3.2
7f0b1f8df000-7f0b1fade000 ---p 00077000 08:03 6573335 /usr/lib64/libgmp.so.10.3.2
7f0b1fade000-7f0b1fadf000 r--p 00076000 08:03 6573335 /usr/lib64/libgmp.so.10.3.2
7f0b1fadf000-7f0b1fae0000 rw-p 00077000 08:03 6573335 /usr/lib64/libgmp.so.10.3.2
7f0b1fae0000-7f0b1faf7000 r-xp 00000000 08:03 4590452 /lib64/libpthread-2.24.so
7f0b1faf7000-7f0b1fcf6000 ---p 00017000 08:03 4590452 /lib64/libpthread-2.24.so
7f0b1fcf6000-7f0b1fcf7000 r--p 00016000 08:03 4590452 /lib64/libpthread-2.24.so
7f0b1fcf7000-7f0b1fcf8000 rw-p 00017000 08:03 4590452 /lib64/libpthread-2.24.so
7f0b1fcf8000-7f0b1fcfc000 rw-p 00000000 00:00 0
7f0b1fcfc000-7f0b1fd0f000 r-xp 00000000 08:03 6572056 /usr/lib64/libsandbox.so
7f0b1fd0f000-7f0b1ff0f000 ---p 00013000 08:03 6572056 /usr/lib64/libsandbox.so
7f0b1ff0f000-7f0b1ff10000 r--p 00013000 08:03 6572056 /usr/lib64/libsandbox.so
7f0b1ff10000-7f0b1ff11000 rw-p 00014000 08:03 6572056 /usr/lib64/libsandbox.so
7f0b1ff11000-7f0b1ff19000 rw-p 00000000 00:00 0
7f0b1ff19000-7f0b1ff3c000 r-xp 00000000 08:03 4590443 /lib64/ld-2.24.so
7f0b1ffb7000-7f0b1ffbe000 r--s 00000000 08:03 6573968 /usr/lib64/gconv/gconv-modules.cache
7f0b1ffbe000-7f0b1ffbf000 ---p 00000000 00:00 0
7f0b1ffbf000-7f0b200da000 rw-p 00000000 00:00 0
7f0b200da000-7f0b2013b000 rw-p 00000000 00:00 0
7f0b2013b000-7f0b2013c000 r--p 00022000 08:03 4590443 /lib64/ld-2.24.so
7f0b2013c000-7f0b2013d000 rw-p 00023000 08:03 4590443 /lib64/ld-2.24.so
7f0b2013d000-7f0b2013e000 rw-p 00000000 00:00 0
7ffc0e27f000-7ffc0ea7e000 rw-p 00000000 00:00 0 [stack]
7ffc0eb74000-7ffc0eb77000 r--p 00000000 00:00 0 [vvar]
7ffc0eb77000-7ffc0eb79000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
make: *** [uncommon.mk:655: enc.mk] Aborted
make: *** Waiting for unfinished jobs.... |
dmesg:
Code: | sh[11044]: segfault at 3f9e850 ip 00000000004414a0 sp 00007fffbdbd8070 error 4 in bash[400000+b1000] |
Maybe there's a hint hidden in there... _________________ People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect... |
|
Back to top |
|
|
drizzt Guru
Joined: 21 Jul 2002 Posts: 428
|
Posted: Sat May 27, 2017 10:58 pm Post subject: |
|
|
drizzt wrote: | ruby crashed rather nasty during emerge:
Code: | ./template/verconf.h.tmpl:3: [BUG] Segmentation fault at 0x00000000000000
ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0009 p:---- s:0052 e:000051 CFUNC :module_eval
c:0008 p:0012 s:0047 e:000046 BLOCK ./template/verconf.h.tmpl:3 [FINISH]
c:0007 p:---- s:0045 e:000044 CFUNC :initialize
c:0006 p:---- s:0043 e:000042 CFUNC :new
c:0005 p:0048 s:0040 E:000940 EVAL ./template/verconf.h.tmpl:3 [FINISH]
c:0004 p:---- s:0032 e:000031 CFUNC :eval
c:0003 p:0050 s:0025 e:000024 METHOD /var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/lib/erb.rb:864
c:0002 p:0384 s:0021 E:0002a8 EVAL ./tool/generic_erb.rb:38 [FINISH]
c:0001 p:0000 s:0002 E:0026f0 *** Error in `./miniruby': malloc(): memory corruption: 0x00007ffc0ea749d8 ***
(none) [FINISH]
-- Ruby level backtrace information ----------------------------------------
./tool/generic_erb.rb:38:in `<main>'
/var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/lib/erb.rb:864:in `result'
/var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/lib/erb.rb:864:in `eval'
./template/verconf.h.tmpl:3:in `<main>'
./template/verconf.h.tmpl:3:in `new'
./template/verconf.h.tmpl:3:in `initialize'
./template/verconf.h.tmpl:3:in `block in <main>'
./template/verconf.h.tmpl:3:in `module_eval'
-- Machine register context ------------------------------------------------
RIP: 0x00007f58baaa9eac RBP: 0x00007f58badbfb38 RSP: 0x00007ffe4934e290
RAX: 0x0000000000000000 RBX: 0x00000000023ff7d0 RCX: 0x000000000000000a
RDX: 0x0000000000000400 RDI: 0x00007f58badbfbc8 RSI: 0x0000000000000440
R8: 0x00007f58badbfbc8 R9: 0x0000000002133a10 R10: 0x0000000000000000
R11: 0x00000000024052f0 R12: 0x3939313a39393839 R13: 0x0000000000000130
R14: 0x00007f58badbfae0 R15: 0x000000000000270d EFL: 0x0000000000010202
-- C level backtrace information -------------------------------------------
======= Backtrace: =========
/lib64/libc.so.6(+0x6ffda)[0x7f0b1ee0ffda]
/lib64/libc.so.6(+0x760f5)[0x7f0b1ee160f5]
/lib64/libc.so.6(+0x78029)[0x7f0b1ee18029]
/lib64/libc.so.6(__libc_malloc+0x54)[0x7f0b1ee19de4]
./miniruby[0x47c718]
./miniruby[0x4b9584]
./miniruby[0x4ccae0]
./miniruby[0x4cf9a9]
./miniruby[0x58e0cc]
./miniruby(rb_iseq_compile_with_option+0x1c1)[0x56a641]
./miniruby[0x58139a]
./miniruby[0x581b4e]
./miniruby[0x57647a]
./miniruby[0x5795c2]
./miniruby[0x57ff4f]
./miniruby(rb_yield+0x388)[0x585048]
./miniruby(rb_ary_each+0x3b)[0x41b0fb]
./miniruby[0x57647a]
./miniruby[0x585c5f]
./miniruby[0x586ccb]
./miniruby[0x5796a7]
./miniruby[0x57ff4f]
./miniruby[0x462d59]
./miniruby[0x464d60]
./miniruby(rb_require_safe+0x9)[0x464eb9]
./miniruby[0x57647a]
./miniruby[0x585c5f]
./miniruby[0x586ccb]
./miniruby[0x5795c2]
./miniruby[0x57ff4f]
./miniruby[0x462d59]
./miniruby[0x4633bd]
./miniruby[0x463499]
./miniruby[0x57647a]
./miniruby[0x585c5f]
./miniruby[0x586ccb]
./miniruby[0x5795c2]
./miniruby[0x57ff4f]
./miniruby[0x45e06a]
./miniruby(ruby_exec_node+0x1d)[0x45fa7d]
./miniruby(ruby_run_node+0x1e)[0x461cde]
./miniruby[0x4192cb]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f0b1edc01c1]
./miniruby(_start+0x2a)[0x4192fa]
======= Memory map: ========
00400000-00669000 r-xp 00000000 00:22 865631 /var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/miniruby
00869000-0086e000 r--p 00269000 00:22 865631 /var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/miniruby
0086e000-0086f000 rw-p 0026e000 00:22 865631 /var/tmp/portage/dev-lang/ruby-2.3.4-r2/work/ruby-2.3.4/miniruby
0086f000-00880000 rw-p 00000000 00:00 0
01a20000-01db3000 rw-p 00000000 00:00 0 [heap]
7f0b18000000-7f0b18021000 rw-p 00000000 00:00 0
7f0b18021000-7f0b1c000000 ---p 00000000 00:00 0
7f0b1e7e1000-7f0b1e7f7000 r-xp 00000000 08:03 7876151 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/libgcc_s.so.1
7f0b1e7f7000-7f0b1e9f6000 ---p 00016000 08:03 7876151 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/libgcc_s.so.1
7f0b1e9f6000-7f0b1e9f7000 r--p 00015000 08:03 7876151 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/libgcc_s.so.1
7f0b1e9f7000-7f0b1e9f8000 rw-p 00016000 08:03 7876151 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/libgcc_s.so.1
7f0b1e9f8000-7f0b1eda0000 r--p 00000000 08:03 7869426 /usr/lib64/locale/locale-archive
7f0b1eda0000-7f0b1ef29000 r-xp 00000000 08:03 4590444 /lib64/libc-2.24.so
7f0b1ef29000-7f0b1f129000 ---p 00189000 08:03 4590444 /lib64/libc-2.24.so
7f0b1f129000-7f0b1f12d000 r--p 00189000 08:03 4590444 /lib64/libc-2.24.so
7f0b1f12d000-7f0b1f12f000 rw-p 0018d000 08:03 4590444 /lib64/libc-2.24.so
7f0b1f12f000-7f0b1f133000 rw-p 00000000 00:00 0
7f0b1f133000-7f0b1f22b000 r-xp 00000000 08:03 4588589 /lib64/libm-2.24.so
7f0b1f22b000-7f0b1f42a000 ---p 000f8000 08:03 4588589 /lib64/libm-2.24.so
7f0b1f42a000-7f0b1f42b000 r--p 000f7000 08:03 4588589 /lib64/libm-2.24.so
7f0b1f42b000-7f0b1f42c000 rw-p 000f8000 08:03 4588589 /lib64/libm-2.24.so
7f0b1f42c000-7f0b1f434000 r-xp 00000000 08:03 4590445 /lib64/libcrypt-2.24.so
7f0b1f434000-7f0b1f634000 ---p 00008000 08:03 4590445 /lib64/libcrypt-2.24.so
7f0b1f634000-7f0b1f635000 r--p 00008000 08:03 4590445 /lib64/libcrypt-2.24.so
7f0b1f635000-7f0b1f636000 rw-p 00009000 08:03 4590445 /lib64/libcrypt-2.24.so
7f0b1f636000-7f0b1f664000 rw-p 00000000 00:00 0
7f0b1f664000-7f0b1f666000 r-xp 00000000 08:03 4590429 /lib64/libdl-2.24.so
7f0b1f666000-7f0b1f866000 ---p 00002000 08:03 4590429 /lib64/libdl-2.24.so
7f0b1f866000-7f0b1f867000 r--p 00002000 08:03 4590429 /lib64/libdl-2.24.so
7f0b1f867000-7f0b1f868000 rw-p 00003000 08:03 4590429 /lib64/libdl-2.24.so
7f0b1f868000-7f0b1f8df000 r-xp 00000000 08:03 6573335 /usr/lib64/libgmp.so.10.3.2
7f0b1f8df000-7f0b1fade000 ---p 00077000 08:03 6573335 /usr/lib64/libgmp.so.10.3.2
7f0b1fade000-7f0b1fadf000 r--p 00076000 08:03 6573335 /usr/lib64/libgmp.so.10.3.2
7f0b1fadf000-7f0b1fae0000 rw-p 00077000 08:03 6573335 /usr/lib64/libgmp.so.10.3.2
7f0b1fae0000-7f0b1faf7000 r-xp 00000000 08:03 4590452 /lib64/libpthread-2.24.so
7f0b1faf7000-7f0b1fcf6000 ---p 00017000 08:03 4590452 /lib64/libpthread-2.24.so
7f0b1fcf6000-7f0b1fcf7000 r--p 00016000 08:03 4590452 /lib64/libpthread-2.24.so
7f0b1fcf7000-7f0b1fcf8000 rw-p 00017000 08:03 4590452 /lib64/libpthread-2.24.so
7f0b1fcf8000-7f0b1fcfc000 rw-p 00000000 00:00 0
7f0b1fcfc000-7f0b1fd0f000 r-xp 00000000 08:03 6572056 /usr/lib64/libsandbox.so
7f0b1fd0f000-7f0b1ff0f000 ---p 00013000 08:03 6572056 /usr/lib64/libsandbox.so
7f0b1ff0f000-7f0b1ff10000 r--p 00013000 08:03 6572056 /usr/lib64/libsandbox.so
7f0b1ff10000-7f0b1ff11000 rw-p 00014000 08:03 6572056 /usr/lib64/libsandbox.so
7f0b1ff11000-7f0b1ff19000 rw-p 00000000 00:00 0
7f0b1ff19000-7f0b1ff3c000 r-xp 00000000 08:03 4590443 /lib64/ld-2.24.so
7f0b1ffb7000-7f0b1ffbe000 r--s 00000000 08:03 6573968 /usr/lib64/gconv/gconv-modules.cache
7f0b1ffbe000-7f0b1ffbf000 ---p 00000000 00:00 0
7f0b1ffbf000-7f0b200da000 rw-p 00000000 00:00 0
7f0b200da000-7f0b2013b000 rw-p 00000000 00:00 0
7f0b2013b000-7f0b2013c000 r--p 00022000 08:03 4590443 /lib64/ld-2.24.so
7f0b2013c000-7f0b2013d000 rw-p 00023000 08:03 4590443 /lib64/ld-2.24.so
7f0b2013d000-7f0b2013e000 rw-p 00000000 00:00 0
7ffc0e27f000-7ffc0ea7e000 rw-p 00000000 00:00 0 [stack]
7ffc0eb74000-7ffc0eb77000 r--p 00000000 00:00 0 [vvar]
7ffc0eb77000-7ffc0eb79000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
make: *** [uncommon.mk:655: enc.mk] Aborted
make: *** Waiting for unfinished jobs.... |
dmesg:
Code: | sh[11044]: segfault at 3f9e850 ip 00000000004414a0 sp 00007fffbdbd8070 error 4 in bash[400000+b1000] |
Maybe there's a hint hidden in there... |
Update:
Hurray, looks like there is another source of trouble coming along:
I was able to build the above ruby version(dev-lang/ruby-2.3.4-r2) flawlessly with gcc-6. gcc-7 always triggers the error shown. *sigh* _________________ People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect... |
|
Back to top |
|
|
trippels Tux's lil' helper
Joined: 24 Nov 2010 Posts: 137 Location: Berlin
|
Posted: Sun May 28, 2017 4:18 am Post subject: |
|
|
drizzt wrote: | ruby crashed rather nasty during emerge:
[code]./template/verconf.h.tmpl:3: [BUG] Segmentation fault at 0x00000000000000
ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-linux]
Update:
Hurray, looks like there is another source of trouble coming along:
I was able to build the above ruby version(dev-lang/ruby-2.3.4-r2) flawlessly with gcc-6. gcc-7 always triggers the error shown. *sigh* |
It is a known ruby bug (undefined behavior due to misaligned loads). This has nothing to do with Ryzen.
See: https://bugs.ruby-lang.org/issues/11831
(It also could be the following GC bug: https://bugs.ruby-lang.org/issues/13150)
Both issues are fixed in 2.4, so I would suggest to simply upgrade ruby. |
|
Back to top |
|
|
|