Bug 129474 - valloc() madness allocates without mmap()?
Summary: valloc() madness allocates without mmap()?
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: glibc
Version: 2.1
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-08-09 15:44 UTC by Bryce
Modified: 2016-11-24 15:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-08-10 13:11:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bryce 2004-08-09 15:44:19 UTC
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
=--=

Comment 1 Bryce 2004-08-09 15:47:08 UTC
(argh glibc not glib...)

Comment 2 Jakub Jelinek 2004-08-09 16:59:48 UTC
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.

Comment 3 Bryce 2004-08-10 13:11:28 UTC
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
=--=


Note You need to log in before you can comment on or make changes to this bug.