On Thu, Aug 20, 2009 at 04:01:44PM +0100, Dave Korn wrote:
>Greg Chicares wrote:
>> On 2009-08-20 11:54Z, Dave Korn wrote:
>>> [...] (Hmm, now there's an idea. GCC needs an
>>> __attribute__ that you can tag onto a class to say it must be a POD-type and
>>> get a compiler error if anyone ever add
Greg Chicares wrote:
> On 2009-08-20 11:54Z, Dave Korn wrote:
>> [...] (Hmm, now there's an idea. GCC needs an
>> __attribute__ that you can tag onto a class to say it must be a POD-type and
>> get a compiler error if anyone ever adds a virtual function or anything else
>> that would make the lay
On 2009-08-20 11:54Z, Dave Korn wrote:
>
> [...] (Hmm, now there's an idea. GCC needs an
> __attribute__ that you can tag onto a class to say it must be a POD-type and
> get a compiler error if anyone ever adds a virtual function or anything else
> that would make the layout non-POD.)
http://gr
Oh, btw., please http://cygwin.com/acronyms/#PCYMTNQREAIYR
On Aug 20 13:19, Corinna Vinschen wrote:
> On Aug 20 18:23, Haojun Bao wrote:
> > Great. In fact, I also found this code myself might cause problem in path.h:
> > (we should test if path is NULL, and free it before the memcpy, and
> > o
Haojun Bao wrote:
> 215 path_conv &operator =(path_conv& pc)
> 216 {
> 217memcpy (this, &pc, sizeof pc);
Ow yuck! I very much hope nobody ever creates derived classes of path_conv
that introduce virtual functions into the base class, or we're going to have a
very tricky to find bug here.
On Aug 20 18:23, Haojun Bao wrote:
> On Thu, Aug 20, 2009 at 4:39 PM, Corinna
> Vinschen wrote:
> > On Aug 20 14:09, Haojun Bao wrote:
> >> I have done some debugging, and the culprit should be dup(2) syscall.
> >> Here's another test case, this time written in C.
> >>
> >> Note that the cygheap_st
On Thu, Aug 20, 2009 at 4:39 PM, Corinna
Vinschen wrote:
> On Aug 20 14:09, Haojun Bao wrote:
>> I have done some debugging, and the culprit should be dup(2) syscall.
>> Here's another test case, this time written in C.
>>
>> Note that the cygheap_start and cygheap_max value will be very likely
>>
On Aug 20 14:09, Haojun Bao wrote:
> I have done some debugging, and the culprit should be dup(2) syscall.
> Here's another test case, this time written in C.
>
> Note that the cygheap_start and cygheap_max value will be very likely
> different on your computer, so you should use gdb to take a pee
On Wed, Aug 19, 2009 at 11:04 PM, Haojun Bao wrote:
> On Wed, Aug 19, 2009 at 10:03 PM, Christopher
> Faylor wrote:
>> On Wed, Aug 19, 2009 at 07:47:37PM +0800, Haojun Bao wrote:
>>>I found this problem when running updatedb, the find will print
>>>
>>> 2 [main] find 2592 C:\cygwin\bin\find.ex
On Wed, Aug 19, 2009 at 07:47:37PM +0800, Haojun Bao wrote:
>I found this problem when running updatedb, the find will print
>
> 2 [main] find 2592 C:\cygwin\bin\find.exe: *** fatal error -
>cmalloc would have returned NULL
>
>I have dumped the cygheap using gdb to see what's in it, the size i
I found this problem when running updatedb, the find will print
2 [main] find 2592 C:\cygwin\bin\find.exe: *** fatal error -
cmalloc would have returned NULL
I have dumped the cygheap using gdb to see what's in it, the size is
about 25M, and I use strings.exe to examine the strings
in it, a
11 matches
Mail list logo
