conrad@CGL.UCSF.EDU (Conrad Huang) (09/06/86)
I've been trying to port ex/vi from 4.3BSD Unix to 4.3VMS (with VAX C V2.0-003) for the past two weeks. Ex/vi is a Unix editor written entirely in C. One of the problems that I ran into while porting it was getting access violations at strange places. Ex/vi uses sbrk() and brk() exclusively for memory management (there is no reference anywhere to malloc(), free(), etc). It also uses two files for temporary storage. The sequence of event that lead up to the access violation is as follows: open(temp_file_1) sbrk(xxx); end1 = sbrk(0); ... lots of processing ... open(temp_file_2) ... more processing with I/O to temp_file_2... end2 = sbrk(yyy); ... copy data to "end1" -> ACCESS VIOLATION VIRTUAL ADDRESS = end1 If I do not use temp_file_2 (delete the open and I/O), then I do *not* get the access violation. I suspect the problem is that opening the second file somehow allocates memory starting at "end1" and makes it somehow outside the legal addressing space. Would anyone who knows about VAX C innards please let me know whether this is correct? I'm completely baffled as to how to fix this problem and would greatly appreciate any pointers. Thanks, Conrad PS I've moved the second "open" call around in the code. It doesn't matter where it appears. As long as the second "open" is present, the program bombs out with an ACCESS VIOLATION sooner or later.
nunn@NBS-VMS.ARPA ("NUNN, JOHN C.") (09/06/86)
Conrad, Provided 4.3BSD ex/vi hasn't changed much from ex/vi of 4.2BSD, you shouldn't have a problem with sbrk/brk. The problem I discovered, in porting ex/vi to vms, was a bug in VAX C V2.0. Ex/vi tries to open files and assumes that if it fails (file does not exist) that the file-descriptor will be available on the next successful open. This is normally the case in the UNIX environment. However, the VAX C OPEN fails to free the file-descriptor. Ex/vi, assuming that the file-descriptor value (I think it was 0) is assigned to an open file, tries to read on the failed file-descriptor. John <nunn@nbs-vms.arpa> ------
LEICHTER-JERRY@YALE.ARPA (09/13/86)
[The original message discussed a problem in porting ex/vi to VAX C V2.0 in which open's lead to access violations. John Nunn reported a V2.0 bug that had to do with VAX C not properly freeing up file descriptors when an open failed.] If the problem John reported is not the cause, here is another thing to look at: Some programs that use sbrk() for storage management assume that they will get contiguous memory: That is, that no one else is changing the program "break address". In VMS, this is NOT a good assumption: RMS will allocate buffers in user space when you open files. It puts them at the top of your virtual address space, extending that space. (Effectively, it calls sbrk().) The best approach is to re-code the program to avoid this assumption; you'll end up with a much more maintainable, modular piece of code. However, there IS a workaround: RMS tries to avoid using buffers in P0 space, where the program code and data live; storage for buffers and other RMS stuff is allocated in P1 space (where the stack lives; RMS reserves stuff "above" the stack) and uses it until it runs out. You can control the amount of space set aside in P1 space with the linker IOSEGMENT option (see the documentation of the options file in the linker manual). The IOSEGMENT option also allows you to specify NOP0BUFS, which forbids RMS from using any P0 space for buffers; then, if the pre-allocated P1 space runs out, RMS will report an error. -- Jerry -------