writing a very simple read file in Fortran 95. The file has only three numbers in it, every time I run the code, the .exe file says "error: attempt to read end-of-file at address", any clues why this keeps happening?
The code is :
program readdata
implicit none
!Delcaration of variables
real :: x,y,z
!Main part
open (10, file='C:\Users\matth\OneDrive\Documents\Tutorialcode\array.txt',ACCESS='SEQUENTIAL', STATUS='OLD', FORM='FORMATTED')
read (10, *) x, y, z
print *,x,y,z
close (10)
end program readdata
I have loaded your code into my Eclipse IDE, using GNU Fortran.
I confirm that the code compiles, without error or warning, and runs as advertised.
With an array.txt file of:
1.00, 2.00, 3.00
I get output:
1.00, 2.00, 3.00
With an empty file I get:
At line 13 of file ../readdata.f90 (unit = 10, file = 'C:\Users\franc\array.txt')
Fortran runtime error: End of file
Error termination. Backtrace:
Could not print backtrace: libbacktrace could not find executable to open
#0 0xffffffff
#1 0xffffffff
#2 0xffffffff
#3 0xffffffff
#4 0xffffffff
#5 0xffffffff
#6 0xffffffff
#7 0xffffffff
#8 0xffffffff
#9 0xffffffff
#10 0xffffffff
#11 0xffffffff
#12 0xffffffff
#13 0xffffffff
#14 0xffffffff
So, my suspicion is over whether your file is missing some values.
Please also see:
Fortran 90 - Attempt to read past end of file
Related
In every program I try to debug, I am getting the same result, every time I use breakpoints and try to run any program gdb crash. I tried the same thing on different programs and it keeps acting like this.
I will show the result on this simple:
int main(int argc,char* argv[]){
for(int i = 0;i < 200; i++){
printf("%d\n",i);
}
}
gcc main.c -m32 -std=c99 -o test
GNU gdb (Debian 8.3-1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test...
(No debugging symbols found in test)
(gdb) disas main
Dump of assembler code for function main:
0x00001199 <+0>: lea 0x4(%esp),%ecx
0x0000119d <+4>: and $0xfffffff0,%esp
0x000011a0 <+7>: pushl -0x4(%ecx)
0x000011a3 <+10>: push %ebp
0x000011a4 <+11>: mov %esp,%ebp
0x000011a6 <+13>: push %ebx
0x000011a7 <+14>: push %ecx
0x000011a8 <+15>: sub $0x10,%esp
0x000011ab <+18>: call 0x10a0 <__x86.get_pc_thunk.bx>
0x000011b0 <+23>: add $0x2e50,%ebx
0x000011b6 <+29>: movl $0x0,-0xc(%ebp)
0x000011bd <+36>: jmp 0x11d8 <main+63>
0x000011bf <+38>: sub $0x8,%esp
0x000011c2 <+41>: pushl -0xc(%ebp)
0x000011c5 <+44>: lea -0x1ff8(%ebx),%eax
0x000011cb <+50>: push %eax
0x000011cc <+51>: call 0x1030 <printf#plt>
0x000011d1 <+56>: add $0x10,%esp
0x000011d4 <+59>: addl $0x1,-0xc(%ebp)
0x000011d8 <+63>: cmpl $0xc7,-0xc(%ebp)
0x000011df <+70>: jle 0x11bf <main+38>
0x000011e1 <+72>: mov $0x0,%eax
0x000011e6 <+77>: lea -0x8(%ebp),%esp
0x000011e9 <+80>: pop %ecx
0x000011ea <+81>: pop %ebx
0x000011eb <+82>: pop %ebp
0x000011ec <+83>: lea -0x4(%ecx),%esp
0x000011ef <+86>: ret
End of assembler dump.
(gdb) break *0x000011ef
Breakpoint 1 at 0x11ef
(gdb) run
Starting program: /root/test
[1]+ Stopped gdb test
I tried to do the same thing in another linux machine, and it works fine. So what could be the problem?
Update: I found a temp solution for the breakpoints issue (so gdb do not crash), You use the command (start) at the beginning and everything will work fine :
GNU gdb (Debian 8.3-1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test...
(No debugging symbols found in test)
(gdb) start
Temporary breakpoint 1 at 0x11a8
Starting program: /root/test
Temporary breakpoint 1, 0x565561a8 in main ()
(gdb) enable
(gdb) disas main
Dump of assembler code for function main:
0x56556199 <+0>: lea 0x4(%esp),%ecx
0x5655619d <+4>: and $0xfffffff0,%esp
0x565561a0 <+7>: pushl -0x4(%ecx)
0x565561a3 <+10>: push %ebp
0x565561a4 <+11>: mov %esp,%ebp
0x565561a6 <+13>: push %ebx
0x565561a7 <+14>: push %ecx
=> 0x565561a8 <+15>: sub $0x10,%esp
0x565561ab <+18>: call 0x565560a0 <__x86.get_pc_thunk.bx>
0x565561b0 <+23>: add $0x2e50,%ebx
0x565561b6 <+29>: movl $0x0,-0xc(%ebp)
0x565561bd <+36>: jmp 0x565561d8 <main+63>
0x565561bf <+38>: sub $0x8,%esp
0x565561c2 <+41>: pushl -0xc(%ebp)
0x565561c5 <+44>: lea -0x1ff8(%ebx),%eax
0x565561cb <+50>: push %eax
0x565561cc <+51>: call 0x56556030 <printf#plt>
0x565561d1 <+56>: add $0x10,%esp
0x565561d4 <+59>: addl $0x1,-0xc(%ebp)
0x565561d8 <+63>: cmpl $0xc7,-0xc(%ebp)
0x565561df <+70>: jle 0x565561bf <main+38>
0x565561e1 <+72>: mov $0x0,%eax
0x565561e6 <+77>: lea -0x8(%ebp),%esp
0x565561e9 <+80>: pop %ecx
0x565561ea <+81>: pop %ebx
0x565561eb <+82>: pop %ebp
0x565561ec <+83>: lea -0x4(%ecx),%esp
0x565561ef <+86>: ret
End of assembler dump.
(gdb) break *0x565561df
Breakpoint 2 at 0x565561df
(gdb) info break
Num Type Disp Enb Address What
2 breakpoint keep y 0x565561df <main+70>
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/test
Breakpoint 2, 0x565561df in main ()
(gdb) step
Single stepping until exit from function main,
which has no line number information.
0
Breakpoint 2, 0x565561df in main ()
(gdb)
Single stepping until exit from function main,
which has no line number information.
1
Breakpoint 2, 0x565561df in main ()
(gdb)
Single stepping until exit from function main,
which has no line number information.
2
Breakpoint 2, 0x565561df in main ()
(gdb)
Single stepping until exit from function main,
which has no line number information.
3
Breakpoint 2, 0x565561df in main ()
(gdb)
Single stepping until exit from function main,
which has no line number information.
4
Breakpoint 2, 0x565561df in main ()
Unfortunately, This is a temp solution just so you can deal with breakpoints, and it have nothing to do with the crashing problem.
You are most likely trying to set a breakpoint at an invalid address with this command break *0x000011ef. The 0x11ef is the offset of that instruction within the section within the ELF, but the program is going to be relocated when it is loaded / started.
You should instead try start, then disas main, and then place your breakpoint.
GDB stopping like this is a bug which occurs when GDB throws an error while trying to place a breakpoint, it was fixed in upstream GDB with this patch:
https://sourceware.org/ml/gdb-patches/2019-05/msg00361.html
Once you see GDB stopped like this:
[1]+ Stopped gdb soQuestionProgram
you should be dropped back to a shell. Just resume GDB with the fg command and continue your debug session. Once GDB 8.4 is out this bug will be fixed.
it keeps acting like this
First: GDB did not crash. It merely got stopped (by your shell). You can get it back with the shell fg command.
Second: this has nothing to do with GDB, and something to do with your terminal configuration. Using reset may cure this problem.
I have a text file with several thousand numbers arranged like this:
line 1: #0 #1 #2 #3 #4 #5
line 2: #6 #7 #8 #9 #10 #11
...
line 111: #106 #107 #108 #109 #110
line 112: #111 #112 #113 #114 #115
...
What I would like to do is format my file to look like this:
line 1: #0 #1 #2 #3 #4 #5 #111 #112 #113 #114 #115 ...
line 2: #6 #7 #8 #9 #10 #11 #116 #117 #118 #119 #120 #121 ...
...
line 111: #106 #107 #108 #109 #110 #218 #219 #220 #221 #222 #223...
basically I want to arrange my numbers in a 111x111 matrix (so after the first 111 lines which would stay in place line 112 would be merged with the first line, line 113 with the second etc and this would happen for every 111 lines). Is there any way of doing this with awk/sed?
Any help would be appreciated!
If you're ok with having temporary files, you can use split then paste. split splits a file into smaller files of n lines each, and paste takes input files and concatenates them vertically.
Choosing an arbitrary prefix tmp for our temporary files:
split -l 111 input.txt tmp
paste tmp* >output.txt
rm tmp*
Try this, untested since you didn't provide testable sample input/output:
awk -v RS='\\s' '{ORS=(NR%111?"\n":OFS)}1' file
The above uses GNU awk for multi-char RS and \s.
When I go to a simple product in order to adjust the price I get a error when I save the product.
Error
There has been an error processing your request
Decoding failed: Syntax error
Trace:
#0 /data/web/public/app/code/core/Mage/Core/Helper/Data.php(659): Zend_Json::decode('', 1)
#1 /data/web/public/app/code/local/Amasty/Conf/Model/Observer.php(145): Mage_Core_Helper_Data->jsonDecode(NULL)
#2 /data/web/public/app/code/core/Mage/Core/Model/App.php(1357): Amasty_Conf_Model_Observer->onSuperProductAttributesPrepareSave(Object(Varien_Event_Observer))
#3 /data/web/public/app/code/core/Mage/Core/Model/App.php(1336): Mage_Core_Model_App->_callObserverMethod(Object(Amasty_Conf_Model_Observer), 'onSuperProductA...', Object(Varien_Event_Observer))
#4 /data/web/public/app/Mage.php(448): Mage_Core_Model_App->dispatchEvent('catalog_product...', Array)
#5 /data/web/public/app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php(670): Mage::dispatchEvent('catalog_product...', Array)
#6 /data/web/public/app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php(725): Mage_Adminhtml_Catalog_ProductController->_initProductSave()
#7 /data/web/public/app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Adminhtml_Catalog_ProductController->saveAction()
#8 /data/web/public/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('save')
#9 /data/web/public/app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#10 /data/web/public/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#11 /data/web/public/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#12 /data/web/public/index.php(83): Mage::run('dutch', 'store')
#13 {main}
Error log record number: 817468762686
I hope someone can tell me what may be the cause.
Best regards,
Michel
Might you be running Magento 1.9 on a PHP7 System? This answer only applies if you are running PHP7. If so, try PHP5.6 and see if it still gives you a problem.
If you are on PHP7, it may be because you need the Inchoo_PHP7 Extension.
Have a look here: https://community.magento.com/t5/Technical-Issues/Magento-1-9-2-create-account-cannot-save-the-customer-error/m-p/42237#M3899
And also here on GitHub, where the extension can also be downloaded: github.com/Inchoo/Inchoo_PHP7/issues/29
I myself had a similar issue on new order creation at http://www.buildersdepot.com, but it seems connected to PHP7, so updating with a new Incho_PHP7 download seems to have done the trick for me on 8/6/2016, my old version was dated around 4/1/2016.
I'm getting an undefined instruction exception when executing:
0xED2D8B0E VPUSH {D8-D14}
(Note: The statement was generated by the compiler as part of C language function entry protocol.)
Initialization code:
;; Initialize VFP (if needed).
;; BL __iar_init_vfp HJ REMOVED AND REPLACED WITH BELOW
MRC p15, #0, r1, c1, c0, #2 ; r1 = Access Control Register
ORR r1, r1, #(0xf << 20) ; enable full access for p10,11
MCR p15, #0, r1, c1, c0, #2 ; Access Control Register = r1
MOV r1, #0
MCR p15, #0, r1, c7, c5, #4 ; flush prefetch buffer because of FMXR below
; and CP 10 & 11 were only just enabled
; Enable VFP itself
MOV r0,#0x40000000
FMXR FPEXC, r0 ; FPEXC = r0
I get the undefined exception when the target FPU is set up as VFPv3 or VFPV3 + NEON.
The initialization code is placed in the "cstartup.c" file, at the __iar_program_start and ?cstartup code, following this code snippet:
MRC p15,0,R1,C1,C0,0
LDR R0,=CP_DIS_MASK ;; 0xFFFFEFFA
AND R1,R1,R0
ORR R1,R1,#(1<<12)
MCR p15,0,R1,C1,C0,0
Registers (before VPUSH):
CPSR: 0x80000113
APSR: 0x80000000
SPSR: 0x000001D3
Tools:
IAR Embedded Workbench IDE & Compiler - 7.40
I-Jet debugging probe
Zoom AM3517 eval board
TI AM35X Cortex-A8 processor
Questions:
In the initialization code above, which statements are required for
NEON and which for VFP?
Are there any initialization instructions I'm missing for NEON and
VFP initialization?
Are there statements I need to place in the macro file for the debug
probe?
The code presented in the question correctly initializes the floating point processor on a Cortex-A8 processor.
The issue of getting undefined instruction exception (which led up to this question), was caused by the O.S. writing an invalid value to the FPEXC register, causing the Floating Point Processor to be disabled.
In a minimal STM32 application I've written that writes characters to USART1, the USART doesn't seem to work when I try to enable all the clocks I need at once:
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA
| RCC_APB2Periph_AFIO
| RCC_APB2Periph_USART1, ENABLE);
But when I enable the clocks one at a time, it works:
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);
Why is this? Is there a specific order these clocks have to be enabled in? (If so, where is this documented?)
(I've left out all the code following this that initializes the GPIO pins, sets up the USART, and starts sending content, as it's the same in each application. If it's relevant, let me know and I'll include it.)
The device I'm using is the STM32F103VET6.
Since there's some interest in the assembly involved, here it is. For all three clocks at once:
00000000 <main>:
0: b590 push {r4, r7, lr}
2: b089 sub sp, #36 ; 0x24
4: af00 add r7, sp, #0
6: f244 0014 movw r0, #16389 ; 0x4005
a: 2101 movs r1, #1
c: f7ff fffe bl 0 <RCC_APB2PeriphClockCmd>
And for one clock at a time:
00000000 <main>:
0: b590 push {r4, r7, lr}
2: b089 sub sp, #36 ; 0x24
4: af00 add r7, sp, #0
6: 2004 movs r0, #4
8: 2101 movs r1, #1
a: f7ff fffe bl 0 <RCC_APB2PeriphClockCmd>
e: 2001 movs r0, #1
10: 2101 movs r1, #1
12: f7ff fffe bl 0 <RCC_APB2PeriphClockCmd>
16: f44f 4080 mov.w r0, #16384 ; 0x4000
1a: 2101 movs r1, #1
1c: f7ff fffe bl 0 <RCC_APB2PeriphClockCmd>
...
And here's RCC_APB2PeriphClockCmd:
00000000 <RCC_APB2PeriphClockCmd>:
0: 4b04 ldr r3, [pc, #16] ; (14 <RCC_APB2PeriphClockCmd+0x14>)
2: 699a ldr r2, [r3, #24]
4: b109 cbz r1, a <RCC_APB2PeriphClockCmd+0xa>
6: 4310 orrs r0, r2
8: e001 b.n e <RCC_APB2PeriphClockCmd+0xe>
a: ea22 0000 bic.w r0, r2, r0
e: 6198 str r0, [r3, #24]
10: 4770 bx lr
12: bf00 nop
14: 40021000 .word 0x40021000
0x40021000 is the base address of the RCC peripheral; the #24 offset points to the RCC_APB2ENR register, which has a bit for each clock that's being enabled. (See page 109 of RM0008 for details.)
Well, I think I figured it out, and it turned out to not be a hardware problem at all... there were a number of problems with my toolchain configuration:
I was setting -nostdlib. This was causing some global initialization code to not be generated. I'm not sure how important that was, but other issues included:
I was not passing -mthumb and other CPU options to the linker. This was causing some of the generated startup code to be garbage.
My startup file didn't contain a call to __libc_init_array. This was causing some more initialization code to be dropped at link time.
I'm still not sure why splitting up the peripheral clock initializations managed to work around this. Perhaps the change in the amount of code was bumping something to just the right alignment? Anyways, solving the underlying issues seems to have patched things up so far (although I'm still kind of suspicious of some of the remaining startup code).
You might want to let us know exactly which device you're using and/or look at the errata for that device. For example, the errata for the STM32L100x6/8/B-A (and other) devices has the following (http://www.st.com/web/en/resource/technical/document/errata_sheet/DM00097022.pdf):
2.6.1 Delay after an RCC peripheral clock enabling
Description
A delay between an RCC peripheral clock enable and the effective
peripheral enabling should be taken into account in order to manage
the peripheral read/write to registers.
This delay depends on the peripheral's mapping:
If the peripheral is mapped on AHB: the delay should be equal to 2 AHB cycles.
If the peripheral is mapped on APB: the delay should be equal to 1 + (AHB/APB prescaler) cycles.
Workarounds
Use the DSB instruction to stall the Cortex-M CPU pipeline until the instruction is completed.
Insert "n" NOPs between the RCC enable bit write and the peripheral register writes (n = 2 for AHB peripherals, n = 1 + AHB/APB
prescaler in case of APB peripherals).
This doesn't really sound like your problem but it might be related (maybe the one-at-a-time enabling introduces a delay that turns out to be necessary).