[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #23 from charlet at gcc dot gnu dot org 2008-05-20 12:44 --- Subject: Bug 24533 Author: charlet Date: Tue May 20 12:43:59 2008 New Revision: 135614 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135614 Log: 2008-05-20 Arnaud Charlet <[EMAIL PROTECTED]> * s-linux-hppa.ads (atomic_lock_t): Put back proper alignment now that the underlying issue with malloc/free has been fixed. Remove associated comments. Minor reformatting. Related to PR ada/24533 Modified: trunk/gcc/ada/s-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #22 from danglin at gcc dot gnu dot org 2007-09-30 16:26 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #21 from danglin at gcc dot gnu dot org 2006-01-20 14:34 --- Subject: Bug 24533 Author: danglin Date: Fri Jan 20 14:34:29 2006 New Revision: 110027 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110027 Log: PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Modified: branches/gcc-4_0-branch/gcc/ada/ChangeLog branches/gcc-4_0-branch/gcc/ada/s-osinte-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #20 from danglin at gcc dot gnu dot org 2006-01-20 14:32 --- Subject: Bug 24533 Author: danglin Date: Fri Jan 20 14:32:10 2006 New Revision: 110026 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110026 Log: PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/s-osinte-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #19 from danglin at gcc dot gnu dot org 2006-01-20 14:30 --- Subject: Bug 24533 Author: danglin Date: Fri Jan 20 14:30:33 2006 New Revision: 110025 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110025 Log: PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #18 from charlet at adacore dot com 2006-01-17 16:33 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > I'll let Arno state the definite approval. As discussed live, I gave my OK this morning already, with the same comment about ??? ;-) Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #17 from hainque at adacore dot com 2006-01-17 16:29 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** John David Anglin wrote: > As I understand the situation, fixing the above problem is quite involved. Indeed. I have dug out the patches involved when this was first attempted, and look into them again. This was back in June 2004, so a lot has changed since then. > The problem is that the alignment provided by malloc is less than > that needed for atomic_lock_t objects. This causes the ada runtime > to round the pointer that it receives from malloc; but it doesn't > retain the adjustment and the free operation has a 50% chance of > failing. Close :) The problem as it currently stands is that the alignment required for atomic_lock_t is larger than BIGGEST_ALIGNMENT, which causes the compiler to generate special code to handle an allocation request from the default storage pool (aka bare malloc). Indeed the generated code arranges for the user visible address (the Ada allocator value) to be a multiple of the requested alignment by rounding up the malloc returned address, and the rounded value is erroneously passed back to free on deallocation request. > The enclosed change is a work-around for the above problem. > The linux libc code can accomodate an unaligned atomic_lock_t object > under most circumstances. The main issue is that ada may detemine > an incorrect struct layout. > > I have tested the above change on hppa-unknown-linux-gnu, 4.0 through > trunk. Without this change, ada is essentially unusable. Thus, I > recommend installing the change as a work-around until a proper fix > can be developed. > > OK? > - for atomic_lock_t'Alignment use 16; > + for atomic_lock_t'Alignment use 8; Since it definitely enhances the situation according to your testing (thanks), I'd go for it with a "???" accompaning comment. I'll let Arno state the definite approval. It is not easy to ensure it is really OK because of ripple effects. It appears fine from the local osinte perspective: << type lock_array is array (1 .. 4) of int; type atomic_lock_t is record lock : lock_array; end record; >> The base size is 16 bytes, and wouldn't change from an alignment upgrade to 16. << type struct_pthread_fast_lock is record spinlock : atomic_lock_t; >> The field is at beginning here so there is no offset rounding mistake to fear, and the size is right so following fields are laid out identically. Besides, in << type pthread_mutex_t is record m_reserved : int; m_count: int; m_owner: System.Address; m_kind : int; m_lock : struct_pthread_fast_lock; end record; >> the m_lock offset is a multiple of 16 here by virtue of the preceeding components (4 all 4 bytes long). Now, I think a 16 bytes alignment for atomic_lock_t would force a 16 bytes alignment for struct_pthread_fast_lock + pthread_mutex_t, and double checking the potential effects of that is fairly involved. Thanks for your feedback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #16 from charlet at adacore dot com 2006-01-17 08:56 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > OK? Assuming you add a proper "???" comment explaining why we use an alignment of 8 in this file (basically summarizing this PR), this is OK. > 2006-01-16 John David Anglin <[EMAIL PROTECTED]> > > PR ada/24533 > * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. > > Index: s-osinte-linux-hppa.ads > === > --- s-osinte-linux-hppa.ads (revision 109788) > +++ s-osinte-linux-hppa.ads (working copy) > @@ -508,7 +508,7 @@ >lock : lock_array; > end record; > pragma Convention (C, atomic_lock_t); > - for atomic_lock_t'Alignment use 16; > + for atomic_lock_t'Alignment use 8; > > type struct_pthread_fast_lock is record >spinlock : atomic_lock_t; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
> OK? Assuming you add a proper "???" comment explaining why we use an alignment of 8 in this file (basically summarizing this PR), this is OK. > 2006-01-16 John David Anglin <[EMAIL PROTECTED]> > > PR ada/24533 > * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. > > Index: s-osinte-linux-hppa.ads > === > --- s-osinte-linux-hppa.ads (revision 109788) > +++ s-osinte-linux-hppa.ads (working copy) > @@ -508,7 +508,7 @@ >lock : lock_array; > end record; > pragma Convention (C, atomic_lock_t); > - for atomic_lock_t'Alignment use 16; > + for atomic_lock_t'Alignment use 8; > > type struct_pthread_fast_lock is record >spinlock : atomic_lock_t;
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-17 03:49 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > --- Comment #8 from hainque at adacore dot com 2006-01-03 16:25 --- > Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: > 0x00062a00 *** > Right. Preliminary attempts at fixing this a while ago made it necessary > to touch expand_expr and is_alignin_offset, fairly deep in the back end. As I understand the situation, fixing the above problem is quite involved. When the parisc-linux project moved to libc6 2.3.5, free was changed and the above error changed. The enclosed change is a work-around for the above problem. The problem is that the alignment provided by malloc is less than that needed for atomic_lock_t objects. This causes the ada runtime to round the pointer that it receives from malloc; but it doesn't retain the adjustment and the free operation has a 50% chance of failing. The linux libc code can accomodate an unaligned atomic_lock_t object under most circumstances. The main issue is that ada may detemine an incorrect struct layout. I have tested the above change on hppa-unknown-linux-gnu, 4.0 through trunk. Without this change, ada is essentially unusable. Thus, I recommend installing the change as a work-around until a proper fix can be developed. OK? Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) 2006-01-16 John David Anglin <[EMAIL PROTECTED]> PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Index: s-osinte-linux-hppa.ads === --- s-osinte-linux-hppa.ads (revision 109788) +++ s-osinte-linux-hppa.ads (working copy) @@ -508,7 +508,7 @@ lock : lock_array; end record; pragma Convention (C, atomic_lock_t); - for atomic_lock_t'Alignment use 16; + for atomic_lock_t'Alignment use 8; type struct_pthread_fast_lock is record spinlock : atomic_lock_t; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #14 from charlet at adacore dot com 2006-01-04 11:54 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > So my question is wether the record+storage array+align will work for all > the C types in s-osinte* or is there an exception (ie a non opaque C type)? Now I understand your question ;-) The answer is no, this approach can't be applied blindly to all C types. This approach could most likely be applied on some platforms to all the *private* C types, although this is not a good idea because the current files are written to be used on many architectures (e.g. s-osinte-hpux.ads can be used under both pa and ia64), so this approach would simply break it (System.Address has a different size under pa and ia64, and the default alignments are very different from one architecture/ABI to the other). That's why I said a few times already that creating s-osinte-linux-.ads files was not a good idea and that a clean up will need to be done at some point to merge back those files. Your suggestion would simply go one step further in making this task close to impossible instead of difficult. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
> So my question is wether the record+storage array+align will work for all > the C types in s-osinte* or is there an exception (ie a non opaque C type)? Now I understand your question ;-) The answer is no, this approach can't be applied blindly to all C types. This approach could most likely be applied on some platforms to all the *private* C types, although this is not a good idea because the current files are written to be used on many architectures (e.g. s-osinte-hpux.ads can be used under both pa and ia64), so this approach would simply break it (System.Address has a different size under pa and ia64, and the default alignments are very different from one architecture/ABI to the other). That's why I said a few times already that creating s-osinte-linux-.ads files was not a good idea and that a clean up will need to be done at some point to merge back those files. Your suggestion would simply go one step further in making this task close to impossible instead of difficult. Arno
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #13 from laurent at guerby dot net 2006-01-04 11:45 --- (In reply to comment #12) > > Arnaud, do you remember non opaque C types in s-osinte? > > I do not understand your question, could you clarify ? "opaque" means that the Ada runtime never access an internal C record component, or does not use knowledge that something is an int and do +1 on it for example. So my question is wether the record+storage array+align will work for all the C types in s-osinte* or is there an exception (ie a non opaque C type)? Laurent -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #12 from charlet at adacore dot com 2006-01-04 09:58 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > For most (if not all) s-osinte*.ads C type redeclarations, I believe it should > be sufficient to use a record containing a > System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an > alignement clause (I don't know if C or GNU C allows to retrieve the alignment > of a struct like sizeof for size). If you use a storage_array, you definitely also need the proper alignment clause, yes. > Arnaud, do you remember non opaque C types in s-osinte? I do not understand your question, could you clarify ? Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
> For most (if not all) s-osinte*.ads C type redeclarations, I believe it should > be sufficient to use a record containing a > System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an > alignement clause (I don't know if C or GNU C allows to retrieve the alignment > of a struct like sizeof for size). If you use a storage_array, you definitely also need the proper alignment clause, yes. > Arnaud, do you remember non opaque C types in s-osinte? I do not understand your question, could you clarify ? Arno
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #11 from laurent at guerby dot net 2006-01-03 19:36 --- (In reply to comment #7) > There's only one fail in 4.0.3: > > http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00025.html > > RUN cxg1005 > > ,.,. CXG1005 ACATS 2.5 06-01-01 01:38:37 > CXG1005 Check that the subprograms defined in the package > Generic_Complex_Elementary_Functions provide correct > results. >* CXG1005 Non-imaginary result from Function Log with a minus one > input value. >* CXG1005 Non-real result from Function Arcsin with a minus one input > value. >* CXG1005 Non-real result from Function Arccos with a minus one input > value. > CXG1005 FAILED . > FAIL: cxg1005 > > I checked the first issue in C and clog(-1.0) seems ok. > > Dave > This is PR20754 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754 I'm adding some comments there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-03 19:31 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > > > > --- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 --- > For most (if not all) s-osinte*.ads C type redeclarations, I believe it should > be sufficient to use a record containing a > System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an > alignement clause (I don't know if C or GNU C allows to retrieve the alignment > of a struct like sizeof for size). GNU C does, __alignof__ (struct a). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
> > > > --- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 --- > For most (if not all) s-osinte*.ads C type redeclarations, I believe it should > be sufficient to use a record containing a > System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an > alignement clause (I don't know if C or GNU C allows to retrieve the alignment > of a struct like sizeof for size). GNU C does, __alignof__ (struct a). -- Pinski
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 --- For most (if not all) s-osinte*.ads C type redeclarations, I believe it should be sufficient to use a record containing a System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an alignement clause (I don't know if C or GNU C allows to retrieve the alignment of a struct like sizeof for size). Arnaud, do you remember non opaque C types in s-osinte? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #8 from hainque at adacore dot com 2006-01-03 16:25 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** charlet at adacore dot com wrote: > Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Yes, the latter is 8, computed from GCC's BIGGEST_ALIGNMENT. > Is it really the case that the C headers mandate an alignment of 16 for this > type which is not guaranteed by malloc ? IIUC, it asks for a 16 bytes alignment consciously knowing that it likely won't get it in terms of objects' _addresses_. Now the request will still impact component _offsets_ within records (make them multiple of 16), as Dave points out, and not matching it in Ada might indeed cause various troubles. The big difference between Ada and C here is that the alignment must also be obeyed for objects addresses in Ada, which is why the allocator return address is rounded up (together with the size argument). > > If ada is going to align malloc'd pointers, then it should keep track > > of the adjustment or the original pointer so that the memory can be > > freed using the original pointer. > > Right, and this is a non trivial task, hence my previous comment. Right. Preliminary attempts at fixing this a while ago made it necessary to touch expand_expr and is_alignin_offset, fairly deep in the back end. Will look it up again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
charlet at adacore dot com wrote: > Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Yes, the latter is 8, computed from GCC's BIGGEST_ALIGNMENT. > Is it really the case that the C headers mandate an alignment of 16 for this > type which is not guaranteed by malloc ? IIUC, it asks for a 16 bytes alignment consciously knowing that it likely won't get it in terms of objects' _addresses_. Now the request will still impact component _offsets_ within records (make them multiple of 16), as Dave points out, and not matching it in Ada might indeed cause various troubles. The big difference between Ada and C here is that the alignment must also be obeyed for objects addresses in Ada, which is why the allocator return address is rounded up (together with the size argument). > > If ada is going to align malloc'd pointers, then it should keep track > > of the adjustment or the original pointer so that the memory can be > > freed using the original pointer. > > Right, and this is a non trivial task, hence my previous comment. Right. Preliminary attempts at fixing this a while ago made it necessary to touch expand_expr and is_alignin_offset, fairly deep in the back end. Will look it up again.
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03 15:49 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Unfortunately, yes. The fundamental issue is that "ldcw" is the only atomic memory operation available in PA 1.x, and it requires a 16-byte alignment. In PA 2.0, this is relaxed to 4-byte alignment when the operation is coherent. The linux folks weren't willing to to throw out their PA 1.1 hardware, so we have this 16-byte alignment... > Is it really the case that the C headers mandate an alignment of 16 for this > type which is not guaranteed by malloc ? These alignment issues are > very tricky, and GCC also has several notions of maximum alignments, so > this are is definitely of that is causing many troubles with Ada when using > GCC 3.x or 4.x Agreed. Because of these issues, I came up with the scheme to make the size of the atomic_lock_t type 16 bytes. The pthread code dynamically picks the aligned 4-byte integer for the ldcw. Thus, the atomic_lock_t type now only needs 4-byte alignment. However, the 16-byte alignment attribute was retained for compatibility. There are some limitations to this scheme and I think the TLS thread implementation will do locking with a light-weight syscall rather than ldcw. This might reduce the alignment requirement to 4 bytes. > Ada does not do anything with these directly, so things should be OK, > except that it's easy to get a subtle alignment issue/discrepency. > > > If ada is going to align malloc'd pointers, then it should keep track > > of the adjustment or the original pointer so that the memory can be > > freed using the original pointer. > > Right, and this is a non trivial task, hence my previous comment. Ok, then I think the alignment should be reduced to 4 or 8. I've done a number of builds using an alignment of 8. There's only one fail in 4.0.3: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00025.html RUN cxg1005 ,.,. CXG1005 ACATS 2.5 06-01-01 01:38:37 CXG1005 Check that the subprograms defined in the package Generic_Complex_Elementary_Functions provide correct results. * CXG1005 Non-imaginary result from Function Log with a minus one input value. * CXG1005 Non-real result from Function Arcsin with a minus one input value. * CXG1005 Non-real result from Function Arccos with a minus one input value. CXG1005 FAILED . FAIL: cxg1005 I checked the first issue in C and clog(-1.0) seems ok. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #6 from charlet at adacore dot com 2006-01-03 15:10 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > and it doesn't fix the invalid tcb pointers being passed to free(). > Reducing the alignment to 8, fixes the pointer problem. This will > work from a locking standpoint, but it's not correct from a struct > layout standpoint. However, it might be ok depending on how ada uses > atomic_lock_t objects. Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Is it really the case that the C headers mandate an alignment of 16 for this type which is not guaranteed by malloc ? These alignment issues are very tricky, and GCC also has several notions of maximum alignments, so this are is definitely of that is causing many troubles with Ada when using GCC 3.x or 4.x Ada does not do anything with these directly, so things should be OK, except that it's easy to get a subtle alignment issue/discrepency. > If ada is going to align malloc'd pointers, then it should keep track > of the adjustment or the original pointer so that the memory can be > freed using the original pointer. Right, and this is a non trivial task, hence my previous comment. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03 15:03 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** > The alignment clause takes *bytes*, not *bits*, so you need to use instead: > >for atomic_lock_t'Alignment use 16; > > The inconsistency between new and free for objects aligned more than > Standard'Maximum_Alignment is indeed a known latent issue that > is being worked on and is not trivial to fix, but should not affect the Ada > run-time itself (except when a wrong clause is defined as was the case here). > > Change suggested above pre-approved. This has been done 2005-12-28 John David Anglin <[EMAIL PROTECTED]> * s-osinte-linux-hppa.ads: Correct alignment of atomic_lock_t. and it doesn't fix the invalid tcb pointers being passed to free(). Reducing the alignment to 8, fixes the pointer problem. This will work from a locking standpoint, but it's not correct from a struct layout standpoint. However, it might be ok depending on how ada uses atomic_lock_t objects. If ada is going to align malloc'd pointers, then it should keep track of the adjustment or the original pointer so that the memory can be freed using the original pointer. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #4 from charlet at gcc dot gnu dot org 2006-01-03 13:28 --- The bug is that the following line in s-osinte-linux-hppa.ads is wrong: for atomic_lock_t'Alignment use 8 * 16; The alignment clause takes *bytes*, not *bits*, so you need to use instead: for atomic_lock_t'Alignment use 16; The inconsistency between new and free for objects aligned more than Standard'Maximum_Alignment is indeed a known latent issue that is being worked on and is not trivial to fix, but should not affect the Ada run-time itself (except when a wrong clause is defined as was the case here). Change suggested above pre-approved. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01 17:11 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** I've looked at the failure of a85013b.adb. The problem seems to be that "new" is applying a kind of rounding to the pointer returned by malloc. Then, the rounded pointer is used for the call to free. This is the cause of the invalid pointer error and the test being aborted by free(). The rounding occurs in this function: -- -- New_ATCB -- -- function New_ATCB (Entry_Num : Task_Entry_Index) return Task_Id is begin return new Ada_Task_Control_Block (Entry_Num); end New_ATCB This is the assembly code (-O0): (gdb) disass Dump of assembler code for function system.task_primitives.operations.new_atcb: 0x0003186c : stw rp,-14(,sp) 0x00031870 : copy r3,r1 0x00031874 : copy sp,r3 0x00031878 : stw,ma r1,40(,sp) 0x0003187c : stw r4,8(,r3) 0x00031880 : stw r26,-24(,r3) 0x00031884 : ldw -24(,r3),ret0 0x00031888 : cmpiclr,< 0,ret0,r0 0x0003188c : ldi 0,ret0 0x00031890 : depw,z ret0,28,29,ret0 0x00031894 : ldo 757(ret0),ret0 0x00031898 : depwi 0,31,4,ret0 0x0003189c : ldo 10(ret0),ret0 0x000318a0 : copy ret0,r26 ---Type to continue, or q to quit--- 0x000318a4 : b,l 0x2e438 <__gnat_malloc>,rp 0x000318a8 : nop 0x000318ac : copy ret0,r20 0x000318b0 : copy r20,ret0 0x000318b4 : sub r0,ret0,ret0 0x000318b8 : extrw,u ret0,31,4,r19 0x000318bc : copy r20,ret0 0x000318c0 : add,l ret0,r19,ret0 0x000318c4 : copy ret0,r4 0x000318c8 : copy r4,ret0 0x000318cc : copy ret0,r26 0x000318d0 :ldw -24(,r3),r25 0x000318d4 :b,l 0x32698 ,rp 0x000318d8 :nop 0x000318dc :copy r4,ret0 0x000318e0 :ldw -14(,r3),rp 0x000318e4 :ldw 8(,r3),r4 ---Type to continue, or q to quit--- 0x000318e8 :ldo 40(r3),sp 0x000318ec :ldw,mb -40(,sp),r3 0x000318f0 :bv,n r0(rp) End of assembler dump(gdb) bt #0 0x000318cc in system.task_primitives.operations.new_atcb (entry_num=1) at s-taprop.adb:752 #1 0x000512f8 in system.tasking.stages.create_task (priority=-1, size=-2147483648, task_info=default_scope, num_entries=1, master=4, state=0xc068c746, discriminants=3228092176, elaborated=0xc068c714, chain=, task_image=0x5edf4, created_task=0x0) at s-tassta.adb:574 #2 0x00055498 in a85013b__tTKVIP___789 () at a85013b.adb:65 #3 0x000551c8 in a85013b () at a85013b.adb:65 #4 0x00014d84 in main () (gdb) p $r19 $8 = 8 (gdb) p $r20 $9 = 562904 (gdb) p $ret0 $10 = 562912 The value in r20 is the result that was returned in ret0 in the call to __gnat_malloc. The value in $ret0 at this point is the value that system.task_primitives.operations.new_atcb returns and is subsequently used in the call to free(). I don't know ada well enough to know where this bit of code comes from 0x000318b0 : copy r20,ret0 0x000318b4 : sub r0,ret0,ret0 0x000318b8 : extrw,u ret0,31,4,r19 0x000318bc : copy r20,ret0 0x000318c0 : add,l ret0,r19,ret0 but it appears to round the address returned by malloc up to a 16-byte boundary. The rounded address is used in the call to free. This is undefined: free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Other- wise, or if free(ptr) has already been called before, undefined behaviour occurs. It seems that the 16-byte alignment used for TCBs is a result of using 16-byte alignment for atomic_lock_t. Changing the alignment to 8 fixes the testsuite failures. The current glibc implementation handles lock objects that aren't aligned to 16-byte boundaries by dynamically picking an aligned lock word: /* We need 128-bit alignment for the ldcw semaphore. At most, we are assured of 64-bit alignment for stack locals and malloc'd data. Thus, we use a struct with four ints for the atomic lock type. The locking code will figure out which of the four to use for the ldcw semaphore. */ typedef volatile struct { int lock[4]; } __attribute__ ((aligned(16))) __atomic_lock_t; It's unclear to me whether changing the alignment for atomic_lock_t in s-osinte-linux-hppa.ads is correct as it changes struct layouts, and could cause problems if an object containing an atomic_lock_t object is copied. It is clear that the pointer returned by malloc must be retained for the free operation. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #2 from danglin at gcc dot gnu dot org 2005-10-26 04:00 --- The same errors occur on the 4.0 branch using libc6 2.3.5-6.0.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #1 from danglin at gcc dot gnu dot org 2005-10-26 02:45 --- Oops, somehow how ended up debugging in the wrong directory. However, it has the same error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533