From mint-bounce@lists.fishpool.fi  Tue Jan 22 17:32:48 2008
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
Subject: Re: [MiNT] another getcwd fix (includes previous patch)
From: Alan Hourihane <alanh@fairlite.demon.co.uk>
To: Vincent =?ISO-8859-1?Q?Rivi=E8re?= <vincent.riviere@freesbee.fr>
Cc: mint <mint@fishpool.com>
In-Reply-To: <4782BA5D.1070700@freesbee.fr>
References: <1199736442.9383.23.camel@localhost>
	 <4782BA5D.1070700@freesbee.fr>
Content-Type: text/plain; charset=UTF-8
Date: Tue, 08 Jan 2008 09:19:14 +0000
Message-Id: <1199783954.12260.5.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-To: mint-bounce@lists.fishpool.fi
X-original-sender: alanh@fairlite.demon.co.uk
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
List-subscribe: <mailto:mint-request@lists.fishpool.fi?Subject=subscribe>
List-owner: <mailto:tjhukkan@fishpool.fi>
List-post: <mailto:mint@lists.fishpool.fi>
X-Virus-Scanned: by amavisd-new at relay.boerde.de
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de
X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=7.0 tests=AWL,
 BAYES_00
X-Spam-Level: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by freemint id m0MGP1dc004618
Status: 
X-Status: 
X-Keywords:                   

On Tue, 2008-01-08 at 00:48 +0100, Vincent Rivière wrote:
> Hello, Alan.
> 
> > Another problem with getcwd() is that it defines a variable sized buffer
> > for _path (which is non-ANSI as the note says).
> > 
> > With gcc optimizations this gets messed up and crashes, probably due to
> > stack corruption.
> 
> The variable sized array is non-ANSI, however it shouldn't crash !
> It may be a GCC bug, a MiNTLib bug, or once again a stack overflow !

As I said, it only crashes when using optimizations with GCC, i.e. -O or
greater. So it sounds like a GCC bug.

> If the size passed to __getcwd() is too big, the original version will 
> allocate a buffer of that size on the stack, and may crash. You version 
> uses malloc, so it is safer.

Right, which is why I prefer the patch.

> However, it would be interesting to know exactly what was the cause of 
> the crash. Did you manage to make a small testcase reproducing that 
> problem ?

I do have a testcase, but I've not delved into it to find why the
optimiser is causing the crash.

Given that the patch cures it and malloc's memory rather than from the
stack, I'm not inclined to go digging much further. 

Alan.