***
CHARACTER W*1
DIMENSION IR(1319), IC(1319)
CALL SCREEN (6)
OPEN (1,FILE='FLOWER.DAT')
DO I=1,1319
READ (1,021,END=035) IR(I),IC(I)
021 FORMAT (I3,I3)
END DO
035 CLOSE(1)
DO J=1,1319
CALL PIXEL (1,IR(J),IC(J)) ; Reading pixel data from the input data file
END DO
READ (*,'(A)') W
CALL SCREEN (3) ; This assembly routine changing text mode to graphics mode
END
**************************
How to solve Input/Output error in GFortran using NetBeans IDE 7.4 Version?
Run time errors given below:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x6f8aecb4
#1 0x6f89d642
#2 0x401138
read from master failed
: Input/output error
RUN FAILED (exit value 1, total time: 819ms)
FLOWER.DAT file opened in Plain text mode.
Are there any modifications required?
If modifications are required let me know how to modify which file.
screen.s, pixel.s files are assembly routines.
Related
I have a code uno.f90 that saves the numbers from 1 to 100 in out_1.txt, and I have a second code dos.f90 which saves the square of each number in out_2.txt. It fulfills its objective, but when running the file I get the following message in the terminal:
At line 13 of file dos.f90 (unit = 33, file = 'out_1.txt')
Fortran runtime error: End of file
*Termination error. back trace:*
#0 0x7fdbe6dab32a
#1 0x7fdbe6dabed5
#2 0x7fdbe6dac69d
#3 0x7fdbe6f22ca3
#4 0x7fdbe6f1bc44
#5 0x7fdbe6f1d379
#6 0x555ca8109ad4
#7 0x555ca8109b9e
#8 0x7fdbe69c0bf6
#9 0x555ca8109879
#10 0xffffffffffffffff
this happens when I run dos.f90 using the following sequence:
gfortran -o dos dos.f90
./dos
The Fortran code is
program two
!integer,dimension(100) :: i(1)
integer::i
open(unit=33,file='out_1.txt',status='unknown',action='read')
open(unit=35,file='out_2.txt',status='new',action='write')
do
read(33,*)i
write(35,*,IOSTAT=ios)i**2
enddo
close(33)
close(35)
end program two
and uno.f90 is
program one
open(unit=33, file='out_1.txt', status='new')
do i=1,100
write(33,*,iostat=ios) i
enddo
close(33)
end program one
I would like to be able to correct the error indicated in the terminal because, although the objective comes out, the terminal exits with said error warning.
In your loop
do
read(33,*)i
write(35,*,IOSTAT=ios)i**2
enddo
you have no loop termination condition, so the loop will keep going forever, or until it is stopped unexpectedly. In this case, it stops unexpectedly when the program gets to the end of the file.
The best way of terminating the loop is to check when you are at the end of the file, using the iostat flag in the read statement just like you've used it in the write statement, e.g.
integer :: ios
do
read(33,*,iostat=ios)i
if (ios<0) then
exit
endif
write(35,*,iostat=ios)i**2
enddo
Note also that in your code the variable ios is not explicitly declared, but gets implicitly declared because you are not using implicit none. You should really use implicit none and declare ios explicitly, otherwise you are going to miss a lot of bugs in the future.
I have two programs: one (program1) writes to a file continuously, and I want the other program (program2) to read the file continuously. What is happening is that my second program is only reading up to the data point which was written when the second code was executed and stops instead of continuously reading.
Is there any way to achieve the thing?
Basically, I want the output of program1 to be used as the input of program2. Is there any way to read and write in RAM instead of file as disk read costs more time.
Code 2:
#include <stdio.h>
int main(){
FILE *fptr;
fptr = fopen("gbbct1.seq","r");
char c;
c = fgetc(fptr);
while (c != EOF){
printf("%c", c);
c = fgetc(fptr);
}
}
I am looking for platform independent approach. If that's not possible, I would like to know for Linux platform. I don't need to preserve the data once read. I don't want to block program1.
The most basic version of your code needs to reset the file stream status when it encounters EOF and then sleep for a while. For example, assuming POSIX and using only the simplest (most ubiquitous) functions:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
const char filename[] = "gbbct1.seq";
FILE *fptr = fopen(filename, "r");
if (fptr == 0)
{
fprintf(stderr, "failed to open file '%s' for reading\b", filename);
exit(EXIT_FAILURE);
}
while (1)
{
int c;
while ((c = fgetc(fptr)) != EOF)
fputc(c, stdout);
clearerr(fptr);
sleep(1);
}
/*NOTREACHED*/
return EXIT_FAILURE;
}
The sleep() function sleeps for an integral number of seconds; if you want sub-second sleeps, you can consider usleep(),
nanosleep(), timer_create() and relatives, etc.
I have a program I call dribbler (because it dribbles data to its output):
Usage: dribbler [-hlntV][-s nap.time][-r std.dev][-f outfile][-i infile][-m message][-o openstr][-F format]
-V Print version information and exit
-f outfile Write to named file (dribbler.out)
-h Print this help message and exit
-i infile Read lines from input file
-l Loop back to start of input file on EOF
-m message Write message on each line of output
-n Number lines read from input file
-o openstr Flags passed to fopen() (a+)
-s nap.time Sleep for given interval between writes (1.000 second)
-r std.dev Randomize the time (Gaussian around nap.time with std.dev)
-t Write to standard output instead of file
-F format Printf format to use instead of %zu
I used:
$ dribbler -s 3 -r 1.3 -f gbbct1.seq &
[1] 81129
$
to write to the control file that program2 is coded to read. I then ran program2 on it, and it produced the outputs as it proceeded.
It's hard to show the time sequence on SO. I have another program (the story of my life) called tstamp which reads lines of input and prints them with a timestamp prefixed to the line:
Usage: tstamp [-hV][-f num][-F format]
-f num Number of fractional digits (0, 3, 6, 9)
-h Print this help message and exit
-F fmt Time format (strftime(3)) to use
-V Print version information and exit
I tried modifying program2.c to set line buffered mode on my Mac (macOS Sierra 10.12.5, GCC 7.1.0), by adding the line below before the while loop in program2.c, but it was effectively ignored, somewhat to my surprise and chagrin:
setvbuf(fptr, 0, _IOLBF, 0);
So, I rewrote the while loop as:
while ((c = fgetc(fptr)) != EOF)
{
fputc(c, stdout);
if (c == '\n')
fflush(stdout);
}
Then I was able to run dribbler in the background, and program2 | tstamp -f 3 to get output like:
$ program2 | tstamp -f 3
2017-06-03 23:52:44.836: 0: message written to file
2017-06-03 23:52:44.836: 1: message written to file
2017-06-03 23:52:44.836: 2: message written to file
2017-06-03 23:52:44.836: 3: message written to file
[…more similar lines with the same time stamp…]
2017-06-03 23:52:44.836: 22: message written to file
2017-06-03 23:52:44.836: 23: message written to file
2017-06-03 23:52:44.836: 24: message written to file
2017-06-03 23:52:44.836: 25: message written to file
2017-06-03 23:52:50.859: 26: message written to file
2017-06-03 23:52:54.866: 27: message written to file
2017-06-03 23:52:58.880: 28: message written to file
2017-06-03 23:53:02.888: 29: message written to file
2017-06-03 23:53:05.902: 30: message written to file
2017-06-03 23:53:07.907: 31: message written to file
2017-06-03 23:53:09.913: 32: message written to file
2017-06-03 23:53:12.925: 33: message written to file
2017-06-03 23:53:14.935: 34: message written to file
2017-06-03 23:53:15.938: 35: message written to file
2017-06-03 23:53:19.954: 36: message written to file
2017-06-03 23:53:21.964: 37: message written to file
2017-06-03 23:53:23.972: 38: message written to file
^C
$ kill %1
[1]+ Terminated: 15 dribbler -s 3 -r 1.3 -f gbbct1.seq
$
You can see that I'd had dribbler running for a while when I started program2 (it got modified and recompiled — part of my chagrin), so there was quite a lot of date to read immediately (hence the multiple lines with the timestamp 2017-06-03 23:52:44.836:), but then it was waiting on dribbler to write more, and as you can see, it sometimes waited nearly 6 seconds between lines, and other times about 1 second, and various intervals in between. The gaps are made more uniform by program2 sleeping for a second at a time. (Yes, I wrote these tools to help answer questions on SO — but dribbler and tstamp both pre-date this question by months.)
I have two programs: one (program1) writes to a file continuously, and I want the other program (program2) to read the file continuously.
What happens then is platform-specific. BTW, the mere ability to run several programs at once (in several processes) is provided by the operating system (and is not defined in, since outside of, the C11 standard). Read Operating Systems : Three Easy Pieces (freely downloadable chapters).
IIRC, on Windows (that I don't know and never used) that is not allowed to happen (one of the programs would be blocked or would have its file open fail).
However, if on Linux with a native local file system (such as Ext4), you could consider using inotify(7) facilities (which won't work with remote file systems à la NFS, and probably won't work on FAT filesystems like e.g. some USB key; but you need to check).
Basically, I want the output of program1 to be used as the input of program2. Is there any way to read and write in RAM instead of file as disk read costs more time.
(I am supposing you wrote both program1 and program2, or at least have their source code and can modify it)
BTW, application programs don't read directly from RAM; they work in virtual memory and each process has its own virtual address space. See this answer.
You surely want to have some inter-process communications, which are provided by your operating system.
On Linux there are many ways of doing that (you should read Advanced Linux Programming whose chapters are freely downloadable). I suggest considering some fifo(7), or some pipe(7) (if both running programs can be started from a common process), or some unix(7) sockets.
You surely need to multiplex for I/O (in both processes) e.g. by having some event loop around a poll(2).
Windows also has inter-process communication facilities. But I don't know them.
(I strongly recommend to spend a few days reading, notably Advanced Linux Programming or some other similar book, before writing a single line of code. You lack an overall picture on OSes and on Linux)
I would recommend using a pipe(7), or else some named fifo(7), or else some unix(7) socket. You could then write code portable on all POSIX systems. I don't recommend to use a file and inotify(7) (which is complex and Linux specific). See also popen(3).
You might find some framework libraries (e.g. Glib from GTK, QtCore, POCO, libevent, 0mq) to help you write portable code able to run on many platforms.
I am working on Pintos OS project. I get this message:
Page fault at 0xbfffefe0: not present error writing page in user context.
The problem with Pintos OS project is that it won't simply tell the line and method that caused the exception.
I know how to use breakpoints/watchpoints etc. but is there any way to step right to it without going through the WHOLE flow and ALL OS files line by line so that I could jump into line that caused exception and put breakpoint there? I looked at GDB commands but didn't find anything.
When I debug this project I have to step through the whole program until I find that error/exception which is very time consuming. There is probably a faster way to do this.
Thanks.
Whole trace:
nestilll#vdebian:~/Class/pintos/proj-3-bhling-nestilll-nsren/src/vm/build$ pintos -v -k -T 60 --qemu --gdb --filesys-size=2 -p tests/vm/pt-grow-pusha -a pt-grow-pusha --swap-size=4 -- -q -f run pt-grow-pusha
Use of literal control characters in variable names is deprecated at /home/nestilll/Class/pintos/src/utils/pintos line 909.
Prototype mismatch: sub main::SIGVTALRM () vs none at /home/nestilll/Class/pintos/src/utils/pintos line 933.
Constant subroutine SIGVTALRM redefined at /home/nestilll/Class/pintos/src/utils/pintos line 925.
warning: disabling timeout with --gdb
Copying tests/vm/pt-grow-pusha to scratch partition...
qemu -hda /tmp/N2JbACdqyV.dsk -m 4 -net none -nographic -s -S
PiLo hda1
Loading............
Kernel command line: -q -f extract run pt-grow-pusha
Pintos booting with 4,088 kB RAM...
382 pages available in kernel pool.
382 pages available in user pool.
Calibrating timer... 419,020,800 loops/s.
hda: 13,104 sectors (6 MB), model "QM00001", serial "QEMU HARDDISK"
hda1: 205 sectors (102 kB), Pintos OS kernel (20)
hda2: 4,096 sectors (2 MB), Pintos file system (21)
hda3: 98 sectors (49 kB), Pintos scratch (22)
hda4: 8,192 sectors (4 MB), Pintos swap (23)
filesys: using hda2
scratch: using hda3
swap: using hda4
Formatting file system...done.
Boot complete.
Extracting ustar archive from scratch device into file system...
Putting 'pt-grow-pusha' into the file system...
Erasing ustar archive...
Executing 'pt-grow-pusha':
(pt-grow-pusha) begin
Page fault at 0xbfffefe0: not present error writing page in user context.
pt-grow-pusha: dying due to interrupt 0x0e (#PF Page-Fault Exception).
Interrupt 0x0e (#PF Page-Fault Exception) at eip=0x804809c
cr2=bfffefe0 error=00000006
eax=bfffff8c ebx=00000000 ecx=0000000e edx=00000027
esi=00000000 edi=00000000 esp=bffff000 ebp=bfffffa8
cs=001b ds=0023 es=0023 ss=0023
pt-grow-pusha: exit(-1)
Execution of 'pt-grow-pusha' complete.
Timer: 71 ticks
Thread: 0 idle ticks, 63 kernel ticks, 8 user ticks
hda2 (filesys): 62 reads, 200 writes
hda3 (scratch): 97 reads, 2 writes
hda4 (swap): 0 reads, 0 writes
Console: 1359 characters output
Keyboard: 0 keys pressed
Exception: 1 page faults
Powering off...
to have the GDB debugger run and stop at the desired location:
gdb filename <--start debug session
br main <--set a breakpoint at the first line of the main() function
r <--run until that breakpoint is reached
br filename.c:linenumber <--set another breakpoint at the desired line of code
c <--continue until second breakpoint is encuntered
The debugger will stop at the desired location in the file, IF it ever actually gets there,
When I debug this project I have to step through the whole program
until I find what caused error/exception which is very time consuming.
There is probably a faster way to do this.
Normally what you would do is set a breakpoint just before the error. Then your program will run at full speed, without your intervention, until it reaches that point.
There are several wrinkles here.
First, sometimes it is difficult to know where to put the breakpoint. In this case I suppose I would look for the code that is printing the message, then work backward from there. Sometimes you have to stop at the failure point, examine the stack, set a new breakpoint further up, and re-run the program.
Then there is the mechanics of setting the breakpoint. One simple way is to break by function name, like break my_function. Another is to use the file name and line number, like break my_file.c:73.
Finally, sometimes a breakpoint can be hit many times before the failure is seen. You can use ignore counts (see help ignore) or conditional breakpoints (like break my_function if variable = 27) to limit the number of stops.
I am debugging a program that I have written for the AVR architecture and compiled using avr-gcc with the -g argument.
I launch simulavr using the following command: simulavr --device atmega8 --gdbserver
Then I invoke avr-gdb and do (gdb) file main.elf as well as (gdb) target remote localhost:1212
Once debugging has started, I can successfully step through the assembly portion of my program .init et al. However, once jmp main is executed and a call to another function is made, simulavr throws the following exception: Assertion failed: (m_on_call_sp != 0x0000), function OnCall, file hwstack.cpp, line 266. Abort trap: 6
It has something to do with the pushing a frame to the stack, but I can't quite put my finger on how to fix it.
That stack value is very far from what it should be. At the start of your program, it should be near the end of RAM, not at the beginning.
It is likely to be some problem with simulavr not configuring RAM properly for your device. A quick look for the source code shows that the stack pointer is set to 0 if the simulator can't determine the correct value.
Did you include -mmcu=atmega8 in the command line when compiling? Try adding -V switch to the simulavr command for more clues.
In Perl 5.16.0 sample C program is working but the existing multi-thread program is aborting in Perl_sv_upgrade. Multi-thread program works fine with Perl 5.8.8. The same code works on Linux and Solaris with Perl 5.16.0.
Comparing the sv argument value between Linux and Hp-PA shows the sv value is NULL in case of Hp-PA. Did anybody notice this problem before. Please let me know?
Linux stack trace after debugging and seeing the sv value:
Breakpoint 4, Perl_sv_upgrade (my_perl=0x14fe6400, sv=0x150317a8, new_type=SVt_PV)
at sv.c:1140
1140 sv.c: No such file or directory.
(gdb) where
#0 Perl_sv_upgrade (my_perl=0x14fe6400, sv=0x150317a8, new_type=SVt_PV) at sv.c:1140
HP-PA stack trace after seeing the sv value while analyzing the abort in gdb:
Thread 3 (system thread 428417):
#3 signal handler called
#4 0xca9825c4 in Perl_sv_upgrade (my_perl=0x40236f10, sv=0x0, new_type=SVt_PV)
at sv.c:1260