Description of problem: valloc() is returning a pointer to a block of memory that is not mmaped by the process which later leads to a segv. Version-Release number of selected component (if applicable): [root@ca-test14-RHAS21 root]# uname -a Linux ca-test14 2.4.18-e.41smp #1 SMP Mon Dec 22 23:36:53 EST 2003 ia64 unknown [root@ca-test14-RHAS21 root]# rpm -q glibc glibc-2.2.4-32.15 I'm presently dealing with adding O_DIRECT support for various utils. In this case tar. These particular changes have been working well in the ia32 enviroment for some time now (5+ months) but recently I was asked to port it over to ia64 where a problem has arisen. In my code I have to use memory aligned buffers and to do this I make a call via valloc() void *DIO_buf; ... mem_req = blks_req * blk_size; DIO_buf = valloc(mem_req); this_read = read (desc, DIO_buf, len); memmove (ptr, DIO_buf, len); Under debugging this will segv on the ia64 in the memmove but the fault seems to be with the valloc(); 99 memmove (ptr, DIO_buf, len); (gdb) print ptr $5 = (void *) 0x600000000000ceb0 (gdb) print DIO_buf $6 = (void *) 0x14000 (the memmove() segv's, (len is 8192)) now according to the process memory map (/proc/<pid>/maps) 0000000000000000-0000000000004000 r--p 0000000000000000 00:00 0 .. <large shared lib list deleted> 6000000000004000-600000000000c000 rw-p 0000000000084000 08:06 200177 /usr/src/redhat/BUILD/tar-1.13.25/src/tar 600000000000c000-600000000001c000 rw-p 0000000000000000 00:00 0 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 60000ffffffec000-60000fffffffc000 rwxp ffffffffffff4000 00:00 0 the variable DIO_buf assigned as address 0x14000 doesn't live within any of the memory maps used by the process thus when we try and operate on it, we get a segv because the process has no claim to memory in that address space and the program bails out. Thus a new question assises which is why did valloc(memsize); allocate a pointer to memory that wasn't in use or allocated to the process. This smells like a glibc bug. Possibly a kernel bug if glibc did request a memory pool and the kernel didn't register it in the maps. Now I'm not saying my code is perfect, and I'll happily accept the answer as 'your code is crap' however I know this works well in ia32 space but the lack of a corresponding memory map area assigned to the process does raise questions. If valloc() had failed I'd have expected a NULL or -1 return but I don't I get passed an address the process cannot use. Help! Phil =--=
(argh glibc not glib...)
Are you sure your program is seeing valloc prototype? Without valloc prototype what you see would be expected. You get valloc prototype in stdlib.h if you are compiling with BSD features (no feature set macros, no -ansi, no -std=c{8,9}9} or -D_GNU_SOURCE or -D_XOPEN_SOURCE >= 500. If this is not a problem (try -W -Wall), I need a self contained (and as small as possible) testcase to reproduce. valloc call I have tried on AS2.1/ia64 worked just fine.
Ah, it IS one of the -D defines that caused this to go awol in the include headers. Thank you Jakub. I appologise for wasting your time with this error on my part. Cheers Phil =--=