Error in g++ library, function ___builtin_vec_new

James Kanze f981500@FFZJ0LX0.bank.dresdner.net
Fri Jan 28 02:04:00 GMT 2000


I've encountered an error in the default implementation of
___builtin_vec_delete in the C++ library.  From disassembly, it appears
that this function calls free to free the memory, rather than operator
delete, as is required by the standard.  

Independantly of the standard, this is an error, because
___builtin_vec_new calls operator new -- calling free to free memory
allocated by operator new is undefined behavior.  In this particular
case, the implementation cannot even legally define the behavior, since
the user is allowed to replace the default operator new and operator
delete with his own versions.  (I encountered the error because I do
precisely this -- I use a debugging version of operator new and operator 
delete which tracks allocations, to detect memory leaks, multiple
deletes, etc.)

I've appended two programs which show the error: the first results in a
memory leak, and the second crashes (at least under Windows NT).

I'm using Mumit Kahn's Windows port of gcc 2.95, under Windows NT 4.0 --
I seriously doubt that the problem has anything to do with the port,
however.

There is a simple work-around: any time you provide a user defined
operator new and operator delete, also provide a user defined operator
new[] and operator delete[].  Please see the commented out code in my
examples.

I know you are working on a new implementation of the standard library.
Given that there is a simple work-around, you may not wish to invest the
effort in fixing the old library.  In this case, you should at least add
a test for this case in the test suite of the new library.


Compiler invocation and output:

|> k:/.../util/fiddle (3)> g++ -v bug1.cc
|> g++ -v bug1.cc
|> Reading specs from /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/specs
|> gcc version 2.95 19990728 (release)
|>  /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/cpp.exe -lang-c++ -v -iprefix /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/ -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Di386 -D_WIN32 -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386__ -D_WIN32 -D__WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386 -D__WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di586 -Dpentium -D__i586 -D__i586__ -D__pentium -D__pentium__ -D__CYGWIN32__ -D__CYGWIN__ bug1.cc c:\tmp/ccMraaaa.ii
|> GNU CPP version 2.95 19990728 (release) (80386, BSD syntax)
|> #include "..." search starts here:
|> #include <...> search starts here:
|>  /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../../include/g++-3
|>  /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../../include
|>  /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/include
|>  /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/include
|> End of search list.
|> The following default directories have been omitted from the search path:
|>  /usr/include
|> End of omitted list.
|>  /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/cc1plus.exe c:\tmp/ccMraaaa.ii -quiet -dumpbase bug1.cc -version -o c:\tmp/ccoJaaaa.s
|> GNU C++ version 2.95 19990728 (release) (i586-cygwin32) compiled by GNU C version 2.95 19990728 (release).
|>  /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/bin/as.exe -o c:\tmp/cc00aaaa.o c:\tmp/ccoJaaaa.s
|>  /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/collect2.exe /Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/lib/crt0.o -L/Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95 -L/Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib -L/Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/lib -L/Program/Cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../.. c:\tmp/cc00aaaa.o -lstdc++ -lm -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc

Compling bug2.cc results in the same.

Program output, running bug1:

|> k:/.../util/fiddle (4)> a
|> a
|> int allocated
|> int deleted
|> Blocks still allocated: 0 (should be 0)
|> int[] allocated
|> int[] deleted
|> Blocks still allocated: 1 (should be 0)

The last line is incorrect, according to the standard.

running bug2:

|> k:/.../util/fiddle (6)> a
|> a
|> int allocated
|> int deleted
|> int[] allocated
|> [main] k:\libs\util\fiddle\a.exe 1119 (0) handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
|> [main] a 1119 (1) handle_exceptions: Dumping stack trace to a.exe.core

There should be no core dump, according to the standard.

Please feel free to contact me for any additional information.

Sample programs (uuencoded, gzipped tar file):

begin 644 bugs.tar.gz
M'XL(`,%HD3@``^U7W4_;,!#G.7_%B0DII;0D_6*CM!+;RR:AO?'$$$H3M[5(
M[,AVQEC5_WUGNTW3#Z:)J6,(WT/<WIU_]^&3[SPJ)F$SC@_V26$0]#H=.`C:
MK:`3X!JV>KTVKI9:8;<'P5G0Z;1Z[;-6""AO=[L'$.S5JP454D4"71E_>!]V
M@Z=-%I((^1L<&PN4ZRLA[QUE<5HD!"ZD2BAO3H>PDTY/X?([IPE$[!$8>3A-
M2$H4`<J`<JD$B;)UK)2.$*S"*QA%]CH/@8:>AT>@:(Q0:F4O2E,>?^(%\@80
M0-_SM/5CC^=$1(H+[8,/DOXD=\HL4`,U%1R9HRBY,]NAYLT\#6:V;@24(VYF
MU/SE_KY1IF/PM70`7Z^OKI!M,309`RM\?[EE;K[U>M5K*Q%$%8(A7-^;VQ!6
M$=@,^@OO\C*`I==C08AO^!:KT5C'1T`\%;AF,<\RPA1E$T0@,.:H]:#_Q1R3
M'$=8N])(<L$G(LI`<7C@XK[9;%H(FUK]JYK>F]L_2+#>-#/?2KCGY]O'9,+0
M>G/S+>VNF[4YT98WL@+^IJV*D64F\XH1#\O)RR+*RGPB8[,((*=8!NBC%OI8
M9\M<YX62/ASJDC211HHDAZ5T4?NX>4O;BBJZN4#V&*4?$>9>@E0T35>@YW"4
M@"^GO$@3&!$(:M_8(9Q43UHC>9O.WD`8P.V6_9O;I_U%V0Z/D;LGGRL%$=AR
M?>G;SM$FC8I)ZZ7[?[O3W>[_/=?__P7])_U?%+&"SXE8W-2HRAG,(.'%*"7P
M`_H03R-Q#(_X:^[M]A`;)A>7*9TPW0R7S;PZ4RQ(\HQ\86,N]:6D[]:]SQ\8
MV7;G*<,8@'7@+HZDNK#*0W]].*F;A>.=C&(T5?O[<25O#%>9&.#T\O3P4H?P
M^0/,SN"T<@-1:VZ.>2USS$L-'R4DVC]*3F`U=[3<V.'(D2-'SR77-]W[W[W_
?WRZY][][_[OWOWO_N_>_FV/<^__MT2]]M^@P`"```.'(
`
end


--
James Kanze                    mailto:James.Kanze@dresdner-bank.com
Conseils en informatique orientée objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


More information about the Gcc-bugs mailing list