xeon%uname -sa Linux xeon 2.4.21-15.EL #1 SMP Thu Apr 22 00:09:47 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux xeon%valgrind --db-attach=yes ./pro ==20240== Memcheck, a memory error detector. ==20240== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==20240== Using LibVEX rev 1313, a library for dynamic binary translation. ==20240== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==20240== Using valgrind-3.0.0, a dynamic binary instrumentation framework. ==20240== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==20240== For more details, rerun with: -v ==20240== ==20240== Warning: set address range perms: large range 135969264, a 0, v 1 . . . . ==20240== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n ==20240== Warning: set address range perms: large range 1064979232, a 0, v 1 --20240-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --20240-- si_code=1; Faulting address: 0x0; sp: 0x7013BE80 valgrind: the 'impossible' happened: Killed by fatal signal ==20240== at 0x2A959C0B9F: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==20240== at 0x11B1C563: realloc (vg_replace_malloc.c:306) Thanks, Rak
Can you demonstrate this problem in a small test case? It will be very hard to figure out what is wrong without one. Thanks.
I will try to generate a small case. I guess, i am doing something wrong This happens inside fortran read call (which i dont have control of) Absoft 64-bit Fortran 95 9.0 with Service Pack 1. This happen only if a very large memory is allocated. But does not happen on linux32 bit for same case. Anyway how can i get rid of "Warning: set address range perms: large range 1064979232, a 0, v 1 " ? and what does this mean. Thanks, Rak
> Anyway how can i get rid of "Warning: set address range perms: large > range 1064979232, a 0, v 1 " ? Comment it out and recompile. > and what does this mean. It's a warning that comes up when a very large region of memory is affected by a single operation such as an allocation or deallocation. Your case is 1GB, which is very big! It's there because such operations are rare, and are likely to indicate bugs in computation of the region size.
*** This bug has been marked as a duplicate of 109487 ***