[comp.os.minix] Bug in ST-kernel 1.5.10.4

Frank Breure <breure%ITIHP1.TNO.NL@pucc.princeton.edu> (06/12/91)

I discovered a bug in the Atari ST kernel 1.5.10.4 which causes the systems
to crash with a "Kernel panic, Trap via vector 2" message when it is
compiled with C68.

It is in the new file dmp.c, I was pointed to this file by Keith Walker
(thanks !), and yesterday I discovered the problem:
It is the function "set_name", which was in stdmp.c and now is in dmp.c,
the new function has one more parameter but is still called with the old
number of parameters in "system.c".
So the 1.5.10.4 files have the following use of set_name():
proto.h:
_PROTOTYPE( void set_name, (int source_nr, int proc_nr, char *ptr));
system.c:
set_name(m_ptr->PROC1, (char *)sp);     /* save command string for F1 display */
set_name(proc_nr, (char *) 0);  /* disable command printing for F1 */
dmp.c:
PUBLIC void set_name(source_nr, proc_nr, ptr)

While the 1.5.10.3 version was defined as:
stdmp.c:
PUBLIC void set_name(proc_nr, ptr)

I edited the new version of set_name to look more like the old one and was able
to get a running system with  C68, although the process table dump (alt-shift-F1
doesn't show the commands names).

The unmodified 1.5.10.4 kernel with ACK doesn't show the process names too (but
ps does !!).

I guess we wave to choose if we modify the calls to set_name() (in system.c)
or it's definition (in dmp.c).

--
Frank Breure                                    (breure@itihp1.tno.nl)
TNO Institute of Applied Computer Science       Delft, The Netherlands
----------------------------------------------------------------------
My opinions may be subject to change without notice.

adamd@rhi.hi.is (Adam David) (06/15/91)

In <56110@nigel.ee.udel.edu> breure%ITIHP1.TNO.NL@pucc.princeton.edu (Frank Breure) writes:

>It is the function "set_name", which was in stdmp.c and now is in dmp.c,
>the new function has one more parameter but is still called with the old
>number of parameters in "system.c".

Thanks for pointing this out, Frank. This must be the reason that CTRL-ALT-F1
no longer finds the process name.

>proto.h:
>_PROTOTYPE( void set_name, (int source_nr, int proc_nr, char *ptr));
                                 ^^^^^^^^^
Can anyone tell us what this extra parameter is for. The change is not very
well documented as to what its purpose is.

>system.c:
>set_name(m_ptr->PROC1, (char *)sp);     /* save command string for F1 display */
>set_name(proc_nr, (char *) 0);  /* disable command printing for F1 */

Obviously a suitable value for source_nr needs to be added to the left of the
parameter list in these function calls. It seems to me that simply duplicating
the first parameter here will fix this kernel bug quite adequately and display
the names correctly. I haven't had a chance to check it yet though.

set_name is called elsewhere with different values for source_nr and proc_nr
so it is not an acceptable solution to remove source_nr from the function
definition.

--
Adam David.
(adamd@rhi.hi.is)

philip@cs.vu.nl (Philip Homburg) (06/17/91)

In article <3252@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes:
%>proto.h:
%>_PROTOTYPE( void set_name, (int source_nr, int proc_nr, char *ptr));
%                                 ^^^^^^^^^
%Can anyone tell us what this extra parameter is for. The change is not very
%well documented as to what its purpose is.
%
%>system.c:
%>set_name(m_ptr->PROC1, (char *)sp);     /* save command string for F1 display */
%>set_name(proc_nr, (char *) 0);  /* disable command printing for F1 */
%
%Obviously a suitable value for source_nr needs to be added to the left of the
%parameter list in these function calls. It seems to me that simply duplicating
%the first parameter here will fix this kernel bug quite adequately and display
%the names correctly. I haven't had a chance to check it yet though.
%
%set_name is called elsewhere with different values for source_nr and proc_nr
%so it is not an acceptable solution to remove source_nr from the function
%definition.

The the semantics of set_name are changed. It used to record a pointer to
the program name in the address space of the process. This caused problems
with forks and it might not be the true name of the executable. In the
new version of set_name, the name of the executable is copied and stored
in the kernel. But that name comes from the address space of MM so
set_name(source, proc, ptr) means that the name for process proc is stored
at location ptr in process source.





						Philip