Re: stack smashing detected
On 1/30/23 8:05 PM, Michael Schmitz wrote:
> ...
> Am 30.01.2023 um 17:00 schrieb Stan Johnson:
>> Hello,
>>
>> 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.
>
> Once the offending binary is known (and the crash can be reproduced
> after system boot), gdb can be used to find the function that overwrote
> its local stack guard.
Is there a way to configure the kernel to use the stack guard for every
function, and then log every resulting abort? I realize that that would
be very slow, but it might also be useful for debugging.
>
> That's a lot of work on a 030 Mac - have you tried to reproduce this on
> any kind of emulator?
I haven't seen the error in QEMU.
>
> I suppose one difference between your 030 and 040 Macs might be the
> amount of RAM available. I wonder if this bug results from a combination
> of 030 MMU and memory pressure, or 030 MMU only.
For some reason, the error seems to happen only with 68030 systems,
regardless of processor speed or memory:
PB 170 : 68030, 25 MHz, 8 MiB, external SCSI2SD
Mac IIci : 68030, 25 MHz, 80 MiB, internal SCSI2SD
SE/30 : 68030, 16 MHz, 128 MiB, external SCSI2SD
PB 550c : 68040, 33 MHz, 36 MiB, external SCSI2SD
Centris 650 : 68040, 25 MHz, 136 MiB, internal SCSI2SD
-Stan
Reply to: