Conference tallis::alpha_migration_tools

961.0. "Program unexpectedly exits after write() data: "mumble...quit...."" by PEACHS::LAMPERT (Pat Lampert, UNIX Applications Support, 343-1050) Fri Mar 28 1997 13:55

This problem relates to Steve Sheppard'd note in 953.
Steve no longer works for Digital so I now have the
call.

The customer is a secure site so he is reluctant to 
send me any actual images. All I have right now is 
a fax containing the verbose=10 output from mxr. 

My take is that we will need more information, probably
the image itself to figure out what is wrong here. Is that
so?

I have included the tail end of the fax here. The
customer insists that the write() statement containing
the string "quit" is related to the unexpected shutdown
of the application.

Here is a comment from the customer.I will follow up
with the last 20 or so lines from the log.

"The attached output is teh reult of a run of a program
modified thru the use of mx to run on OSF.
It currently is running fine on ultrix 4.4. During the
migration (or execution of mx) no errors are output.
This program called (msgdetail) validates the type of 
file being pulled from a previous program. It
then copies it into your home directory where it then 
begins parsing the data it has retrieved to a GUI 
interace.

The program is dying somewhere shortly after it copies
the file into your home directory. The GUI window never
appears, and no information is passed back to the
command line from which the application is launched.
It acts as though it is exiting gracefully, but it 
shouldnt. I know this is very vague, but without the 
source it is difficult to identity which line of source
code it is choking on. If there are questions I can put 
before the developer or further tests you would recomend,
please contact me.


----------------------------------------------


.
.
MXR: CONV_NAME ioctl returns 0
MXR: ioctl returning success: 0 (0x0)
	ioctl() returns 0x0 at 7:23:20.837408
SYSCALL: PID 0x4ca8, time 7:23:20.838384
	read(0x4, 0c79fe5f8, 0c40) from 0c87a64c, stack is 7f9fe578
	read() returns 0x040 at 7:23:20.838384
	>> read data: ....,...)...(...........|.d........;...)...(...........|.d...
SYSCALL: PID 0x4ca8, time 7:23:20.838384,
	write(0x4, 0x10041a70, 0xdc) from 0x87a6c, stack is 7f9ff100
	>>write data: F...(.......t.Y.....J...(.......v.h...Quit..F..(.......p.U.'.
	write() returns 0xdx at 7:23:20.839360
SYSCALL: PID 0x4ca8, time 7:23:20:910608,
	close(0x0) from 0x87a83c, stack is 7f9ff050
	close() returns 0x0 at 7:23:20.910608
SYSCALL: PID 0x4ca8, time 7:23:20:911584,
	close(0x1) from 0x87a83c, stack is 7f9ff050
	close() returns 0x0 at 7:23:20.911584
SYSCALL: PID 0x4ca8, time 7:23:20:912560,
	close(0x2) from 0x87a83c, stack is 7f9ff050
	close() returns 0x0 at 7:23:20.912560
SYSCALL: PID 0x4ca8, time 7:23:20:912560,
	exit(0x0) from 0x87d61c, stack is 7f9ff0c0
	MXR ULTRIX syscall summary:
	.
	.
	.

    
    
    From the logfile, it appears that the executable is exiting
    cleanly.  The most likely cause (assuming that the customer
    is running the most up to date bits of mx/mxr - see note 4.34)
    is that there is simply some data/configuration file which
    needs to be copied over.  Have them do a run with:
            setenv MXR_TRACE_SYSCALLS open,stat,access
    
    And look to see what files are not found.  Or, if all of the
    files _are_ found, look to see if any of the files being
    accessed are system files with formats that differ between
    Digital UNIX and Ultrix.  Things like files in /etc /var
    and such may have incompatable formats, so using a translator
    won't solve the problems.
    
    Getting mxr up to date is key - older versions had problems
    with the getmnt() system call on local AdvFS filesystems.  One
    user mode call that uses getmnt() under Ultrix 4.4 is getwd().
    
    	Rick