bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSFromUnicode stack trashing bug


From: Richard Frith-Macdonald
Subject: Re: GSFromUnicode stack trashing bug
Date: Wed, 18 Jan 2006 16:54:29 +0000


On 18 Jan 2006, at 15:30, Wim Oudshoorn wrote:

Richard Frith-Macdonald <richard@brainstorm.co.uk> writes:

On 18 Jan 2006, at 11:16, Wim Oudshoorn wrote:

No, I mean 1. But that is just to try to make the problem simple to grasp.
In practice, take the following example:

BUFSIZ = 1024
extra = 0
bsize = 1024   (it will be this value before the first GROW call)
dpos = 1023
sl = 1
dest = 0

However, it looks like that is an impossible example, since the code
says

if (dst == 0 || *size == 0)
   {
     ptr = buf;
     bsize = (extra != 0) ? BUFSIZ - 1 : BUFSIZ;
   }

Yes, that is the case when setting up. That is why bsize in the first
run is equal  to BUFSIZ.  This is NOT the code in the GROW  macro,
which will will do:  ptr -= BUFSIZ.


Am I missing something here?

I think so.  I am quite convinced I am right.  But even when I am
convinced I have been proven wrong before ;-(

Do you have any code to demonstrate the problem actually happening?

Hm our application? But than, of course that is not a simple test program.

At the moment I am really struggling with a very nasty memory corruption problem
in a multithreaded environment.  Grrr.   So I won't have time to write
a small test application. But even a small test application does not prove anything. I could well be that it corrupts an innocent part of thes stack.

OK ... I managed to write a test to reproduce it, and confirm that the change I made fixed it.

I imagine this was an extremely rare problem since, I can't find much to trigger it in the base library. Unless I missed something, the only method which uses GSFromUnicode with a null destination pointer seems to be cStringLength (we should probably get a few other methods to use it for efficiency).
The bug would only be triggered for a string at least BUFSIZ bytes long.
The bug would only be triggered if the C string encoding is utf-8






reply via email to

[Prev in Thread] Current Thread [Next in Thread]