> 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:
>
> http://cygwin.com/ml/cygwin-developers/2002-
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
^ ^
* *
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 d
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:
http://cygwin.com/ml/cygwin-developers/2002-12/msg00027.htm
On Thu, Jan 02, 2003 at 10:23:56AM +, Steven O'Brien wrote:
> 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 r
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 lo
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. (How
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:
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 *pr
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
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
>
>
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
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 entr
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 a
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 an
On Wed, Jan 01, 2003 at 12:34:45PM -0500, 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 obta
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
>> >glib initialisa
> 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 (_SC_GE
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:
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 /etc
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*.
Happy New Year.
Rob
--
---
GPG key availa
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
pretty
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 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 mode
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. Finall
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 fr
26 matches
Mail list logo
