Dne 24. 07. 20 v 21:01 Jeff Law napsal(a): > On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote: >> The LTO break Ruby on various platforms. >> >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573 >> >> vs >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733 >> >> (Note these are my experimental builds testing single test case). > I haven't gotten a clean ruby build with or without LTO. Ruby builds just fine on x86_64 according to Koschei: https://koschei.fedoraproject.org/package/ruby? > So I haven't > investigated Ruby for any LTO specific failures. > >> >> The only difference is redhat-rpm-config 162-1.fc33 => 163-1.fc33. >> Adding `%define _lto_cflags %{nil}` helped to recover, but if it was at >> least behaving the same on all platforms :/ >> >> >> And this is Koschei failure: https://koschei.fedoraproject.org/package/ruby? >> >> Looking at the full test suite, it seems it causes some troubles to >> SIGSEV signal handler (Ruby spawns subprocess and kills it). > Does the signal handler modify any global variables? I am afraid there happens a lot of interesting stuff. This is the method responsible for printing the output which likely fails: https://github.com/ruby/ruby/blame/master/vm_dump.c#L920 But the issue might be that the signal handler itself might be somehow modified and the modification fails. This is the default signal handler: https://github.com/ruby/ruby/blob/master/signal.c#L1137 > That's been a common source > of issues I've seen. I am afraid I'll need to open some upstream ticket to help with answers to questions like this :/ Vít > > jeff _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
