Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Segfaults during compilation on AMD Ryzen.
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 9, 10, 11  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54098
Location: 56N 3W

PostPosted: Fri May 26, 2017 1:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
drizzt
Guru
Guru


Joined: 21 Jul 2002
Posts: 428

PostPosted: Fri May 26, 2017 1:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Fri May 26, 2017 2:00 pm    Post subject: Reply with quote

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
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54098
Location: 56N 3W

PostPosted: Fri May 26, 2017 2:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Fri May 26, 2017 2:26 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Naib,

I'm aware :)

I suspect many readers here are not.
oh I know you know :wink:


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
View user's profile Send private message
likewhoa
l33t
l33t


Joined: 04 Oct 2006
Posts: 778
Location: Brooklyn, New York

PostPosted: Fri May 26, 2017 8:07 pm    Post subject: Reply with quote

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 :evil:
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
View user's profile Send private message
nitm
n00b
n00b


Joined: 27 Dec 2004
Posts: 63

PostPosted: Sat May 27, 2017 8:39 am    Post subject: Reply with quote

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
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Sat May 27, 2017 9:03 am    Post subject: Reply with quote

[quote="likewhoa"]
Naib wrote:

On hardened-sources so limited to 4.9.x :evil:
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
View user's profile Send private message
frinnst
n00b
n00b


Joined: 27 May 2017
Posts: 5

PostPosted: Sat May 27, 2017 10:33 am    Post subject: Reply with quote

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
View user's profile Send private message
nitm
n00b
n00b


Joined: 27 Dec 2004
Posts: 63

PostPosted: Sat May 27, 2017 11:06 am    Post subject: Reply with quote

@frinnst: What RAM are you using? What frequency and timings have you set?
Back to top
View user's profile Send private message
frinnst
n00b
n00b


Joined: 27 May 2017
Posts: 5

PostPosted: Sat May 27, 2017 12:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
frinnst
n00b
n00b


Joined: 27 May 2017
Posts: 5

PostPosted: Sat May 27, 2017 12:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
drizzt
Guru
Guru


Joined: 21 Jul 2002
Posts: 428

PostPosted: Sat May 27, 2017 12:50 pm    Post subject: Reply with quote

[quote="Naib"]
likewhoa wrote:
Naib wrote:

On hardened-sources so limited to 4.9.x :evil:
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 :evil:
_________________
People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect...
Back to top
View user's profile Send private message
dryatu
n00b
n00b


Joined: 26 May 2017
Posts: 2

PostPosted: Sat May 27, 2017 12:52 pm    Post subject: Reply with quote

[quote="Naib"]
likewhoa wrote:
Naib wrote:

On hardened-sources so limited to 4.9.x :evil:
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
View user's profile Send private message
nitm
n00b
n00b


Joined: 27 Dec 2004
Posts: 63

PostPosted: Sat May 27, 2017 2:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
frinnst
n00b
n00b


Joined: 27 May 2017
Posts: 5

PostPosted: Sat May 27, 2017 3:19 pm    Post subject: Reply with quote

[/quote]
Can you show the line for this event in the dmseg log?[/quote]

It's a userspace segfault, not kernel.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Sat May 27, 2017 3:32 pm    Post subject: Reply with quote

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
View user's profile Send private message
frinnst
n00b
n00b


Joined: 27 May 2017
Posts: 5

PostPosted: Sat May 27, 2017 4:00 pm    Post subject: Reply with quote

Nothing there. besides, the output was not very interesting I dont have any logs saved
Back to top
View user's profile Send private message
bgamari
n00b
n00b


Joined: 11 Apr 2017
Posts: 9

PostPosted: Sat May 27, 2017 6:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
trippels
Tux's lil' helper
Tux's lil' helper


Joined: 24 Nov 2010
Posts: 137
Location: Berlin

PostPosted: Sat May 27, 2017 6:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
trippels
Tux's lil' helper
Tux's lil' helper


Joined: 24 Nov 2010
Posts: 137
Location: Berlin

PostPosted: Sat May 27, 2017 6:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
nitm
n00b
n00b


Joined: 27 Dec 2004
Posts: 63

PostPosted: Sat May 27, 2017 6:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
drizzt
Guru
Guru


Joined: 21 Jul 2002
Posts: 428

PostPosted: Sat May 27, 2017 6:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
drizzt
Guru
Guru


Joined: 21 Jul 2002
Posts: 428

PostPosted: Sat May 27, 2017 10:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
trippels
Tux's lil' helper
Tux's lil' helper


Joined: 24 Nov 2010
Posts: 137
Location: Berlin

PostPosted: Sun May 28, 2017 4:18 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 9, 10, 11  Next
Page 6 of 11

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum