Re: pointer, equivalence, common block, 32bit code, ifort v11 64bit, segfault

If it's relevant this is how memory is allocated:
in a .f file:

i_pointer=memalloc(i_pointer, somenumber)
c numbers are either int or real

Then in memalloc.c:

void *memalloc( void **pntr, int *somenumber )
{ void *newptr;
etc....

works with ifort v11 ia32.

And I compiled with various options such as from
-g -O0 -132 -nus -traceback

I've used other options without any differences:
-align commons -align rec8byte -unroll=0, -no-vec, -heap-arrays -
traceback -fp-stack-check -fp0 -check all

On May 8, 4:16 pm, happy...@xxxxxxxxx wrote:
I have a fortran project (except for memory allocation code in c)
written many years ago. Compiles fine with ifort v11.83 ia32 on
Intel64 machine (dual quad) with RHEL5. But with ifort v11.83
intel64, I get a segfault.

In a pointer .h file, pointers, their targets and equivalence
variables are declared like this:
pointer(i_ptr, ptr)
int(100) arrayptr
equivalence(i_ptr, arrayptr(1)
common /namex/ arrayptr

I'm assuming that routines that has "included" this .h file can access
the pointers, targets and equivalent arrayptr index via the common
declaration. Ptr is implicit here, I think, but is declared as
"character*90 ptr(100)" in such routines.

After other routines allocate memory for a pointer, with c calloc and
realloc call, the following causes a segfault:

ptr(1)="stringx"

--------------------------

I've attempted to convert all integer to "integer*8" or using the
compiler option "-integer-64" without success. (The current standard
doesn't allow allocable pointers and equivalences.) The ptr is the
correct size after memory for i_ptr has been allocated.

Any ideas on how I can resolve this without rewriting the entire code
base? I hope I've included all relevant information here. Thanks.

.

Relevant Pages

  • Re: Ranting about JVMs default memory limits...
    ... Originally, 32-bit Windows split it half and half, with the user code getting 2GB and the OS getting 2GB. ... But, the OS didn't really need 2GB of address space, and so enabling "LARGEADDRESSAWARE" tells the OS that the application doesn't make any assumptions about the range of pointers and that it can pass user data addresses to the process in the first 1GB of the second 2GB of the full 4GB address space. ... Memory blocks aren't moveable, so allocations can sit in between two free blocks, limiting the size of the largest block that can actually be allocated. ... Depending on the allocation pattern, it's not hard at all to have over 1GB of virtual address space left, but not be able to allocate any single block nearly that large. ...
    (comp.lang.java.programmer)
  • Re: Help wanted - problems with heap
    ... Memory pressure, because of limited heap size. ... identified that by failures to allocate memory. ... Any pointers as to work out what is happening would be welcome. ...
    (rec.games.roguelike.development)
  • Re: Garbage Collection VS ALLOCATE and FREE
    ... Well, I worked that way for the first 15 years of my Forth career, but I really don't see how being native or co-resident with an OS has any bearing on how you manage memory. ... Forth compiles from source more than many other languages, because the compile cycle is so quick and simple; it's just as quick and quite a lot simpler to manage code this way than to wrestle with run-time libraries. ... ALLOCATE and FREE are intended for managing data storage, such as temporary buffers for some purpose that you can release when you're done. ... I have always avoided garbage collection and most other dynamic memory allocation schemes any more complex than ALLOCATE and FREE. ...
    (comp.lang.forth)
  • Re: How to allocate memory for a linked list of pointers in a kernel process
    ... are you sure you access memory at proper ... lists using pointers of course. ... When the kernel routines need to allocate a ... Are you aware that the kernel contains routines to do doubly linked lists ...
    (microsoft.public.win32.programmer.kernel)
  • Re: "Criticism of the C programming language ??????"
    ... in which memory allocated by malloc can be garbage-collected, and free becomes a no-op. ... Then existing programs and libraries gain the benefits of GC (in some cases, memory leaks just go away), and new code can be written more simply without bothering to call free. ... Those few programs that play games with pointers would just have to be built with GC disabled, or modified to keep the pointers visible. ... If you allocate memory with GC_alloc, and free the same memory with free, what happens? ...
    (comp.lang.c)