NetBSD Problem Report #44235

From martin@duskware.de  Wed Dec 15 14:45:23 2010
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 983A863B87A
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 15 Dec 2010 14:45:23 +0000 (UTC)
Message-Id: <20101215144523.983A863B87A@www.NetBSD.org>
Date: Wed, 15 Dec 2010 14:45:23 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@gnats.NetBSD.org
Subject: lint1 fails when compiling mesa for sparc
X-Send-Pr-Version: 3.95

>Number:         44235
>Notify-List:    uwe@netbsd.org
>Category:       bin
>Synopsis:       lint1 fails when compiling mesa for sparc
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 15 14:50:00 +0000 2010
>Last-Modified:  Mon Jan 17 15:45:03 +0000 2011
>Originator:     Martin Husemann
>Release:        NetBSD 5.9.41
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD night-porter.duskware.de 5.1_STABLE NetBSD 5.1_STABLE (PORTER) #23: Sun Nov 21 11:25:34 CET 2010 martin@night-porter.duskware.de:/usr/src-5/sys/arch/i386/compile/PORTER i386
Architecture: i386
Machine: i386
>Description:

Trying to run a build.sh -x with -m sparc reproducable fails for me with a
lint1 core dump. Interestingly this core is called 
./tools/lint1/lint1 ./external/rg/lib/libOSMesa/sparc--netbsdelf.core
(compare the prefix passed to the lint build - the lint1 is missing).

The failure happens here:

Core was generated by `sparc--netbsdelf'.
Program terminated with signal 11, Segmentation fault.
#0  0x08061f81 in nextinit (brace=0)
    at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/init.c:420
420                     if (initstk->i_type == NULL &&
(gdb) bt
#0  0x08061f81 in nextinit (brace=0)
    at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/init.c:420
#1  0x0806222a in mkinit (tn=0xbb784000)
    at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/init.c:538
#2  0x0804ae9b in yyparse ()
    at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/cgram.y:1171
#3  0x08051b74 in main (argc=2, argv=0xbfbfe510)
    at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/main1.c:222
(gdb) print *initstk
$1 = {i_type = 0x0, i_subt = 0xbb76fdc4, i_brace = 0, i_nolimit = 0, 
  i_namedmem = 0, i_mem = 0x0, i_cnt = 1, i_nxt = 0x0}

now 0xbb76fdc4 is a bad index into the types array (and issclt() does no
index checking). No idea where that bogus number comes from.

>How-To-Repeat:
Any build.sh -m sparc -x will do for me, build host is netbsd-5 on i386.

>Fix:
yes please.

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Wed, 15 Dec 2010 15:53:49 +0100

 On Wed, Dec 15, 2010 at 02:50:01PM +0000, martin@NetBSD.org wrote:
 > lint1 core dump. Interestingly this core is called 
 > ./tools/lint1/lint1 ./external/rg/lib/libOSMesa/sparc--netbsdelf.core

 What I tried to say:
 it is called "sparc--netbsdelf.core" and found in
 $OBJDIR//external/rg/lib/libOSMesa/

 Martin

From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Wed, 15 Dec 2010 18:24:53 +0100

 At 14:50 Uhr +0000 15.12.2010, martin@NetBSD.org wrote:
 >Trying to run a build.sh -x with -m sparc reproducable fails for me with a
 >lint1 core dump.

 Same here, fwiw. Build host is i386 netbsd-5.

 	hauke

 -- 
      The ASCII Ribbon Campaign                    Hauke Fath
 ()     No HTML/RTF in email            Institut für Nachrichtentechnik
 /\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf +49-6151-16-3281

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org, christos@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Sun, 19 Dec 2010 04:10:20 +0900

 > Trying to run a build.sh -x with -m sparc reproducable fails for me with a
 > lint1 core dump.

 This also happens on hpcmips and dreamcast targets on i386 5.99.41 host,
 and reverting src/usr.bin/xlint/lint1/tree.c rev 1.65 solves coredump.

 ---
 Izumi Tsutsui

From: henning petersen <henning.petersen@t-online.de>
To: gnats-bugs@NetBSD.org, christos@NetBSD.org
Cc: 
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Sat, 18 Dec 2010 21:40:39 +0100

 Am 18.12.2010 20:15, schrieb Izumi Tsutsui:
 > The following reply was made to PR bin/44235; it has been noted by GNATS.
 >
 > From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
 > To: gnats-bugs@NetBSD.org, christos@NetBSD.org
 > Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
 > Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
 > Date: Sun, 19 Dec 2010 04:10:20 +0900
 >
 >  > Trying to run a build.sh -x with -m sparc reproducable fails for me with a
 >  > lint1 core dump.
 >  
 >  This also happens on hpcmips and dreamcast targets on i386 5.99.41 host,
 >  and reverting src/usr.bin/xlint/lint1/tree.c rev 1.65 solves coredump.
 >  
 >  ---
 >  Izumi Tsutsui
 >  
 >


 I think that failure is
          strg1->st_wcp = xrealloc(strg1->st_wcp, sizeof(*strg1->st_wcp));
 change to
          strg1->st_wcp = xrealloc(strg1->st_wcp, len * sizeof(*strg1->st_wcp));


 Henning Petersen

From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44235 CVS commit: src/usr.bin/xlint/lint1
Date: Sat, 18 Dec 2010 15:57:42 -0500

 Module Name:	src
 Committed By:	christos
 Date:		Sat Dec 18 20:57:41 UTC 2010

 Modified Files:
 	src/usr.bin/xlint/lint1: tree.c

 Log Message:
 PR/44235: Martin Husemann: Fix core dump due to memory corruption.
 Found by Henning Petersen


 To generate a diff of this commit:
 cvs rdiff -u -r1.65 -r1.66 src/usr.bin/xlint/lint1/tree.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: henning petersen <henning.petersen@t-online.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Sat, 18 Dec 2010 21:10:58 +0100

 Am 18.12.2010 20:15, schrieb Izumi Tsutsui:
 > The following reply was made to PR bin/44235; it has been noted by GNATS.
 >
 > From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
 > To: gnats-bugs@NetBSD.org, christos@NetBSD.org
 > Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
 > Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
 > Date: Sun, 19 Dec 2010 04:10:20 +0900
 >
 >  > Trying to run a build.sh -x with -m sparc reproducable fails for me with a
 >  > lint1 core dump.
 >  
 >  This also happens on hpcmips and dreamcast targets on i386 5.99.41 host,
 >  and reverting src/usr.bin/xlint/lint1/tree.c rev 1.65 solves coredump.
 >  
 >  ---
 >  Izumi Tsutsui
 >  
 >
 I think that failure is
          strg1->st_wcp = xrealloc(strg1->st_wcp, sizeof(*strg1->st_wcp));
 change to
          strg1->st_wcp = xrealloc(strg1->st_wcp, len *
 sizeof(*strg1->st_wcp));


 Henning Petersen

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org, christos@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, martin@NetBSD.org,
        tsutsui@ceres.dti.ne.jp
Subject: Re: PR/44235 CVS commit: src/usr.bin/xlint/lint1
Date: Sun, 19 Dec 2010 07:33:25 +0900

 >  PR/44235: Martin Husemann: Fix core dump due to memory corruption.
 >  Found by Henning Petersen

 lint1 still dumps core even with this fix. (no wide char in MesaLib)

 Probably istk->i_type->t_dim should be updated once after
 st_len is bumped in catstrg()?

 ---
 Izumi Tsutsui

From: christos@zoulas.com (Christos Zoulas)
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, martin@NetBSD.org
Subject: Re: PR/44235 CVS commit: src/usr.bin/xlint/lint1
Date: Sat, 18 Dec 2010 18:21:52 -0500

 On Dec 19,  7:33am, tsutsui@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
 -- Subject: Re: PR/44235 CVS commit: src/usr.bin/xlint/lint1

 | >  PR/44235: Martin Husemann: Fix core dump due to memory corruption.
 | >  Found by Henning Petersen
 | 
 | lint1 still dumps core even with this fix. (no wide char in MesaLib)
 | 
 | Probably istk->i_type->t_dim should be updated once after
 | st_len is bumped in catstrg()?

 Can you extract a simple example where that fails?
 Do yo know which file it fails on?

 christos

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
        martin@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: PR/44235 CVS commit: src/usr.bin/xlint/lint1
Date: Sun, 19 Dec 2010 13:18:20 +0900

 > Can you extract a simple example where that fails?
 > Do yo know which file it fails on?

 The target is /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/enums.c
 built in /usr/src/external/mit/xorg/lib/libOSMesa/.

 It has so long wrapped strings and that causes the problem?

 ---
 LONGSTRING static const char enum_string_table[] = 
    "GL_2D\0"
    "GL_2_BYTES\0"
    "GL_3D\0"
   :
 [ ~1890 lines ]
   :
    "GL_ZERO\0"
    "GL_ZOOM_X\0"
    "GL_ZOOM_Y\0"
    ;
 ---
 Izumi Tsutsui

From: christos@zoulas.com (Christos Zoulas)
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, 
	martin@NetBSD.org
Subject: Re: PR/44235 CVS commit: src/usr.bin/xlint/lint1
Date: Sun, 19 Dec 2010 11:31:53 -0500

 On Dec 19,  1:18pm, tsutsui@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
 -- Subject: Re: PR/44235 CVS commit: src/usr.bin/xlint/lint1

 | > Can you extract a simple example where that fails?
 | > Do yo know which file it fails on?
 | 
 | The target is /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/enums.c
 | built in /usr/src/external/mit/xorg/lib/libOSMesa/.
 | 
 | It has so long wrapped strings and that causes the problem?
 | 
 | ---
 | LONGSTRING static const char enum_string_table[] = 
 |    "GL_2D\0"
 |    "GL_2_BYTES\0"
 |    "GL_3D\0"
 |   :
 | [ ~1890 lines ]
 |   :
 |    "GL_ZERO\0"
 |    "GL_ZOOM_X\0"
 |    "GL_ZOOM_Y\0"
 |    ;

 Thanks! That should help a lot.

 christos

From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Sat, 15 Jan 2011 02:18:37 +0300

 Some data points.

 I tried to reproduce this under linux (hoping to track it down with
 valgrind) and can't.  I was building under amd64, but with -m32.
 There's no crash and valgrind of the offending lint1 detects nothing.

 Under netbsd lint1 emits the following warning before the crash: 

 /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/enums.c(1930): {}-enclosed initializer required [181]

 I don't see that warning building under linux.

 Under netbsd when I poke around with gdb I see:

 Program received signal SIGSEGV, Segmentation fault.
 0x08058139 in cconv (tn=0xbb891000)
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/tree.c:745
 745             if (tn->tn_type->t_tspec == ARRAY) {
 (gdb) bt
 #0  0x08058139 in cconv (tn=0xbb891000)
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/tree.c:745
 #1  0x0806267b in mkinit (tn=0xbb891000)
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/init.c:552
 #2  0x0804b10a in yyparse ()
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/cgram.y:1171
 #3  0x08051f2c in main (argc=2, argv=0xbfbfe858)
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/main1.c:222
 (gdb) p/x *tn
 $6 = {tn_op = 0x45565f32, tn_type = 0x58455452, tn_lvalue = 0x1,
   tn_cast = 0x1, tn_parn = 0x1, tn_u = {tn_s = {_tn_left = 0x30424952,
       _tn_right = 0x4e5f345f}, _tn_sym = 0x30424952, _tn_val = 0x30424952,
     _tn_strg = 0x30424952}}
 (gdb) x/s tn
 0xbb891000:      "2_VERTEX_ATTRIB0_4_NV"


 and mkinit call:

 1169    init_expr:
 1170              expr                          %prec T_COMMA {
 1171                    mkinit($1);
 1172              }

 gets bogus tn already on entry.

 -uwe

From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Mon, 17 Jan 2011 04:44:59 +0300

 dmalloc shows memory corruption.  Watchpoint for the overwritten
 dmalloc 'fence-bottom' is triggered at 

 0x08057773 in getsnode (strg=0xbb6cf868)
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/tree.c:380
 380                     (void)memcpy(n->tn_strg->st_cp, strg->st_cp, len + 1);
 (gdb) bt
 #0  0x08057773 in getsnode (strg=0xbb6cf868)
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/tree.c:380
 #1  0x0804bd05 in yyparse ()
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/cgram.y:1642
 #2  0x08051f2c in main (argc=2, argv=0xbfbfe82c)
     at /usr/src/tools/lint1/../../usr.bin/xlint/lint1/main1.c:222


 memcpy args are:

 (gdb) p *n->tn_u._tn_strg
 $12 = {st_tspec = CHAR, st_len = 41103, st_u = {_st_cp = 0xbb6d0000 "GL_2D",
     _st_wcp = 0xbb6d0000}}
 (gdb) p *strg
 $25 = {st_tspec = CHAR, st_len = 41103, st_u = {_st_cp = 0xb8e40008 "GL_2D",
     _st_wcp = 0xb8e40008}}


 (gdb) x/i $eip
 0x8057773 <getsnode+204>:       rep movsb %ds:(%esi),%es:(%edi)
 (gdb) p len
 $47 = 41103
 (gdb) p $ecx
 $48 = 24719
 (gdb) p/x $esi
 $49 = 0xb8e44009
 (gdb) p/x $edi
 $50 = 0xbb6d4001

 Note that strg->st_cp comes from dmalloc (+8 bytes offset for the
 fence), but n->tn_strg->st_cp comes comes from xmaplloc (mmaped,
 starts at page boundary).

 -uwe

From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Mon, 17 Jan 2011 05:00:25 +0300

 xgetblk doesn't check if the next free block it pick up has enough
 space for the allocation.  We come asking for s=41104 bytes, there
 isn't enough space in the current block, so we get one from freelist
 and don't check that it has enough space, so in
 usr.bin/xlint/lint1/mem1.c

 216             mb->nfree -= s;

 size_t nfree gets wrapped into 0xffff.... values and after that all
 bets are off, since this block now has enough memory for everything :)

 jmc@ tried to fix this:

   revision 1.8
   date: 2002/06/28 05:03:55;  author: jmc;  state: Exp;  lines: +9 -2
   Change xgetblk to detect cases where the requested size is more than mblklen.
   (generally it's 20k). Adjust mblklen temporarily to the size of the block
   required and allocate one. This avoids coredumps when mapping in identifiers
   that have huge values. (In my example it was a char[] for a 640k pixmap).

 but didn't address the case of frmblks != NULL.

 -uwe

From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44235 CVS commit: src/usr.bin/xlint/lint1
Date: Sun, 16 Jan 2011 22:04:11 -0500

 Module Name:	src
 Committed By:	christos
 Date:		Mon Jan 17 03:04:10 UTC 2011

 Modified Files:
 	src/usr.bin/xlint/lint1: mem1.c

 Log Message:
 PR/44235: Valeriy E. Ushakov: Don't pick up a block from the free list if
 it is not big enough, allocate a new one. XXX: this is inefficient, but at
 least it does not end up corrupting memory.


 To generate a diff of this commit:
 cvs rdiff -u -r1.13 -r1.14 src/usr.bin/xlint/lint1/mem1.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org,
	uwe@netbsd.org
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Mon, 17 Jan 2011 08:19:09 +0000

 On Mon, Jan 17, 2011 at 02:05:03AM +0000, Valeriy E. Ushakov wrote:
 > The following reply was made to PR bin/44235; it has been noted by GNATS.
 > 
 > From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
 > Date: Mon, 17 Jan 2011 05:00:25 +0300
 > 
 >  xgetblk doesn't check if the next free block it pick up has enough
 >  space for the allocation.  We come asking for s=41104 bytes, there
 >  isn't enough space in the current block, so we get one from freelist
 >  and don't check that it has enough space, so in
 >  usr.bin/xlint/lint1/mem1.c

 Is lint using its own 'malloc' built on top of the system one?
 Or is something else going on here??

 If malloc isn't good enough it should be fixed!

 	David

 -- 
 David Laight: david@l8s.co.uk

From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Mon, 17 Jan 2011 15:10:03 +0300

 On Mon, Jan 17, 2011 at 08:19:09 +0000, David Laight wrote:

 > On Mon, Jan 17, 2011 at 02:05:03AM +0000, Valeriy E. Ushakov wrote:
 >
 > > The following reply was made to PR bin/44235; it has been noted by GNATS.
 > > 
 > > From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
 > > Date: Mon, 17 Jan 2011 05:00:25 +0300
 > > 
 > >  xgetblk doesn't check if the next free block it pick up has enough
 > >  space for the allocation.  We come asking for s=41104 bytes, there
 > >  isn't enough space in the current block, so we get one from freelist
 > >  and don't check that it has enough space, so in
 > >  usr.bin/xlint/lint1/mem1.c
 > 
 > Is lint using its own 'malloc' built on top of the system one?
 > Or is something else going on here??
 > 
 > If malloc isn't good enough it should be fixed!

 I haven't actually read the code :), but I assume it's written that
 way to simplify memory management.  You can allocate a lot of
 transient objects for some context (e.g. an expression or statement)
 and then do a bulk free on them when your context dies, instead of
 free'ing every one of them (which also requires keeping track of them &c).

 -uwe

From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/44235 CVS commit: src/usr.bin/xlint/lint1
Date: Mon, 17 Jan 2011 15:11:29 +0300

 On Mon, Jan 17, 2011 at 03:05:04 +0000, Christos Zoulas wrote:

 >  Module Name:	src
 >  Committed By:	christos
 >  Date:		Mon Jan 17 03:04:10 UTC 2011
 >  
 >  Modified Files:
 >  	src/usr.bin/xlint/lint1: mem1.c
 >  
 >  Log Message:
 >  PR/44235: Valeriy E. Ushakov: Don't pick up a block from the free list if
 >  it is not big enough, allocate a new one. XXX: this is inefficient, but at
 >  least it does not end up corrupting memory.
 >  
 >  
 >  To generate a diff of this commit:
 >  cvs rdiff -u -r1.13 -r1.14 src/usr.bin/xlint/lint1/mem1.c

 This fixes it.  dmalloc is happy and my landisk build now completes
 successfully.

 Thanks.

 -uwe

From: christos@zoulas.com (Christos Zoulas)
To: David Laight <david@l8s.co.uk>, gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org, 
	uwe@netbsd.org
Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
Date: Mon, 17 Jan 2011 10:42:16 -0500

 On Jan 17,  8:19am, david@l8s.co.uk (David Laight) wrote:
 -- Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc

 | On Mon, Jan 17, 2011 at 02:05:03AM +0000, Valeriy E. Ushakov wrote:
 | > The following reply was made to PR bin/44235; it has been noted by GNATS.
 | > 
 | > From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
 | > To: gnats-bugs@NetBSD.org
 | > Cc: 
 | > Subject: Re: bin/44235: lint1 fails when compiling mesa for sparc
 | > Date: Mon, 17 Jan 2011 05:00:25 +0300
 | > 
 | >  xgetblk doesn't check if the next free block it pick up has enough
 | >  space for the allocation.  We come asking for s=41104 bytes, there
 | >  isn't enough space in the current block, so we get one from freelist
 | >  and don't check that it has enough space, so in
 | >  usr.bin/xlint/lint1/mem1.c
 | 
 | Is lint using its own 'malloc' built on top of the system one?
 | Or is something else going on here??
 | 
 | If malloc isn't good enough it should be fixed!

 That was my thought too... It uses its own pool allocator.

 christos

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.