[gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale <rdalek1967@gmail.com>]

Dale wrote:
> Howdy,
>
> I was trying to re-emerge some packages.  The ones I was working on
> failed with "internal compiler error: Segmentation fault" or similar
> being the common reason for failing.  I did get gcc to compile and
> install.  But other packages are failing, but some are compiling just
> fine.  Here's a partial list at least. 
>
> net-libs/webkit-gtk
> kde-plasma/kpipewire
> sys-devel/clang
> sys-devel/llvm
>
>
> When I couldn't get a couple to complete. I just went to my chroot and
> started a emerge -e world.  Then the packages above started failing as
> well in the chroot.  This all started when gkrellm would not open due to
> a missing module.  Some info on gcc.
>
>
> root@Gentoo-1 / # gcc-config -l
>  [1] x86_64-pc-linux-gnu-13 *
> root@Gentoo-1 / #
>
>
> Output of one failed package.
>
>
> In file included from
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2/Source/WebCore/platform/graphics/GraphicsLayer.h:46,
>                  from
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2/Source/WebCore/platform/graphics/GraphicsLayerContentsDisplayDelegate.h:28,
>                  from
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2/Source/WebCore/html/canvas/CanvasRenderingContext.h:29,
>                  from
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2/Source/WebCore/html/canvas/GPUBasedCanvasRenderingContext.h:29,
>                  from
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2/Source/WebCore/html/canvas/WebGLRenderingContextBase.h:33,
>                  from
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2/Source/WebCore/html/canvas/WebGLStencilTexturing.h:29,
>                  from
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2/Source/WebCore/html/canvas/WebGLStencilTexturing.cpp:29,
>                  from
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2_build/WebCore/DerivedSources/unified-sources/UnifiedSource-950a39b6-33.cpp:1:
> /var/tmp/portage/net-libs/webkit-gtk-2.44.2/work/webkitgtk-2.44.2/Source/WebCore/platform/ScrollableArea.h:96:153:
> internal compiler error: in layout_decl, at stor-layout.cc:642
>    96 |     virtual bool requestScrollToPosition(const ScrollPosition&,
> const ScrollPositionChangeOptions& =
> ScrollPositionChangeOptions::createProgrammatic()) { return false; }
>      
> |                                                                                                                                                        
> ^
> 0x1d56132 internal_error(char const*, ...)
>         ???:0
> 0x6dd3d1 fancy_abort(char const*, int, char const*)
>         ???:0
> 0x769dc4 start_preparsed_function(tree_node*, tree_node*, int)
>         ???:0
> 0x85cd68 c_parse_file()
>         ???:0
> 0x955f41 c_common_parse_file()
>         ???:0
>
>
> And another package:
>
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/tuple: In
> instantiation of ‘constexpr std::__tuple_element_t<__i,
> std::tuple<_UTypes ...> >& std::get(const tuple<_UTypes ...>&) [with
> long unsigned int __i = 0; _Elements =
> {clang::CodeGen::CoverageMappingModuleGen*,
> default_delete<clang::CodeGen::CoverageMappingModuleGen>};
> __tuple_element_t<__i, tuple<_UTypes ...> > =
> clang::CodeGen::CoverageMappingModuleGen*]’:
> /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/unique_ptr.h:199:62:  
> required from ‘std::__uniq_ptr_impl<_Tp, _Dp>::pointer
> std::__uniq_ptr_impl<_Tp, _Dp>::_M_ptr() const [with _Tp =
> clang::CodeGen::CoverageMappingModuleGen; _Dp =
> std::default_delete<clang::CodeGen::CoverageMappingModuleGen>; pointer =
> clang::CodeGen::CoverageMappingModuleGen*]’
> /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/unique_ptr.h:470:27:  
> required from ‘std::unique_ptr<_Tp, _Dp>::pointer std::unique_ptr<_Tp,
> _Dp>::get() const [with _Tp = clang::CodeGen::CoverageMappingModuleGen;
> _Dp = std::default_delete<clang::CodeGen::CoverageMappingModuleGen>;
> pointer = clang::CodeGen::CoverageMappingModuleGen*]’
> /var/tmp/portage/sys-devel/clang-16.0.6/work/clang/lib/CodeGen/CodeGenModule.h:668:31:  
> required from here
> /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/tuple:1810:43:
> internal compiler error: Segmentation fault
>  1810 |     { return std::__get_helper<__i>(__t); }
>       |                                           ^
> 0x1d56132 internal_error(char const*, ...)
>         ???:0
> 0x9816d6 ggc_set_mark(void const*)
>         ???:0
> 0x8cc377 gt_ggc_mx_lang_tree_node(void*)
>         ???:0
> 0x8cccfc gt_ggc_mx_lang_tree_node(void*)
>         ???:0
> 0x8ccddf gt_ggc_mx_lang_tree_node(void*)
>         ???:0
> 0x8ccda1 gt_ggc_mx_lang_tree_node(void*)
>         ???:0
>
>
> As you can tell, compiler error is a common theme.  All of them I looked
> at seem to be very similar to that.  I think there is a theme and likely
> common cause of the error but no idea where to start. 
>
> Anyone have any ideas on what is causing this?  Searches reveal
> everything from bad kernel, bad gcc, bad hardware and such.  They may as
> well throw in a bad mouse while at it.  LOL  A couple seemed to solve
> this by upgrading to a newer version of gcc.  Thing is, I think this is
> supposed to be a stable version of gcc. 
>
> Open to ideas.  I hope I don't have to move back to the old rig while
> sorting this out.  O_O  Oh, I updated my old rig this past weekend.  Not
> a single problem on it.  Everything updated just fine. 
>
> Thanks.
>
> Dale
>
> :-)  :-) 
>


Here's a update.  I got the replacement memory sticks today.  Usually I
do my trip to town on Thursday morning but given there is a storm coming
my way, again, I went today.  So, before I left I installed all 4 sticks
of memory, booted my awesome Ventoy USB stick and then ran memtest while
I was gone.  When I got back from town, I had a banner that said PASS on
my screen.  It was part way through a second test.  I was gone a while. 
Doctor for about 30 minutes, Walmart for a while, Subway shop to get
something for supper a couple nights plus getting from place to place,
loading groceries etc etc.  Also, it rained on me too.  :/ 

I went into the BIOS.  On the first screen that pops up, it showed all
the memory with the same speed etc.  Now I admit, I didn't go into the
advanced stuff.  It is all set to the default from looking at it during
the initial build tho.  But, it doesn't seem any slower.  If anything,
it seems faster now.  When I open Firefox or Seamonkey, it pops up
faster than before.  Not a lot but noticeable.  I may just be lucky.  o_O 

I also noticed, the replacement sticks are only one digit apart on the
serial number.  So, they pick two from the line, test them I'd guess and
then box them up as a matched set.  It makes sense.  Two coming off the
line back to back should be as identical as it can get without extensive
testing.  Honestly tho, it is amazing given the number of components on
these chips that they work at all. 

So, I now have 128GBs of memory.  I should be able to compile some stuff
for a while now without running out of memory.  :-D

Dale

:-)  :-)