Jump to content

Search the Community

Showing results for tags 'crash'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Funtoo Discussion Forums
    • News and Announcements
    • General Discussion
    • Dev Central
    • Funtoo Hosting
    • Funtoo Infrastructure
  • Help Central
    • General Help
    • Installation Help
    • Portage Help
    • Desktop Help
    • Server Help
  • Funtoo Services


  • drobbins' Blog
  • It's a Bear's life
  • haxmeister's Blog
  • psychopatch's Blog
  • 666threesixes666's Blog
  • decision theory
  • Chris Kurlinski's Blog
  • Sandro's Blog
  • danielv's Blog
  • Not So Stupid Admin Tricks
  • maldoror's Blog
  • andreawilson's Blog
  • Simple Step-by-Step Server Setup
  • saraedward's Blog
  • eusanpe
  • Funtoo Perl Hackers's Perl on Funtoo

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start






First Name

Last Name



Found 1 result

  1. I investigated as to why my grub wouldn't install when it looked like the compile was OK. Now emerging GDB and also attempting to re-emerge with different CFLAGS (just -O2, removing -march=native). Taro build-pc # ./grub-mkimage --help Usage: grub-mkimage [OPTION...] [OPTION]... [MODULES] Make a bootable image of GRUB. -c, --config=FILE embed FILE as an early config Segmentation fault (core dumped) What's weird is it should just be printing some output. That shouldn't crash it unless there is a major bug. Well ... it installed. Is there some way to tell portage to change CFLAGS for a certain program? Is there an /etc/portage/package.cflags? I know the ebuilds can do it, but the ebuild isn't filtering out -march=native, which is definately breaking grub (like a bug somewhere). I'm gonna compile the broken one, just so I can gdb it. Program received signal SIGSEGV, Segmentation fault. 0x000000000041459a in memset () (gdb) bt #0 0x000000000041459a in memset () #1 0x0000000000414672 in memset () #2 0x0000000000414672 in memset () #3 0x0000000000414672 in memset () #4 0x0000000000414672 in memset () This repeats until the stack overflows ... at least 10000 times. Weird eh? I think its related to this GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 It looks like even gcc's own test suite caches the bug and yet they released it anyway :/ Only bites with -O3 when doing something like that looks like a memcopy. GCC will optimize by calling the library routine which can result in an infinite loop. In which case you can fix the source with: #pragma GCC optimize ("no-tree-loop-distribute-patterns") Or just tweak the ebuild to add "-fno-tree-loop-distribute-patterns" to the CFLAGS in the ebuild and be done with it. Yup - this fixes it! Off to file a bug. (and keeping that -fno-tree-loop-... in my global CFLAGS, who knows what other apps will silently fail - I should probably recompile EVERYTHING).
  • Create New...