06-23-2010
fortran: segmentation fault when deallocating
Hi,
I'm looking for a quite "interesting" bug at the moment - any idea could help! (o;
Language is fortran 90, compiler gfortran (sry, dont find which version it is). As I suppose you dont want to read like 10k lines of code here, I won't post the entire thing ^^
The problem is that I get segmentation faults when deallocating four of my arrays while running the program. The output is depending on which of the arrays i deallocate first.. I always get one of those:
*** glibc detected *** double free or corruption (out)
*** glibc detected *** free(): invalid next size (normal)
*** glibc detected *** double free or corruption (!prev)
segmentation fault
This happens only when a variable - which has NOTHING to do with the arrays i'm trying to deallocate - has a certain value.
My problem is that the cause isn't one of the normal stuff - the arrays are totally well defined, i'm not trying to write values outside the boundaries, ect.
Also, I can deallocate the arrays directly after changing them the last time.
I do suppose that at some other point of the program something is going terribly wrong and sort of overwriting my arrays (But nooo, the values as well as size(), ubound() and lbound() are what they should be, and allocated() is true.)
Does anybody have an idea what is happening here? Have you seen something similar yet? What could i still try?
Greetings & thank you,
Giogio
10 More Discussions You Might Find Interesting
1. UNIX for Dummies Questions & Answers
hello all,
I tried a program on an array to intialise array elements from the standard input device.it is an integer array of 5 elements.but after entering the 4th element it throws a message called "Segmentation Fault" and returns to the command prompt without asking for the 5th element.
... (3 Replies)
Discussion started by: compbug
3 Replies
2. AIX
Hi ,
During execution a backup binary i get following error
"Program error 11 (Segmentation fault), saving core file in '/usr/datatools"
Riyaz (2 Replies)
Discussion started by: rshaikh
2 Replies
3. Linux
Hi,
on a linux Red HAT(with Oracle DB 9.2.0.7) I have following error :
RMAN> delete obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 2
using channel ORA_DISK_1
Segmentation fault
What does it mean ? And the solution ?
Many thanks. (0 Replies)
Discussion started by: big123456
0 Replies
4. UNIX for Dummies Questions & Answers
Hi,
While comparing primary key data of two tables thr bteq script I am getting this Error. This script is a shell script.
*** Error: The following error was encountered on the output file.
Script.sh: 3043492 Segmentation fault(coredump)
Please let me know how to get through it.
... (5 Replies)
Discussion started by: monika
5 Replies
5. Programming
If I do this.
Assume
struct life
{
char *nolife;
}
struct life **life;
// malloc initialization & everything
if(life->nolife == 0)
Would I get error at life->nolife if it is equal to 0.
wrong accession? (3 Replies)
Discussion started by: joey
3 Replies
6. Programming
Hi,
I am having this segmentation fault not in the following program, bt. in my lab program . My lab program is horrible long so cannot post it here bt. I am using the following logic in my program which is giving the segmentation fault. Bt. if I run this sample program as it is it dosen't give... (3 Replies)
Discussion started by: mind@work
3 Replies
7. Programming
I use a binary name (ie polo) it gets some parameter , so for debugging normally i do this :
i wrote script for watchdog my app (polo) and check every second if it's not running then start it , the problem is , if my app , remain in state of segmentation fault for a while (ie 15 ... (6 Replies)
Discussion started by: pooyair
6 Replies
8. Solaris
Hi Guys,
I just installed and booted a zone called testzone. When I logged in remotely and tried changing to root user I get this error:
"Segmentation fault"
Can someone please help me resolve this?
Thanks alot (2 Replies)
Discussion started by: cjashu
2 Replies
9. Programming
I keep getting this fault on a lot of the codes I write, I'm not exactly sure why so I'd really appreciate it if someone could explain the idea to me.
For example this code
#include <stdio.h>
main()
{
unsigned long a=0;
unsigned long b=0;
int z;
{
printf("Enter two... (2 Replies)
Discussion started by: sizzler786
2 Replies
10. Programming
Oddities with gcc, 2.95.3 for the AMIGA and 4.2.1 for MY current OSX 10.14.1...
I am creating a basic calculator for the AMIGA ADE *NIX emulator in C as it does not have one.
Below are two very condensed snippets of which I have added the results inside the each code section.
IMPORTANT!... (11 Replies)
Discussion started by: wisecracker
11 Replies
LEARN ABOUT REDHAT
malloc
MALLOC(3) Linux Programmer's Manual MALLOC(3)
NAME
calloc, malloc, free, realloc - Allocate and free dynamic memory
SYNOPSIS
#include <stdlib.h>
void *calloc(size_t nmemb, size_t size);
void *malloc(size_t size);
void free(void *ptr);
void *realloc(void *ptr, size_t size);
DESCRIPTION
calloc() allocates memory for an array of nmemb elements of size bytes each and returns a pointer to the allocated memory. The memory is
set to zero.
malloc() allocates size bytes and returns a pointer to the allocated memory. The memory is not cleared.
free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Oth-
erwise, or if free(ptr) has already been called before, undefined behaviour occurs. If ptr is NULL, no operation is performed.
realloc() changes the size of the memory block pointed to by ptr to size bytes. The contents will be unchanged to the minimum of the old
and new sizes; newly allocated memory will be uninitialized. If ptr is NULL, the call is equivalent to malloc(size); if size is equal to
zero, the call is equivalent to free(ptr). Unless ptr is NULL, it must have been returned by an earlier call to malloc(), calloc() or
realloc().
RETURN VALUE
For calloc() and malloc(), the value returned is a pointer to the allocated memory, which is suitably aligned for any kind of variable, or
NULL if the request fails.
free() returns no value.
realloc() returns a pointer to the newly allocated memory, which is suitably aligned for any kind of variable and may be different from
ptr, or NULL if the request fails. If size was equal to 0, either NULL or a pointer suitable to be passed to free() is returned. If real-
loc() fails the original block is left untouched - it is not freed or moved.
CONFORMING TO
ANSI-C
SEE ALSO
brk(2), posix_memalign(3)
NOTES
The Unix98 standard requires malloc(), calloc(), and realloc() to set errno to ENOMEM upon failure. Glibc assumes that this is done (and
the glibc versions of these routines do this); if you use a private malloc implementation that does not set errno, then certain library
routines may fail without having a reason in errno.
Crashes in malloc(), free() or realloc() are almost always related to heap corruption, such as overflowing an allocated chunk or freeing
the same pointer twice.
Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment vari-
ables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple
errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be
protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored;
if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately. This can be useful because otherwise a crash
may happen much later, and the true cause for the problem is then very hard to track down.
Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the mem-
ory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM
killer.
GNU
1993-04-04 MALLOC(3)