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

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