On Wed, Jan 17, 2001 at 10:00:43PM -0500, Neal H Walfield wrote:
> On Wed, Jan 17, 2001 at 06:21:40PM -0500, Roland McGrath wrote:
> > I don't see anything obviously wrong (other than your spelling of "semantics").
>
> Do you think it might be an error elsewhere, e.g. in gdb or the proc
> server?
Here is (hopefully) a clearer presentation of the problem.
After adding the aforementioned code to a clean tree, translators fail
to retreive their port to the proc server if one attaches to the
translator with gdb _during_ the pause.
Here are the different scenarios:
* Just settrans it works fine:
tty1 (0)$ settrans -acfg fs /hurd/ext2fs part/7
tty1 (0)$ ls fs
lost+found
* The same goes if one attaches gdb later:
tty1 (0)$ settrans -acfg fs /hurd/ext2fs part/7
tty1 (0)$ ls fs
lost+found
tty2 (0)$ gdb /hurd/diskpart 808
GNU gdb 5.0
...
[Switching to thread 808.1]
(gdb) c
Continuing.
tty1 (0)$ ls fs
lost+found
* If one pauses yet does not attach gdb, all still goes well:
tty1 (0)$ settrans -acfgP fs /hurd/ext2fs part/7
Translator pid: 845
Pausing...
tty1 (0)$ ls fs
lost+found
* Pausing and attaching gdb after hitting enter is also fine:
tty2 (0)$ gdb /hurd/ext2fs 845
GNU gdb 5.0
...
(gdb) c
Continuing.
tty1 (0)$ ls fs
lost+found
* However, if fails when attaching during the pause:
tty1 (0)$ settrans -acfgP fs /hurd/ext2fs part/7
Translator pid: 851
Pausing...
tty2 (0)$ gdb /hurd/ext2fs 851
GNU gdb 5.0
...
(gdb)
Now, hitting enter at the prompt followed by continuing in gdb:
(gdb) c
Continuing.
from gdb:
warning: Pid 851 died with unknown exit status, using SIGKILL.
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
And from termianl 1:
tty1 (0)$ Translator startup failure: fsys_startup: (ipc/send)
invalid destination port
* It also dies if one connects gdb and continues before hitting enter;
This has slightly different output:
tty1 (0)$ settrans -acfgP fs /hurd/ext2fs part/7
Translator pid: 876
Pausing...
tty2 (0)$ gdb /hurd/ext2fs 851
GNU gdb 5.0
...
(gdb) c
Continuing.
Back to terminal 1 and hit enter:
ext2fs: ../../project/hurd/hurd-build/libdiskfs/init-startup.c:178:
_diskfs_init_completed: Assertion `proc' failed.
Taking a look at init-startup.c shows the following:
/* This is called when we have an ordinary environment, complete
with proc and auth ports. */
void
_diskfs_init_completed ()
{
/* Some variables followed by the first lines of code: */
/* Contact the startup server and register our shutdown request.
If we get an error, print an informational message. */
proc = getproc ();
assert (proc); <-- Line 178
...
Which was called by either diskfs_S_fsys_init (boot-start.c) or
diskfs_startup_diskfs (init-startup.c).
Attaching to settrans during the pause shows that it is waiting for
a key:
(gdb) up
#8 0x8048ca9 in open_node (flags=0, underlying=0x11dfcd0,
underlying_type=0x11dfca8, task=62, cookie=0x0) at
/include/stdio.h:545
545 return __getc (stdin);
Breaking at the next line and hitting enter shows that everything
here is (relatively) sane:
(gdb) n
Cannot find bounds of current function
(gdb) b 184
Breakpoint 1 at 0x8048c85: file /include/stdio.h, line 184.
(gdb) b settrans.c:184
Breakpoint 2 at 0x8048cac: file
../../project/hurd/hurd-build/utils/settrans.c, line 184.
(gdb) c
Continuing.
warning: Can't wait for pid 897: No child processes
Breakpoint 2, open_node (flags=0, underlying=0x11dfcd0,
underlying_type=0x11dfca8, task=62, cookie=0x0)
at ../../project/hurd/hurd-build/utils/settrans.c:184
184 node = file_name_lookup (node_name, flags |
lookup_flags, 0666);
(gdb) n
185 if (node == MACH_PORT_NULL)
(gdb)
191 *underlying = node;
(gdb)
192 *underlying_type = MACH_MSG_TYPE_COPY_SEND;
(gdb)
194 return 0;
(gdb)
service_fsys_startup (underlying_open_fn=0x11dfe4c, cookie=0x0, port=61,
timeout=60000, control=0x11dfe48, task=62)
at ../../project/hurd/hurd-build/libfshelp/start-translator-long.c:152
152 reply.realnodeType = realnodeType;
(gdb) c
Continuing.
warning: Pid 897 died with unknown exit status, using SIGKILL.
That is all for now.
PGP signature
