View source for Other less-common errors

----
<span style="color:red"><strong><big>We have migrated bug reports and support requests to our [https://github.com/geoschem/geos-chem/issues/ Github issue tracker].</big></strong></span>
----


'''''[[Segmentation faults|Previous]] | [[Guide to GEOS-Chem error messages|Next]] | [[Guide to GEOS-Chem error messages]]'''''

#[[Understanding the different categories of errors]]
#[[Compile-time warnings and errors]]
#[[Run-time crashes and abnormal exits]]
#[[Segmentation faults]]
#<span style="color:blue">'''Other less-common errors'''</span>


== Overview ==

The errors listed below, which occur infrequently, are related to invalid memory operations.  These can especially occur with  <code>POINTER</code>-based variables.

=== Bus Error ===

A bus error means that you are trying to reference memory that cannot possibly be there.  The website StackOverflow.com has a [http://stackoverflow.com/questions/212466/what-is-a-bus-errornice definition of bus error and how it differs from a segmentation fault].

One cause of a bus error can be if you are trying to call a subroutine with the wrong number of arguments (i.e. usually too many arguments).

--[[User:Bmy|Bob Y.]] 12:27, 19 October 2012 (EDT)

=== Dwarf subprogram entry error ===

The error message:

  Dwarf subprogram entry L_ROUTINE-NAME__LINE-NUMBER__par_loop2_2_576 has high_pc < low_pc. 
  This warning will not be repeated for other occurrences.

can occur when you try to use a pointer variable that is unassociated (i.e. that is not currently pointing to any other variable) from within an OpenMP parallel loop, where:

#<tt>ROUTINE-NAME</tt> is the name of the routine where the error occurred, and
#<tt>LINE-NUMBER</tt> is the line where the error occurred.

We recently discovered that this error can be caused if you have a pointer declaration such as this:

  TYPE(Species), POINTER :: ThisSpc => NULL()

where the pointer <code>ThisSpc</code> is later used to point to another variable from within an OpenMP parallel loop.  As it turns out, the above declaration statement will inadvertently cause pointer <code>ThisSpc</code> to be declared with the <tt>SAVE</tt> attribute.  This can cause a segmentation fault, because all pointers used within an OpenMP parallel region must be created and destroyed on the same thread.

This type of problem can usually be fixed by removing the nullification from the declaration statement.  In other words, you can rewrite the above line of code with:

  TYPE(Species), POINTER :: ThisSpc
  . . .
  ThisSpc => NULL()

For more information, [http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#4 please see this article].

--[[User:Bmy|Bob Yantosca]] ([[User talk:Bmy|talk]]) 19:27, 29 April 2016 (UTC)

=== Relocation truncated to fit ===

Please see [[Intel Fortran Compiler#Relocation truncated to fit error|this wiki post on our Intel Fortran Compiler page]] which describes how to work around an <tt>Relocation truncated to fit</tt> error message.

--[[User:Bmy|Bob Y.]] 10:46, 24 February 2012 (EST)

=== Out of memory asking for NNNNN ===

This is not a common error message, but it may occur if you are compiling a version of GEOS-Chem for a high-resolution horizontal grid, or with one of the available microphysics packages (i,e. [[APM aerosol microphysics|APM]] or [[TOMAS aerosol microphysics|TOMAS]]).  Please see [[Intel_Fortran_Compiler#Out_of_memory_asking_for_NNNNN|this wiki post on our Intel Fortran Compiler page]] which describes this error in detail.

--[[User:Bmy|Bob Y.]] 10:42, 26 July 2013 (EDT)

=== Memory error: "munmap_chunk: invalid pointer" ===

The following error is not common but can happen:

{| border=1 cellspacing=0 cellpadding=5
|-valign="top"
!width="150px" bgcolor="#CCCCCC"|Error
|width="850px"|<tt>*** glibc detected *** ./geos: munmap_chunk(): invalid pointer: 0x00000000059aac30 ***</tt> 

|-valign="top"
!bgcolor="#CCCCCC"|Reference
|http://stackoverflow.com/questions/6199729/how-to-solve-munmap-chunk-invalid-pointer-error-in-c 

|-valign="top"
!bgcolor="#CCCCCC"|Explanation
|This happens when the pointer passed to (C-library language routine <tt>free()</tt>, which is called from Fortran routine <tt>NULLIFY()</tt>) is not valid or has been modified somehow. I don't really know the details here. The bottom line is that the pointer passed to free() must be the same as returned by (C-library routines) malloc(), realloc() and their friends. 

 The free() function frees the memory space pointed  to  by  ptr,  which
 must  have  been  returned  by a previous call to malloc(), calloc() or
 realloc().  Otherwise, or if free(ptr) has already been called  before,
 undefined behavior occurs.  If ptr is NULL, no operation is performed.
 GNU                               2012-05-10                         MALLOC(3)

|-valign="top"
!bgcolor="#CCCCCC"|Simpler explanation
|This can happen if you are trying to deallocate or nullify a pointer variable that has already been deallocated or modified.

|}

--[[User:Bmy|Bob Yantosca]] ([[User talk:Bmy|talk]]) 21:32, 6 January 2017 (UTC)

=== Memory error: "free: invalid size" ===

The following error is not common but can happen:

{| border=1 cellspacing=0 cellpadding=5
|-valign="top"
!width="150px" bgcolor="#CCCCCC"|Error
|width="850px"|<tt>*** Error in `./geos': free(): invalid size: 0x000000000662e090 ***</tt>

|-valign="top"
!bgcolor="#CCCCCC"|Reference
|http://stackoverflow.com/questions/4729395/error-free-invalid-next-size-fast

|-valign="top"
!bgcolor="#CCCCCC"|Explanation
|It means that you have a memory error. You may be trying to free a pointer that wasn't allocated (or delete an object that wasn't created) or you may be trying to nullify/delete such an object more than once. You may be overflowing a buffer or otherwise writing to memory to which you shouldn't be writing, causing heap corruption.  

Any number of programming errors can cause this problem. You need to use a debugger, get a backtrace, and see what your program is doing when the error occurs. If that fails and you determine you have corrupted the heap at some previous point in time, you may be in for some painful debugging (it may not be too painful if the project is small enough that you can tackle it piece by piece).

|}

--[[User:Bmy|Bob Yantosca]] ([[User talk:Bmy|talk]]) 21:32, 6 January 2017 (UTC)

=== Memory error: "double free or corruption" ===

The following error is not common, but can occur under some circumstances:

{| border=1 cellspacing=0 cellpadding=5
|-valign="top"
!width="150px" bgcolor="#CCCCCC"|Error
|width="850px"|<tt> *** glibc detected *** ./geos: double free or corruption (out):</tt>

|-valign="top"
!bgcolor="#CCCCCC"|Reference
|http://stackoverflow.com/questions/2902064/how-to-track-down-a-double-free-or-corruption-error-in-c-with-gdb 

|-valign="top"
!bgcolor="#CCCCCC"|Explanation
|There are at least two possible situations:
#You are deleting the same entity twice
#You are deleting something that wasn't allocated (or that has since been deallocated)

For the first one I strongly suggest NULL-ing all deleted pointers.

You have [some] options:
#Overload new and delete and track the allocations
#Use a debugger -- then you'll get a backtrace from your crash, and that'll probably be very helpful

Three basic rules:
#Set pointer to NULL after free
#Check for NULL before freeing.
#Initialize pointer to NULL in the start.

Combination of these three works quite well. 

This error can also occur if a library that GEOS-Chem needs (e.g. netCDF or netCDF-Fortran) is not installed on your system.  GEOS-Chem will try to make function calls to the missing library, which will result in this error.  In this case, the solution is to install the missing library.

|}

--[[User:Bmy|Bob Yantosca]] ([[User talk:Bmy|talk]]) 21:02, 10 June 2019 (UTC)


----
'''''[[Segmentation faults|Previous]] | [[Guide to GEOS-Chem error messages|Next]] | [[Guide to GEOS-Chem error messages]] | [[Getting Started with GEOS-Chem]]'''''