rpctrace is lousing up the auth_makeauth RPC (msgid 25001) arguments. I
bet it is not doing the right thing for the empty array that is the first
argument. Can you look into this? Set a bkpt in trace_and_forward when
inp->msgh_id==25001, and examine the message at INP, then do "finish"
and exam
Roland McGrath <[EMAIL PROTECTED]> writes:
> It would be helpful to see all the output rpctrace gives when it is lousing
> things up.
Here it is. I got it using some cut'n'paste via emacs and xterm, hope
it isn't too screwed up. Strings like "^?ELF^A^A^A" in the output
were actual control charac
It would be helpful to see all the output rpctrace gives when it is lousing
things up.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
This is a complete test program for the rpctrace problem.
8<
#include
#include
#include
#include
#include
int
main(int argc, char **argv)
{
if (access("/bin/ls", X_OK) < 0)
{
printf("/bin/ls not executable, according to access: %s\n",
strerror(errno));
Ok, now I've tried some more, using rpctrace.
But I think I have a new problem. The program behaves differently when
run under rpctrace than on it's own. The code contains a loop
for (i = *index; system_sources[i].path; )
{
if (access(system_sources[i].path, X_OK) < 0)
{
Try attaching gdb to the evil process and see if you can get something
useful from a back-trace or set some break points here and there to
see where it fails.
--
Alfred M. Szmidt
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman
I've experienced a few more or less reproducible hangs on Neal's Hurd
box (dryden).
One example: I telnet in to the box. Start screen. Start emacs. Type
M-x man RET non-existing-command RET.
Then emacs displays a message saying that the man page can't be found,
and then I lose contact with both