Hi Michael et al,
On Wed, Feb 1, 2023 at 7:52 PM Michael Schmitz <schmitz...@gmail.com> wrote:
> On 2/02/23 05:38, Stan Johnson wrote:
> > On 1/30/23 8:05 PM, Michael Schmitz wrote:
> >> ...
> >> Am 30.01.2023 um 17:00 schrieb Stan Johnson:
> >>> I am seeing anywhere from zero to four of the following errors while
> >>> booting Linux on 68030 systems and using sysvinit startup scripts:
> >>>
> >>> *** stack smashing detected ***: terminated
> >>> Aborted
> >>>
> >>> I usually (but not always) see three of the errors while init is running
> >>> the rcS.d scripts, and one while running the rc2.d scripts. The stack
> >>> smashing messages appear only on the system console (nothing is logged
> >>> in an error log or dmesg). Despite the errors, the system continues
> >>> booting to multiuser mode without any obvious additional problems. I
> >>> haven't tested systemd, which is too slow to be useful on my m68k
> >>> systems (though I have a Debian SID with systemd that I can restore for
> >>> testing if necessary).
> >>>
> >>> ...
> >> Another way may be logging the start of each of the rcS.d or rc2.d
> >> scripts until you know what scripts to look at in more detail, then
> >> adding 'set -v' at the start of those to log every command in the
> >> offending script.
> > Hi Michael,
> >
> > Thanks for your reply.
> >
> > After logging the start and end of each script, I see that the "stack
> > smashing detected" error often happens while running
> > "/etc/rcS.d/S01mountkernfs.sh" (/etc/init.d/mountkernfs.sh). I'll try to
> > isolate it to a particular command.
> >
> > This may be a coincidence, but the error seems to happen (up to about 4
> > times) after a warm boot into Mac OS 7.5.5 and a subsequent boot into
> > Linux that when starting with a cold boot into Mac OS 7.5.5, but it
> > doesn't seem that that should make any difference for Linux. This
> > morning, after a cold boot, I saw two of the errors, while after a warm
> > boot, I saw four.
> Hmm - that might well indicate a hardware issue rather than software.
> Bits flipping at random in RAM (and getting picked up because the stack
> canary changes).
You can enable extra debugging options in the kernel, which might help
detecting memory corruption, like CONFIG_DEBUG_LIST and DEBUG_SLAB.
It will slow down your kernel, and make it grow too large, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
