[archive] Instruction at "XXX" referenced memory at "XXX" The memory could not be read

[Migrated content. Thread originally posted on 04 December 2008]

Hello,

I (along with my customers) have received the title error numerous times from various programs in my system. I have seen a few posts about this occurring in AcuCobol 7 and being fixed in version 8. However, I am using Acu 6.2 and have not found anyone mentioning that version as having issues. At this time, an upgrade is not plausible.

Can anyone comment on this?

Thanks,
Edgar

Without more details it is difficult to comment. Each version of Acu probably fixes some memeory leaks and potentially creates other or different memory leaks. This issue you receive appears to be memory alignment.

Memory alignment error
A "Memory alignment error" occurs in response to a Bus Error signal. This signal is generated on some UNIX machines (but not all) when a multi-byte data item is accessed on an inappropriate memory boundary. These machines require that integers and long data items be aligned on a certain byte boundary and involves how the CPU fetches data and the optimizations present in the machine's instruction set. For example, if a program accesses a 4-byte long data item that is not aligned on a memory address that is divisible by 4, a memory alignment error would occur.


Data correctly aligned:


data 1 = a|a|a|a|


data 2 = b|b|b|b|



Data misaligned:

(data 2 doesn't begin at the start of the 4-byte address)

data 1 = a|a|b|b|

data 2 = b|b| | |


COMPILE SWITCHES TO USE


The most common solution to memory alignment errors is to synchronize data items by compiling all programs with these three switches:


* Dw32 or -Dw64 (modifies the size of some data types based on the maximum word size specified (32-bit or 64-bit))

* Da4 or -Da8 (specifies that data should be aligned on quad-byte or octal- byte boundaries)

* Dl# (specifies a maximum boundary to the alignment modulus used for SYNCHRONIZED data items


Other compile switches which have been used to correct the alignment error:


* Dy treats all binary data items as if they were SYCHRONIZED. D5 treats BINARY data items as COMP-5 data items.

* D6 treats unsigned, PACKED-DECIMAL, data items as COMP-6.

* Dm changes the binary data item storage size.

* Df changes all COMP-1 data to FLOAT and COMP-2 data to DOUBLE.


OTHER POSSIBLE CAUSES AND SOLUTIONS


-Cr compile option:


Often, it has been found that compiling without the -Cr causes the memory alignment errors to disappear. RM-compatibility causes COMP data items to be treated as "COMP-2" items (unpacked decimal). This is RM/COBOL's normal meaning of COMP (although RM has switches to imply other formats). This can be worked around by adding "-D2" to the compile line. Note, however, that this change causes all COMP items to be treated as COMP-4, so this could affect compatibility with existing data.


Relinked runtime:

If this problem is happening with a relinked runtime on a Solaris machine, it is interesting to note that one customer resolved a memory alignment problem by rebuilding the runtime with this switch, "-xmemalign=8i", which was found in the manual of Forte C (Standard C compiler for Solaris). The cc line in that makefile was "CC = cc -xarch=v9 -xmemalign=8i"


REDEFINES

REDEFINES items can often cause problems; a closer look at those may be warranted.


Use COMP-5

The development team recommends using COMP-5 data types for numbers to help avoid memory alignment errors.


Debug in 'C' compiler

One way to find a memory alignment error is to compile for debugging and run under a 'C' debugger with the runtime's "-z" switch. "-Z" turns off our signal-catching routines. When bad things happen (such as segmentation violation or bus error), then the -z switch causes the runtime to dump the core instead of shutting down nicely. It allows 'C'-style debuggers to trap what is going on. When the error occurs, the debugger should pick up the bus error signal and point to the offending code.


Tables/Arrays

Sometimes, a memory alignment error occurs on a table (array) that contains a referencing error. To find these errors, compile with a -Za, which will detect them. Be sure to recompile them without -Za for production as this switch adversely affects performance.

[Migrated content. Thread originally posted on 04 December 2008]

Hello,

I (along with my customers) have received the title error numerous times from various programs in my system. I have seen a few posts about this occurring in AcuCobol 7 and being fixed in version 8. However, I am using Acu 6.2 and have not found anyone mentioning that version as having issues. At this time, an upgrade is not plausible.

Can anyone comment on this?

Thanks,
Edgar

Dilbert, thanks for the quick reply. I should have given more details in the original post.j

The platforms we are using are mostly Windows XP, with the occasional 2000/2003 thrown in. There are 2 scenarios where I know this is occurring, but there may be more.

First, when exiting the main window, while canceling the child programs, this error gets thrown.

The second scenario is a bit more prevalent. We interface with a third-party program using a flat file. I write to the file; the other program updates it with a status letting me know it's got control; and then check it periodically (usually every 2 seconds) for an update. Yes I know this is extremely inefficient but this was in place long before I got to this company. The error gets thrown right at the moment I write the initial data and the other program picks it up to start processing. The error numbers are the exact same ("0x7c1768a1" and "0x0014718c") regardless of which machine gets the error.

In the meantime, I will look through my code for your suggestions.

Thanks,
Edgar

[Migrated content. Thread originally posted on 04 December 2008]

Hello,

I (along with my customers) have received the title error numerous times from various programs in my system. I have seen a few posts about this occurring in AcuCobol 7 and being fixed in version 8. However, I am using Acu 6.2 and have not found anyone mentioning that version as having issues. At this time, an upgrade is not plausible.

Can anyone comment on this?

Thanks,
Edgar

Dilbert, thanks for the quick reply. I should have given more details in the original post.j

The platforms we are using are mostly Windows XP, with the occasional 2000/2003 thrown in. There are 2 scenarios where I know this is occurring, but there may be more.

First, when exiting the main window, while canceling the child programs, this error gets thrown.

The second scenario is a bit more prevalent. We interface with a third-party program using a flat file. I write to the file; the other program updates it with a status letting me know it's got control; and then check it periodically (usually every 2 seconds) for an update. Yes I know this is extremely inefficient but this was in place long before I got to this company. The error gets thrown right at the moment I write the initial data and the other program picks it up to start processing. The error numbers are the exact same ("0x7c1768a1" and "0x0014718c") regardless of which machine gets the error.

In the meantime, I will look through my code for your suggestions.

Thanks,
Edgar

[Migrated content. Thread originally posted on 04 December 2008]

Hello,

I (along with my customers) have received the title error numerous times from various programs in my system. I have seen a few posts about this occurring in AcuCobol 7 and being fixed in version 8. However, I am using Acu 6.2 and have not found anyone mentioning that version as having issues. At this time, an upgrade is not plausible.

Can anyone comment on this?

Thanks,
Edgar

Is it possible that there is an antivirus program running on the machines wheere the memory issue occurs. Sometimes if the virus software is set "high" enough, the virus software gets in the way of reading / writing to data files.

[Migrated content. Thread originally posted on 04 December 2008]

Hello,

I (along with my customers) have received the title error numerous times from various programs in my system. I have seen a few posts about this occurring in AcuCobol 7 and being fixed in version 8. However, I am using Acu 6.2 and have not found anyone mentioning that version as having issues. At this time, an upgrade is not plausible.

Can anyone comment on this?

Thanks,
Edgar

We've already required our customers to ignore this interface file on any virus scan.

[Migrated content. Thread originally posted on 04 December 2008]

Hello,

I (along with my customers) have received the title error numerous times from various programs in my system. I have seen a few posts about this occurring in AcuCobol 7 and being fixed in version 8. However, I am using Acu 6.2 and have not found anyone mentioning that version as having issues. At this time, an upgrade is not plausible.

Can anyone comment on this?

Thanks,
Edgar

The mav you experience when cancelling child programs sounds like one of the issues we have adressed which was about deleting an object and later try to handle messages on it. To get this right yu have to upgrade.

As for the issue with the file, I doubt this is about anti virus, sounds weird. At any rate, as you describe it, it sounds like a very focused issue and should be possible to reproduce at small scale. If it does not, it is certainly not an anti virus issue as that should be persistent.

[Migrated content. Thread originally posted on 04 December 2008]

Hello,

I (along with my customers) have received the title error numerous times from various programs in my system. I have seen a few posts about this occurring in AcuCobol 7 and being fixed in version 8. However, I am using Acu 6.2 and have not found anyone mentioning that version as having issues. At this time, an upgrade is not plausible.

Can anyone comment on this?

Thanks,
Edgar

The mav you experience when cancelling child programs sounds like one of the issues we have adressed which was about deleting an object and later try to handle messages on it. To get this right yu have to upgrade.

As for the issue with the file, I doubt this is about anti virus, sounds weird. At any rate, as you describe it, it sounds like a very focused issue and should be possible to reproduce at small scale. If it does not, it is certainly not an anti virus issue as that should be persistent.

[Migrated content. Thread originally posted on 04 December 2008]

Hello,

I (along with my customers) have received the title error numerous times from various programs in my system. I have seen a few posts about this occurring in AcuCobol 7 and being fixed in version 8. However, I am using Acu 6.2 and have not found anyone mentioning that version as having issues. At this time, an upgrade is not plausible.

Can anyone comment on this?

Thanks,
Edgar

I agree that this is not an anti-virus issue.

Unfortunately, this is not reproducible. This interface is heavily used; about 40 times a day per machine, and over 20 different machines. The error occurs about once or twice a day.