On Wed, 01 Jan 2003 18:39:08 -0500
Charles Wilson [EMAIL PROTECTED] wrote:
Steven O'Brien wrote:
My patch works around this problem by allocating a buffer of 1024
bytes for cygwin. I think I got this value by reading the cygwin dll
source to find a real upper bound, but it was a long time
Chuck,
On Wed, Jan 01, 2003 at 11:36:49PM -0500, Charles Wilson wrote:
Turns out, the problem IS in newlib.
I concur. In fact, this problem is the root cause for the Cygwin Python
SEGV that I was trying to debug in the following:
Jason Tishler wrote:
I concur. In fact, this problem is the root cause for the Cygwin Python
SEGV that I was trying to debug in the following:
http://cygwin.com/ml/cygwin-developers/2002-12/msg00027.html
For those interested, Python's test_format regression test would SEGV
after trying to
Chuck,
On Thu, Jan 02, 2003 at 03:18:45PM -0500, Charles Wilson wrote:
Jason Tishler wrote:
Thanks for your astute analysis. With the attached patch, I was able
^ ^
* *
But
Chuck,
On Wed, Jan 01, 2003 at 11:36:49PM -0500, Charles Wilson wrote:
Turns out, the problem IS in newlib.
I concur. In fact, this problem is the root cause for the Cygwin Python
SEGV that I was trying to debug in the following:
Hi
I found a possible glib buffer overflow that is cygwin-specific (due to
a bug in cygwin perhaps?) that I worked around when porting glib-1.2.10
to cygwin. Maybe this is still a problem in glib-2.0.x
In glib-1.2.10, gutils.c: g_get_any_init (void), the current user
details are obtained from
On Wed, Jan 01, 2003 at 10:05:10AM +, Steven O'Brien wrote:
Hi
I found a possible glib buffer overflow that is cygwin-specific (due to
a bug in cygwin perhaps?) that I worked around when porting glib-1.2.10
to cygwin. Maybe this is still a problem in glib-2.0.x
In glib-1.2.10, gutils.c:
On Wed, Jan 01, 2003 at 10:05:10AM +, Steven O'Brien wrote:
In glib-1.2.10, gutils.c: g_get_any_init (void), the current user
details are obtained from /etc/passwd. This code is called as part of
glib initialisation, whether the app wants this data or not. It uses
sysconf
On Wed, Jan 01, 2003 at 02:48:54PM -0500, Christopher Faylor wrote:
I've uploaded a new snapshot which should correctly calculate the buffer
size for overflow conditions and returns a large number for
_SC_GETPW_R_SIZE_MAX
Chris, I don't understand your changes in getpwuid_r32.
The uid and
Robert Collins wrote:
On Wed, 2003-01-01 at 11:45, Charles Wilson wrote:
[...but I can't reproduce the fault on linux. Even if I link in
dlmalloc. Bleah. ElectricFence on linux couldn't find anything
suspicious either.]
You might try valgrind. valgrind is *good*.
Oh dear. What're
Steven O'Brien wrote:
Hi
I found a possible glib buffer overflow that is cygwin-specific (due to
a bug in cygwin perhaps?) that I worked around when porting glib-1.2.10
to cygwin. Maybe this is still a problem in glib-2.0.x
From (hazy) memory, the buffer is 64 bytes, so if your /etc/passwd
Christopher Faylor wrote:
On Wed, Jan 01, 2003 at 12:19:52PM -0500, Pierre A. Humblet wrote:
On Wed, Jan 01, 2003 at 10:05:10AM +, Steven O'Brien wrote:
In glib-1.2.10, gutils.c: g_get_any_init (void), the current user
details are obtained from /etc/passwd. This code is called as part of
On Wed, Jan 01, 2003 at 04:13:42PM -0500, Pierre A. Humblet wrote:
On Wed, Jan 01, 2003 at 02:48:54PM -0500, Christopher Faylor wrote:
I've uploaded a new snapshot which should correctly calculate the
buffer size for overflow conditions and returns a large number for
_SC_GETPW_R_SIZE_MAX
Chris, I
At 07:01 PM 1/1/2003 -0500, Christopher Faylor wrote:
Oops. You're right. So, the only potential problem is that the getpw
routines aren't thread safe. There is a window during the passwd info
resides in a static structure.
You are right, the routines are not thread safe. However everything
Turns out, the problem IS in newlib.
First, create a buffer of the appropriate length:
buffer = g_new (gchar, g_printf_string_upper_bound (format, args1));
And then format the data into that buffer.
vsprintf (buffer, format, args2);
But the buffer isn't long enough, so the actual problem is
On Wed, Jan 01, 2003 at 11:36:49PM -0500, Charles Wilson wrote:
Turns out, the problem IS in newlib.
You should probably post a synopsis in the newlib mailing list about
this if you think newlib is at fault.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:
On Thu, 2003-01-02 at 10:31, Charles Wilson wrote:
1) valgrind hasn't been ported to cygwin AFAIK. But it was fairly easy
to compile efence, given that helpful folks had previously posted
patches to the list. I've updated them to Bruce's 2.2.2 release, and
will publish them soon.
Christopher Faylor wrote:
On Mon, Dec 30, 2002 at 11:18:55PM -0500, Charles Wilson wrote:
If somebody with a debuggable cygwin kernel could look into this, I'd
appreciate it. I'll try to follow up on my own, but it takes FOREVER to
do a 'cvs update' on the cygwin source tree over a 28.8k
On Tue, Dec 31, 2002 at 09:43:50AM -0500, Charles Wilson wrote:
Did gcc (pre 3.2) automatically initialize data to 0, while gcc-3.2 does
not? Hmmm...waitaminute, I do have gcc2 installed...
If gcc/ld is not initializing static data to zero then there are some
pretty serious problems. Neither
Christopher Faylor wrote:
On Tue, Dec 31, 2002 at 09:43:50AM -0500, Charles Wilson wrote:
Did gcc (pre 3.2) automatically initialize data to 0, while gcc-3.2 does
not? Hmmm...waitaminute, I do have gcc2 installed...
If gcc/ld is not initializing static data to zero then there are some
Charles Wilson wrote:
Then, configure, make. It passes all tests but one, and I *think* that
one is actually a bug in cygwin's malloc routine. But I am NOT sure
about that.
test results:
==
string-test: FAIL
dies in this test:
g_string_sprintf (string2,
If somebody with a debuggable cygwin kernel could look into this, I'd
appreciate it. I'll try to follow up on my own, but it takes FOREVER to
do a 'cvs update' on the cygwin source tree over a 28.8k modem...
Sigh. Finally built a debuggable cygwin from current CVS. Here's the
stacktrace
On Mon, Dec 30, 2002 at 11:18:55PM -0500, Charles Wilson wrote:
If somebody with a debuggable cygwin kernel could look into this, I'd
appreciate it. I'll try to follow up on my own, but it takes FOREVER to
do a 'cvs update' on the cygwin source tree over a 28.8k modem...
Sigh. Finally built
23 matches
Mail list logo
