Re: OpenJDK build attempts on the testing security infrastructure
Riku Voipio schrieb: > Also I notice the packages are built with ecj using the slowish gij > interpreter. perhaps the package build could be made faster by using > gcj precompiled ecj-gcj package? unfortunately this doesn't help; java-gcj-compat-dev already depends on ecj-gcj. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenJDK build attempts on the testing security infrastructure
On Sun, Oct 19, 2008 at 07:50:42PM +0200, Florian Weimer wrote: > Build times are generally acceptable, with the exception of armel, > which needed almost 45 hours. > armel is at about 19 hours, so almost acceptable. However, in > practice, this likely adds to the 45 hours of openjdk-6, resulting in > 64 hours of total build time, which is totally out of question. > Otherwise, the build times are fine. We (armel porters + debian system admins) are working on getting a Marvell Developer board[1], which seems to build packages approximately 2-3x faster than the current armel buildd's. My last night test build of openjdk-6 using this board took about 20h. Also I notice the packages are built with ecj using the slowish gij interpreter. perhaps the package build could be made faster by using gcj precompiled ecj-gcj package? [1] http://lists.debian.org/debian-arm/2008/07/msg00095.html -- "rm -rf" only sounds scary if you don't have backups signature.asc Description: Digital signature
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Mon, Oct 27, 2008 at 11:27 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: > I understand all that, but the question still stands: is the compiler > really moving a memory write past a memory barrier? ISTR we did have > a discussion on gcc-list about that, but it was a while ago and should > now be fixed. This issue no longer affects the PA port, but I can't speak for s390. The PA port is the only port for which I do regular gcc / glibc testing. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Carlos O'Donell wrote: > On Mon, Oct 27, 2008 at 10:05 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: >>> I've seen this on-and-off again on the hppa-linux port. The issue has, >>> in my experience, been a compiler problem. My standard operating >>> procedure is to methodically add volatile to the atomic.h operations >>> until it goes away, and then work out the compiler mis-optimization. >>> >>> The bug is almost always a situation where the lll_unlock is scheduled >>> before owner = 0, and the assert catches the race condition where you >>> unlock but have not yet cleared the owner. >> Are you sure this is a compiler problem? Unless you use explicit atomic >> memory accesses or volatile the compiler is supposed to re-order memory >> access. Perhaps I'm misunderstanding you. > > Sorry, parsing the above statement requires knowing something about > how lll_unlock is implemented in glibc. > > The lll_unlock function is supposed to be a memory barrier. > > The function is usually an explicit atomic operation, or a volatile > asm implementing the futex syscall i.e. INTERNAL_SYSCALL macro. I understand all that, but the question still stands: is the compiler really moving a memory write past a memory barrier? ISTR we did have a discussion on gcc-list about that, but it was a while ago and should now be fixed. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Mon, Oct 27, 2008 at 10:05 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: >> I've seen this on-and-off again on the hppa-linux port. The issue has, >> in my experience, been a compiler problem. My standard operating >> procedure is to methodically add volatile to the atomic.h operations >> until it goes away, and then work out the compiler mis-optimization. >> >> The bug is almost always a situation where the lll_unlock is scheduled >> before owner = 0, and the assert catches the race condition where you >> unlock but have not yet cleared the owner. > > Are you sure this is a compiler problem? Unless you use explicit atomic > memory accesses or volatile the compiler is supposed to re-order memory > access. Perhaps I'm misunderstanding you. Sorry, parsing the above statement requires knowing something about how lll_unlock is implemented in glibc. The lll_unlock function is supposed to be a memory barrier. The function is usually an explicit atomic operation, or a volatile asm implementing the futex syscall i.e. INTERNAL_SYSCALL macro. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Carlos O'Donell wrote: > On Sat, Oct 25, 2008 at 1:21 PM, Julien Danjou <[EMAIL PROTECTED]> wrote: >> Is there anything from an outsider that could help? > > I've seen this on-and-off again on the hppa-linux port. The issue has, > in my experience, been a compiler problem. My standard operating > procedure is to methodically add volatile to the atomic.h operations > until it goes away, and then work out the compiler mis-optimization. > > The bug is almost always a situation where the lll_unlock is scheduled > before owner = 0, and the assert catches the race condition where you > unlock but have not yet cleared the owner. Are you sure this is a compiler problem? Unless you use explicit atomic memory accesses or volatile the compiler is supposed to re-order memory access. Perhaps I'm misunderstanding you. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Sat, Oct 25, 2008 at 1:21 PM, Julien Danjou <[EMAIL PROTECTED]> wrote: > Is there anything from an outsider that could help? I've seen this on-and-off again on the hppa-linux port. The issue has, in my experience, been a compiler problem. My standard operating procedure is to methodically add volatile to the atomic.h operations until it goes away, and then work out the compiler mis-optimization. The bug is almost always a situation where the lll_unlock is scheduled before owner = 0, and the assert catches the race condition where you unlock but have not yet cleared the owner. $0.02. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libcommons-jexl-java 1.1
On Tue, Oct 14, 2008 at 10:15 AM, Onkar Shinde <[EMAIL PROTECTED]> wrote: > Hi all, > > I have updated the packaging for libcommons-jexl-java in pkg-java svn > to make it suitable for latest upstream version 1.1. Can someone > please review and upload it. You should get .orig.tar.gz by simply > doing uscan. > Any update on this? Onkar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
