Forum Stats

  • 3,840,006 Users
  • 2,262,557 Discussions


Oracle.DataAccess.Client.OracleException (0x80004005): Memory could not be allocated



  • RobM
    RobM Member Posts: 9 Green Ribbon
    edited May 25, 2022 4:22AM

    That was my thought as well (that it had to be a client issue) but I figured I'd double-check.

    I've been doing some preliminary memory profiling, and it does look like the application might be skirting quite close to that 2gb limit. I need to delve in more detail to find out why - the managed part of the code is using only a small portion of that, and it doesn't have the classic profile of a memory leak, but in the meantime any ways to work around that would be welcome. I've been reading up about the /3GB system switch though, and everything I've read implies that it doesn't do anything on a 64-bit OS; I should be clear that the app is stuck as 32-bit, but the OS of the servers is 64-bit.

    EDIT: Found some info about the /LARGEADDRESSAWARE compiler flag, that seems like it might help. I'll give that a try.

  • Alex Keh-Oracle
    Alex Keh-Oracle Posts: 3,107 Employee

    Yes, you're right about /3GB. That was an option for apps on 32-bit OSes since 1 of those GBs was being taken from the OS to use. It's been awhile since I've dealt with any 32-bit specific limitations. The /LARGEADDRESSAWARE is for 32-bit apps on 64-bit OSes. Theoretically, it would appear that it would give a 32-bit app more memory without robbing from 64-bit OS resources.

  • RobM
    RobM Member Posts: 9 Green Ribbon
    Answer ✓

    I've proved to myself that it is indeed the 2GB limit for 32-bit processes that is causing the memory error, so I'm going to call this solved, and leave it here in case someone else finds it useful.

    Haven't yet worked out where the memory leak in our code is, but that's not really Oracle's problem...