I recently got some Fortran code, which successfully ran on Mac OS. This code along with input files were later sent to me to get compiled. I precisely used the same code and the same input files but an error "array bounds exceeded" appeared. I am using CVF 6.6 on Windows XP.
I wanted to know the following things:
Is this a compiler or OS problem?
Shall I arrange a Mac OS to get them compiled?
After surfing so much on internet I think the wise thing to do is to get my data "format free". But I don't how to do that when my data is a time series with time in one column and voltage in the second.
The error message array bounds exceeded always (I think) indicates that your code has tried to access an array element outside the bounds of an array, for example element 25 in an array with 24 elements. This can only occur at run-time, and your compiler/run-time will only spot it if, when compiling, you set on the compiler option(s) for array bounds checking; your compiler documentation will tell you what those options are.
The error message should have been accompanied by some more information telling you where in the program the error occurred and the index of the out-of-bounds array access.
Given that your source code and your input data are identical how could this have occurred ? Since you have compiled the program on 2 different platforms your compilations cannot have been identical, it is entirely possible that array bounds checking is switched off on your Mac and on on your Windows PC.
Fortran programs may execute apparently successfully despite making accesses to out-of-bounds array elements. If the memory address of array element 25 out of 24 holds a value which is meaningful and the address is within your program's space the computation is likely to continue. It is also likely to be useless, but you can go for many years before finding that out.
I suggest that you go back to the Mac, recompile with array bounds checking, and run again, see what happens.
It's also possible that the routines which read your file find a different number of values on XP and Mac; I suspect that can be caused by different line ending characters, even by whether or not the input file has a newline at the end. Check this too.
Related
I have a huge application (made in PowerBuilder) that crashes every once in a while so it is hard to reproduce this error. We have it set up so that when a crash like this occurs, we recieve a .dmp file.
I used WinDbg to analyze my .dmp file with the command !analyze -v. From this I can deduct that the error that occured was an Access Violation C0000005. Based on the [0] and [1] parameters, it attempted to dereference a null pointer.
WinDbg also showed me STACK_TEXT consisting of around 30 lines, but I am not sure how to read it. From what I have seen I need to use some sort of symbols.
First line of my STACK_TEXT is this:
00000000`00efca10 00000000`75d7fa46 : 00000000`10df1ae0 00000000`0dd62828 00000000`04970000 00000000`10e00388 : pbvm!ob_get_runtime_class+0xad
From this, my goal is to analyze this file to figure out where exactly in the program this error happened or which function it was in. Is this something I will be able to find after further analyzing the stack trace?
How can I pinpoint where in the program a crash happened using .dmp and WinDbg so I can fix my code?
If you analyze a crash dump with !analyze -v, the lines after STACK TEXT is the stack trace. The output is equivalent to kb, given you set the correct thread and context.
The output of kb is
Child EBP
Return address
First 4 values on the stack
Symbol
The backticks ` tell you that you are running in 64 bit and they split the 64 bit values in the middle.
On 32 bit, the first 4 parameters on the stack were often equivalent to the first 4 parameters to the function, depending on the calling convention.
On 64 bit, the stack is not so relevant any more, because with the 64 bit calling convention, parameters are passed via registers. Therefore you can probably ignore those values.
The interesting part is the symbol like pbvm!ob_get_runtime_class+0xad.
In front of ! is the module name, typically a DLL or EXE name. Look for something that you built. After the ! and before the + is a method name. After the + is the offset in bytes from the beginning of the function.
As long as you don't have functions with thousands of lines of code, that number should be small, like < 0x200. If the number is larger than that, it typically means that you don't have correct symbols. In that case, the method name is no longer reliable, since it's probably just the last known (the last exported) method name and a faaaar way from there, so don't trust it.
In case of pbvm!ob_get_runtime_class+0xad, pbvm is the DLL name, ob_get_runtime_class is the method name and +0xad is the offset within the method where the instruction pointer is.
To me (not knowing anything about PowerBuilder) PBVM sounds like the PowerBuilder DLL implementation for Virtual Memory. So that's not your code, it's the code compiled by Sybase. You'd need to look further down the call stack to find the culprit code in your DLL.
After reading Wikipedia, it seems that PowerBuilder does not necessarily compile to native code, but to intermediate P-Code instead. In this case you're probably out of luck, since your code is never really on the call stack and you need a special debugger or a WinDbg extension (which might not exist, like for Java). Run it with the -pbdebug command line switch or compile it to native code and let it crash again.
In both GW-BASIC and QuickBASIC, statements are passed arguments, some of which are optional and can be omitted depending on the statement:
REM Move the text cursor to the specified column and row.
LOCATE row%, column%
REM Move the text cursor to the specified column without changing the row.
LOCATE , column%
In GW-BASIC, the CLEAR statement is rather unusual in that its first "argument" is always omitted:
CLEAR , basicMem
CLEAR , basicMem, basicStack
CLEAR , , basicStack
In QuickBASIC, the basicMem parameter became optional due to the interpreter/runtime managing its own memory:
CLEAR , , basicStack
What I'm wondering is whether that first "argument" ever used for anything prior to GW-BASIC, i.e. something like this was actually useful:
CLEAR missingArg, basicMem, basicStack
REM ^^^^^^^^^^
REM here
That is, was there ever an purposeful non-empty argument before the first comma?
If anybody has any idea, I'd love to know!
What I'm wondering is whether that first "argument" ever used for
anything prior to GW-BASIC, i.e. something like this was actually
useful:
CLEAR missingArg, basicMem, basicStack
REM ^^^^^^^^^^
REM here
That is, was there ever an purposeful non-empty argument before the
first comma?
Yes, there was a first argument, but there was never a 3-argument form that actually made use of it.
Microsoft (originally Micro-Soft) created Altair BASIC. It featured a CLEAR command with no arguments that set all program variables to zero. The 4K version had no strings, so it had no need for managing string space. However, the 8K, Extended, and Disk versions had a CLEAR command that also accepted a single argument of the form CLEAR x. The value x specified the maximum amount of string space available in bytes, with the default at load time of BASIC being 50 bytes in the 8K version and 200 bytes in the Extended and Disk versions until it was changed [source]. That's where the missing first argument came from and what it was used for originally. At the time, however, only that one argument was valid.
Microsoft went on to develop a derivative called "BASIC-80" for several systems, notably the Intel ISIS-II, CP/M, and TEKDOS operating systems. A "Standalone Disk BASIC" version of BASIC-80 was also created that could run on "almost any 8080 or Z80 based disk hardware without an operating system." There was no 4K version of BASIC-80, so it's reasonable to assume all versions of BASIC-80 had strings available as the 8K version of Altair BASIC did. As a result, that string space needed managed. However, it was in BASIC-80 that a second argument was added:
CLEAR [expression![,address]]
expression! was an expression that specified the amount of string space, like in 8K (Altair) BASIC, and address was the maximum address available to BASIC, i.e. the amount of memory available to BASIC, like the argument immediately after the first comma in GW-BASIC.
Eventually, BASIC-80, Release 5.0, was shipped into the world, and it featured the odd syntax instead:
CLEAR [,[expression1][,expression2]]
expression1 was the maximum memory available to BASIC, and expression2 was the amount of stack space. Appendix A: New Features in BASIC-80, Release 5.0 explains why the first argument was dropped:
String space is allocated dynamically, and the first argument in a two-argument CLEAR statement will be ignored.
In other words, CLEAR strSpace!,maxMem would ignore the strSpace! argument in BASIC-80, Release 5.0, so the syntax became CLEAR [,[maxMem][,maxStack]].
QuickBASIC eventually changed the syntax further to just CLEAR [,,stack].
Confusingly, the on-line help system of QuickBASIC 4.5 states the following:
Note: Two commas are used before stack to keep QuickBASIC compatible
with BASICA. BASICA included an additional argument that set the
size of the data segment. Because QuickBASIC automatically manages
the data segment, the first parameter is no longer required.
"The first parameter" mentioned is maxMem as BASICA (and GW-BASIC) used the syntax available with BASIC-80, Release 5.0, rather than the equally missing strSpace! parameter used by pre-5.0 releases of BASIC-80.
I'm trying to implement "Two bag-of-words classifiers", so I found resources at this website. http://people.csail.mit.edu/fergus/iccv2005/bagwords.html This website provides complete files including Matlab code. But I've encountered some errors while implementing the code.
I run this code on Matlab 2011b , under Windows 7.
At first, some errors occur because of path experession, but this can be soleved. At file "gg_lola_km_binary.m", replace "/" with "\" due to path expression in Windows, and it also needs to allocate appropiate path. After doing this, this error has been solved, but the next error occur:
Error using imformats>find_in_registry (line 512)
Format specifier must be a 1-D character array.
I consider whether this error results from Matlab version difference, but I don't know how to solve this problem.
Thank You
The error should be something to do with the format of your Input.Not your Matlab version. Most of the written distributed functions are constructed using basic operations and should work on most versions of Matlab (even the older versions); if not it will probably prompt an unknown function being called which it does not recognize.
Your errors seems to say that:
The function imformats>find_in_registry is looking for a 1 dimensional character array, which it did not find. (most possibly in your input file format or file path). I suggest you check again, without further information, we cannot help you.
In a previous version of MATLAB (7.6), I used to get OutOfMemoryErrors that I thought were kind of annoying. But since I upgraded to 7.11, for some reason it's not throwing the errors anymore.
This means that when I accidentally try to make a variable that's way too large, the MATLAB shell will try to create the variable and bring my machine to a halt.
I'd really like to have these errors get thrown, so that I can exit out gracefully or debug my code, but I can't find the solution anywhere.
Possibly useful details:
I'm using OSX 10.5 on a 64-bit machine, with 4GB of RAM.
In MATLAB 7.6:
$ rand(50000);
??? Error using ==> rand
Maximum variable size allowed by the program is exceeded.
In MATLAB 7.11:
$ rand(50000);
(hang)
Between version 7.6 and 7.11 the Macintosh version of MATLAB switched from a 32-bit application to a 64-bit application. So now instead of running out of address space MATLAB thrashes.
Matlab doesn't hang. It's just paging, which takes forever. Try assigning a large array, open the Activity Monitor, and see the 'Virtual Memory' grow and grow.
If you reduce the page file size on your system, you can avoid that issue.
I've read a lot of similar questions, but I can't seem to find an answer to exactly what my problem is.
I've got a set of minidumps from a 32-bit application that was running on 64-bit Windows 2008. The 32-bit Visual Studio on my 32-Bit Vista Business wouldn't touch them at all, so I've been trying to open them in WinDbg.
I don't have the EXACT corresponding .pdb files (we only started saving them AFTER this particular release), but I have .pdbs built by the same machine with the same code. I also have access to the exact executable that created the minidumps.
I found a nifty little application called ChkMatch that can make .pdbs match an executable... the only difference (according to ChkMatch) was age, so I matched my newer .pdbs to the original executable.
However, when I load it in WinDbg, it still says that it is a "mismatched pdb" then, since I had set .symopts+0x40 it tries to load them anyway. I then get the warning:
*** WARNING: Unable to verify checksum for myexe.exe
I ran !lmi myexe and saw that, indeed, the checksum of the executable was in fact zero. From poking around a bit, I've found that the executable should have been built with the /release flag to have a checksum. That's all well and good, but I can't exactly go back in time and rebuild (if I did though, I'd definitely save the original .pdbs :-P ).
Is there anything I can do here? Seems a little ridiculous I can't make things match here at least enough to get a call stack.
you don't need the checksum to get a call stack - this warning can be safely ignored.
to get the stack you need to issue the stack command (any variant of k).
if the minidumps are any good (i.e. describe an actual fault), you should first try the auto analysis !analyze -v which will get you started.
come back when you have exhausted your expertise :o)
If you're working with minidumps then you have to set your image path (Ctrl+I) to point to a location with the images in the dump. The trouble with minidumps is that they don't contain any code or data from the executables on the target, so you have to supply them yourself.
-scott