Walt Mankowski via plug on 3 Jan 2022 14:58:50 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Very weird error with make (constant segfaulting)


The only person who's posted a main function is me, and that will have
absolutely no effect on make. It's not a syntax error, and if some
compiler setting flags it as a warning that's exactly the sort of
thing that make is supposed to catch.

On Mon, Jan 03, 2022 at 02:41:14PM -0800, Charles Hathaway via plug wrote:
> Small nit; there's no return on your main function. What happens if you add
> one?
> 
> Does this happen with other programs?
> 
> Charles
> 
> On Mon, Jan 3, 2022, 14:26 Mark Bergman via plug <plug@lists.phillylinux.org>
> wrote:
> 
> > In the message dated: Mon, 03 Jan 2022 09:11:29 -0500,
> > The pithy ruminations from Lynn Bradshaw via plug on
> > [[PLUG] Very weird error with make (constant segfaulting)] were:
> > => So I was about to start compiling some software project and make
> > => segfaulted. I thought it might have been a fluke, so I tried again,
> >
> > Was it truely the "make" executable that segfaulted, or was it part of
> > the compile chain called by Make (lex, yacc, gcc, ld) that segfaulted?
> >
> > Was it actually during compilation (indicating a likely hardware error
> > or corrupt tool or library), or was it after compilation, ie., if the
> > Makefile ran tests of the executable, indicating that the binaries
> > produced aren't compatible with the hardware & OS?
> >
> > => same thing, repeatedly. Tried backing out of the shell or tmux
> >
> > Repeatedly? At the same step in compilation each time? Does the problem
> > happen when compiling other software packages?
> >
> > I've seen compilation fail with very odd errors (in old versions of
> > cc/gcc) when the source code had non-ASCII characters or was corrupt.
> >
> > Get another copy of the package & be sure that the code is valid (not
> > a corrupted download, UTF-8 issue, etc).
> >
> > I'd verify the installed packages ("make" and other parts of the build
> > chain, the libraries used for compilation, etc) and possibly reinstall.
> >
> > => altogether, restarting the terminal emulator, using bash (normal
> > => choice is zsh on this one) and ultimately only restarting the entire
> > => machine fixed it.
> >
> > Changing your shell will have almost no affect on this ("almost", except
> > for unlikely instances where a interactive setting -- shell variable,
> > usually -- caused the issue, and that setting isn't enabled in a shell
> > startup file).
> >
> > =>
> > => I don't think it's dodgy hardware because a) only make has ever done
> > => this (I think it's the second or third time now) and b) the hardware
> > => in question is reasonably new and also c) the uptime that of course
> > => got wiped out was nearly three weeks. The one hardware possibility
> > => that comes to mind is that it's a Raspberry Pi (four cores, ARMv7
> > => Processor rev 3 (v7l)) and something just slipped under the radar that
> > => maybe wouldn't have if it had been an Intel or Intel-like processor.
> >
> >
> > Compilation is a pretty stressful operation -- to the point where kernel
> > compilation was often used as part of a system burn-in or acceptance
> > test. It will often expose problems in marginal RAM or CPUs, issues
> > that only appear when an component is at high temperature, or a marginal
> > powersupply (a frequent RPI issue).
> >
> > Are you using an SD card for storage? I've see with my 5 (6?) PIs that
> > the SD card is the weakest link -- with frequent corruption. I don't
> > care much, as the PIs are easily reimaged and reconfigured and I don't do
> > compilation there, but you may find that a better class of SD card helps.
> >
> > If you're using external storage (SSD via USB, for example), carefully
> > check the RPI power supply, cooling, and use a separate power source
> > for the storage device if possible.
> >
> > However, if it is a hardware problem, you can probably cause it through
> > other CPU/RAM intensive operations, and processes other than just "make"
> > are likely to show faults as well.
> >
> >
> > --
> > Mark Bergman    Biker, Rock Climber, SCUBA Diver, Unix mechanic, IATSE #1
> > Stagehand
> > '94 Yamaha GTS1000A^1                                         2015 Aprilia
> > Caponord
> >                         https://www.flickr.com/photos/rmsppu
> >
> > ___________________________________________________________________________
> > Philadelphia Linux Users Group         --
> > http://www.phillylinux.org
> > Announcements -
> > http://lists.phillylinux.org/mailman/listinfo/plug-announce
> > General Discussion  --
> > http://lists.phillylinux.org/mailman/listinfo/plug
> >

> ___________________________________________________________________________
> Philadelphia Linux Users Group         --        http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug

Attachment: signature.asc
Description: PGP signature

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug