some clues for the 110h4 problem?

[Torsten Scherer <itschere@TechFak.Uni-Bielefeld.DE>]

 Yeah, well, I'm not quite sure if this might help anyone, but I've tried
to track down some of *my* (say: MP) problems with mint110h4, and what
I've discovered is:

 MiNT itself can start every program from mint.cnf, including init. It does
so by calling p_exec(0).

 Init can't start /bin/sh (the MiNTOS one) for the bootup scripts, when it
tries to launch it with p_fork/p_exec(200), the child get's killed immediately
(I see from the PID that it's the child) but successfully manages to start
three gettys with p_vfork/p_exec(200). Note that the getty for the console
is started first and the others afterwards!

 When I try to log into the console, the first getty crashes after asking for
the login name. The next attempt goes through to passwd, which does *not*
crash when starting my shell, the Michael Hohmuth port of tcsh 6.0.3.

 This one can be repeated on any tty. The first getty crashes, the second
one goes through. If you log out and log in again immediately, the first
one succeeds immediately. If you log out and start any other program on any
other tty, so that the next getty will be loaded to another adress, the first
attempt on the original tty will crash again. All this looks like the code
for setting up some segment is broken, which needn't be called again if - by
pure coincidence - the segment is already in memory at the same adress, and
therefore doesn't break this time.

 Since *none* of these login tools was compiled with -mbaserel, *nor* has it
got the sticky bit set, the `remaining in memory' can only be a bug.

 The /bin/sh (*not* compiled with -mbaserel) seems to start every program -
either in background or in foreground - with p_fork/p_exec(200) and crashes
every time, even if you try to trigger the above mentioned effect and try
to start the same program repeatitively.

 The tcsh (compiled with -mbaserel, but without sticky bit) starts programs
in the foreground with p_vfork/p_exec(200) and doesn't produce any problems
then. When it tries to start a program in the background (using p_fork/
p_exec(200)) the forked child immediately crashes.

 Each time the problem is triggered by a p_fork() with a subsequent p_exec()
and each time the *child* crashes *after* it's got its PID, but *before* it's
got its name.

 That's where I'm standing now, a bit tired, at 10:30pm local time. Can there
please somebody else who's more familiar with that parts of MiNT have a
closer look at it?

 Anybody who still thinks this is a compiler bug (mine: bmgcc233p2) may feel
free to send me a -DONLY030 binary of the unmodified 110h4 code compiled with
his/her preferred compiler to test it and I promise never to mention their
names for `illegally' copying binaries of MiNT. :-)

good night,
TeSche
-- 
Torsten Scherer (TeSche, Schiller...)
Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...
| Use any of "finger itschere@129.70.131.2-15" for adresses and more.|
| Last updated: 14. April 1994.|