Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: tlug: gcc question
- To: tlug@example.com
- Subject: Re: tlug: gcc question
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Date: Mon, 17 Jan 2000 15:17:03 +0900 (JST)
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=us-ascii
- In-Reply-To: <387DDEE5.91F624DE@example.com>
- References: <Pine.LNX.4.10.10001121547550.26141-100000@example.com><387DB3D3.15948545@example.com><14461.53588.914038.845367@example.com><387DDEE5.91F624DE@example.com>
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
>>>>> "Fredric" == Fredric Fredricson <Fredric.Fredriksson@example.com> writes: Fredric> It is not malloc(3) but sbrk(2) that malloc(3) use to Fredric> request new pages from the kernel that matters. No, because GNU malloc (some version of which is used in all Linux systems AFAIK) breaks up the memory it gets from sbrk() into reasonably-sized pieces. In old GNU malloc, you only get all the raw memory as returned by sbrk if you are allocating more memory than the malloc BLOCKSIZE, which is 2048 bytes on 32 bit systems. I don't know what Doug Lea malloc does, though. Fredric> If you allocate, say, 80 bytes using malloc and start to Fredric> use the returned pointer to write to memory outside these Fredric> 80 bytes you will probably corrupt malloc(3)s data Fredric> structures before you try to access data outside the Fredric> allocated memory for the process and get a SIGSEGV. This actually is not true under the old GNU malloc, since it keeps its data structures in separately allocated memory. Again, I don't know about the strategy followed by new GNU (Doug Lea) malloc, I don't have a copy of the source on my system at the moment. Of course, since C structures often contain pointers, and in many cases function pointers, you don't need to corrupt malloc internal data structures to generate SIGBUS and SIGSEGV errors before overrunning the allocated memory. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." ------------------------------------------------------------------- Next Technical Meeting: January 14 (Fri) 19:00 * Topic: "glibc - current status and future developments" * Guest Speaker: Ulrich Drepper (Cygnus Solutions) * Place: Oracle Japan HQ 12F Seminar Room (New Otani Garden Court) ------------------------------------------------------------------- more info: http://www.tlug.gr.jp Sponsor: Global Online Japan
- Follow-Ups:
- Re: tlug: gcc question
- From: Fredric Fredricson <fredric.fredriksson@example.com>
- References:
- Re: tlug: gcc question
- From: "Scott M. Stone" <sstone@example.com>
- Re: tlug: gcc question
- From: Fredric Fredricson <Fredric.Fredriksson@example.com>
- Re: tlug: gcc question
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Re: tlug: gcc question
- From: Fredric Fredricson <Fredric.Fredriksson@example.com>
Home | Main Index | Thread Index
- Prev by Date: tlug: It was PATH. Re: Partial execution of /etc/rc.d/rc.M
- Next by Date: Re: tlug: problems with netscape 4.7 japanese
- Prev by thread: Re: tlug: gcc question
- Next by thread: Re: tlug: gcc question
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links