Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: swamp-dog AT ntlworld DOT com (Guy Harrison) To: Subject: Re: BUG - Cygwin to GNU CC compatibility Date: Tue, 06 Aug 2002 23:48:06 GMT Message-ID: <3d505fa0.21340736@smtp.ntlworld.com> References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g76Nnha09537 On Tue, 06 Aug 2002 00:58:18 +0000, "Arash Partow" wrote: >Hi Ernest, > > >>If your program runs on a bunch of systems, well, you're just lucky, >>because the bugs are in your code, not in cygwin. >i doubt the efforts of the cygwin group can surpass those of borland >and GCC and now after recieving your mail visual c++ >It seems that all these systems can produce perfectly running >executables, running both on linux, solaris and windows. > >I don't think there is any luck involved in this, there is a bug and it >needs to be fixed. out of the 4 compilers i compiled this code on only >cygwin was the one to fail. Covered later. >>You've provided a >>constructor (whitespace edited to make this email shorter) >> >>DigitList::DigitList(DigitList const &diglst) { >> *this = diglst; >>}; >> >this is a perfectly valid copy constructor. No. This is... DigitList::DigitList(DigitList const &diglst) : listSize (diglst.listSize), digitList (diglst.digitList) { }; You coded "*this=diglst" and got... DigitList::DigitList(DigitList const &diglst) //memcpy(&listSize,&diglst,sizeof listSize) //memcpy(&digitList,&diglst.digitList,sizeof digitList) { this->operator=(diglst); //memcpy(this,&diglst,sizeof *this) }; ...thereby initialising it wrongly *twice*. It "worked" only because 'listSize,digitList' are both simple datatypes so a bitwise (ie "shallow") copy will do: coupled with the fact there were no subclasses involved - had there been it'd not worked at all. Probably you don't believe me. Add this declaration to DigitList.h ... DigitList & operator=(const DigitList&); ...after all if it ain't being used it won't matter a jot will it? Tip: make a code stub of declarations and use them as a basis for all class code you write... foo(); foo(const foo&); foo& operator=(const foo&); foo operator=(const foo&) const; //etc ...prevents the compiler doing things automatically for you! >>which just invokes, implicitly, the default copy constructor. This >>default copy constructor would look something like this: >> >>DigitList::DigitList(DigitList &diglst) { >> this.digitList = diglist.digitList; // *** This line >> this.listSize = diglist.listSize; >>} > >when you do the copy constructor the whole object and its variable >contents is copied automaically no need for any of the stuff you >just wrote. Hurrah! Let's delete all that STL header junk. >>The line I've marked with a *** is the trouble maker -- it makes an >>alias for the pointer member digitList (which is effectively an >>int*). When you copy a DigitList using this copy ctor, you get two >>DigitLists sharing a single digitList pointer. >> >The program does not any any way use any variable more than once, >not in the test that i have given you nor in the actuall class code. >So what you are saying is not possible, and hence if you think it >is occuring instead of writing about it, just give a simple answer >like on line so and so this is happening. if you give an example of >it then i will accept your argument :D Dealt with above and below. >>Now, in your dtor: >> >>DigitList::~DigitList() { >> listSize = 0; >> free(digitList); >>}; >> >>you free digitList. But if two objects sharing a digitList both delete >>the same pointer, then you've crossed over into the realm of undefined >>behaviour. > >no two objects are using digitList, hence no crossing over into the >twilight-zone. > > >>The implementation is allowed to do anything now: it can >>keep running without a problem, it can crash (as cygwin's newlib is >>apparently doing) or it can send dirty pictures of itself to the >>White House. > >mmmmm.... > > > >>Anyway, so you should THANK cygwin for finding the bugs in your >>code. > >I found a bug in cygwin not the other way round. it can't handle >not initialised object parameter passing or something else. > >>BTW, 1) why are you using free and malloc instead of new and >>delete, anyway? >if you actually looked at the code, malloc was used for the >initialisation of a structure not a class, i don't know where you >come from but on earth we use malloc to initialise and structure >on memory according to its size. C++ "struct foo{}" == "class foo{}" but default public instead of private. C++ memory management is done via new/delete not via the C ones - how on earth, to use your own phrase, is C supposed to know about features in a language that came after it? >>and 2) Why are you writing a class like DigitList in the >>first place -- why not simply use a vector? and >becuase its my prerogative to write such a class, i do not >want to use the stl. > >>3) I've only pointed out ONE of your memory management bugs. There are >>plenty more in this code. > >feel free to point out more if you can find any, i will continue issue >this as a bug to cygwin. >until either a patch comes along or someone can explain why it works >on every other os and compiler It doesn't. I already knew this but as you insist the fault is peculiar to cygwin I checked anyway just to see specifically how it would fail. Builder v3 -> dies in malloc (inevitable: data already corrupted as 10 seconds in the debugger plainly shows *prior* to the failure). v5 -> won't even compile it. Easily fixed (sideshow issue of namespacing std::cout) but implies you've been fiddling with options or not submitted identical code. Warnings are more important than errors. Nevertheless, here we have not a problem in malloc() - nope. Catastrophic stack failure exiting from... DigitList::DigitList(int intlist[], int listsize) ...(typically indicative of borlandmm corruption against an RTL link. Tends to manifest less catastrophically on a static link - likely what you used in v6.). >except for when its compiled by cygwin. I have a horrible feeling you're not going to let this rest without proof. Here it is... Error 00016. 0x310030 (Thread 0x00CF): Reference to freed resource: free(0x00BE3328) Call Tree: 0x00404186(=Main.exe:0x01:003186) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#75 0x00404841(=Main.exe:0x01:003841) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#30 0x0040450A(=Main.exe:0x01:00350A) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#18 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) The memory block (0x00BE3328) [size: 12 bytes] was allocated with malloc Call Tree: 0x00403FD7(=Main.exe:0x01:002FD7) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#45 0x004044F2(=Main.exe:0x01:0034F2) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#18 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) The memory block (0x00BE3328) was freed with free Call Tree: 0x00404186(=Main.exe:0x01:003186) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#75 0x00404308(=Main.exe:0x01:003308) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#130 0x004047F9(=Main.exe:0x01:0037F9) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#26 0x0040450A(=Main.exe:0x01:00350A) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#18 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) ------------------------------------------ Error 00017. 0x310030 (r) (Thread 0x00CF): Reference to freed resource: free(0x00BE3348) Call Tree: 0x00404186(=Main.exe:0x01:003186) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#75 0x00404841(=Main.exe:0x01:003841) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#30 0x00404551(=Main.exe:0x01:003551) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#19 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) The memory block (0x00BE3348) [size: 12 bytes] was allocated with malloc Call Tree: 0x00403FD7(=Main.exe:0x01:002FD7) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#45 0x00404539(=Main.exe:0x01:003539) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#19 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) The memory block (0x00BE3348) was freed with free Call Tree: 0x00404186(=Main.exe:0x01:003186) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#75 0x00404308(=Main.exe:0x01:003308) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#130 0x004047F9(=Main.exe:0x01:0037F9) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#26 0x00404551(=Main.exe:0x01:003551) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#19 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) ------------------------------------------ Error 00018. 0x310030 (r) (Thread 0x00CF): Reference to freed resource: free(0x00BE3368) Call Tree: 0x00404186(=Main.exe:0x01:003186) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#75 0x00404841(=Main.exe:0x01:003841) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#30 0x00404598(=Main.exe:0x01:003598) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#20 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) The memory block (0x00BE3368) [size: 12 bytes] was allocated with malloc Call Tree: 0x00403FD7(=Main.exe:0x01:002FD7) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#45 0x00404580(=Main.exe:0x01:003580) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#20 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) The memory block (0x00BE3368) was freed with free Call Tree: 0x00404186(=Main.exe:0x01:003186) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#75 0x00404308(=Main.exe:0x01:003308) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#130 0x004047F9(=Main.exe:0x01:0037F9) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#26 0x00404598(=Main.exe:0x01:003598) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#20 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) ------------------------------------------ Error 00019. 0x300010 (Thread 0x00CF): Resource leak: The object (0xBE31B4) was never deleted The object (0x00BE31B4) [size: 96 bytes] was created with new Call Tree: 0x0040630F(=Main.exe:0x01:00530F) J:\BCB\CB5\Include\rw/ctype.h#494 0x004061FD(=Main.exe:0x01:0051FD) J:\BCB\CB5\Include\rw/locimpl.h#454 0x004130F1(=Main.exe:0x01:0120F1) 0x004061C0(=Main.exe:0x01:0051C0) J:\BCB\CB5\Include\rw/usefacet.h#72 0x00406103(=Main.exe:0x01:005103) J:\BCB\CB5\Include\ios.h#375 0x0040AE5A(=Main.exe:0x01:009E5A) ------------------------------------------ Error 00020. 0x300010 (Thread 0x00CF): Resource leak: The object (0xBE36AC) was never deleted The object (0x00BE36AC) [size: 96 bytes] was created with new Call Tree: 0x0040630F(=Main.exe:0x01:00530F) J:\BCB\CB5\Include\rw/ctype.h#494 0x004061FD(=Main.exe:0x01:0051FD) J:\BCB\CB5\Include\rw/locimpl.h#454 0x004130F1(=Main.exe:0x01:0120F1) 0x004061C0(=Main.exe:0x01:0051C0) J:\BCB\CB5\Include\rw/usefacet.h#72 0x004095EF(=Main.exe:0x01:0085EF) 0x00409A35(=Main.exe:0x01:008A35) ------------------------------------------ Error 00021. 0x300010 (Thread 0x00CF): Resource leak: The memory block (0xBE3358) was never freed The memory block (0x00BE3358) [size: 12 bytes] was allocated with malloc Call Tree: 0x00404275(=Main.exe:0x01:003275) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#115 0x004047F9(=Main.exe:0x01:0037F9) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#26 0x00404551(=Main.exe:0x01:003551) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#19 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) ------------------------------------------ Error 00022. 0x300010 (Thread 0x00CF): Resource leak: The memory block (0xBE3378) was never freed The memory block (0x00BE3378) [size: 12 bytes] was allocated with malloc Call Tree: 0x00404275(=Main.exe:0x01:003275) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#115 0x004047F9(=Main.exe:0x01:0037F9) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#26 0x00404598(=Main.exe:0x01:003598) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#20 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) ------------------------------------------ Error 00023. 0x300010 (Thread 0x00CF): Resource leak: The memory block (0xBE3338) was never freed The memory block (0x00BE3338) [size: 12 bytes] was allocated with malloc Call Tree: 0x00404275(=Main.exe:0x01:003275) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\DigitList.cpp#115 0x004047F9(=Main.exe:0x01:0037F9) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\CounterBlock.cpp#26 0x0040450A(=Main.exe:0x01:00350A) H:\BCB\CB3\usr\exa\snippets\cygwin_bug\countertest.cpp#18 0x0040119B(=Main.exe:0x01:00019B) J:\BCB\CB5\usr\allcc\Main.cpp#19 0x0041D2F2(=Main.exe:0x01:01C2F2) ------------------------------------------ Functions called: sprintf (3 times) delete (21 times) write (9 times) lseek (21 times) fflush (13 times) delete[] (3 times) strchr (4 times) strstr (2 times) free (24 times) _lsetlocale (6 times) new[] (14 times) new (31 times) calloc (7 times) strlen (86 times) realloc (1 times) strdup (5 times) malloc (11 times) memcpy (10 times) Resource types used: object array (14 allocs, 13 max) object (31 allocs, 17 max) memory block (24 allocs, 13 max) Modules used: 00400000 08/06/2002 18:16:00 J:\BCB\CB5\usr\allcc\Main.exe ========================================== -- swamp-dog AT ntlworld DOT com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/