|
From: Julian S. <js...@ac...> - 2005-03-21 12:05:13
|
Basically it is a mistake to use MAP_FIXED at all, unless you have complete control of the address space. Which, in almost all programs you don't. A few years ago I worked on a project which did this, and our program started to fail on obscure Linux distros. We realised our mistake and reworked it to get rid of MAP_FIXED. J On Sunday 20 March 2005 16:19, Benny Cheung wrote: > Hi Tom, > > Tom Hughes <tom <at> compton.nu> writes: > > How do you know what address the region will be mapped at? If you're > > trying to use MAP_FIXED to force it then be aware that valgrind will > > fail attempts to map memory at some high addresses as only part of the > > address space is available for your program - some is reserved for > > valgrind to use. > > Yes I did. But after I remove the MAP_FIXED in mmap() the memory > (in 64MB chunks) still cannot be allocated. Maybe I need to change > it back to malloc(). > > > If you're talking about the TRANSLATE line for 0x1B8E4C30 then that > > is a function intercept and is nothing to do with any data access in > > your program. > > I see. That clears my doubt. Thanks a lot! > > > You need to look at how/when multibuff is allocated and what sort of > > memory it is pointing at. > > Turns out multibuff is not needed anyway (it is declared as > struct dsmmsg multibuff[BUFFSLOT] as global and then initialized > at a init function that causes the fault), but I still doubt why > the fault does not happen without using Valgrind. > > Best Regards, > Benny. > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |