Bug#816742: libc6: sem_post/sem_wait not working for 32bit to 64bit inter-process communication

[Carlos O'Donell]

On Sat, Mar 5, 2016 at 7:28 AM, Aurelien Jarno  wrote:
> control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=17980

Semaphore interoperability between two different ABIs has never been
supported. It worked because you were lucky and the implementation was
flawed. To fix the implementation flaws (which are real), we've had to
adopt slightly different algorithms for 32-bit and 64-bit.

Cheers,
Carlos.

Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86

[Carlos O'Donell]

I disagree. IMO the most flexible approach is for glibc to stop using cpuid
for RTM detection and rely on the kernel to tell it if RTM is usable. Then
we have a single hardware blacklist in the kernel. We need to talk to
kernel people about this. Not to mention we might extend a getauxval-type
API to prevent applications from using cpuid directly e.g. create a
platform header for this with an x86 specific feature interface.

c.

Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86

[Carlos O'Donell]

On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
 On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
 I can live with that, and I think I can prepare a patch if you want me to.

 Here's a minimal patch to glibc that should do it (compile tested).

The GNU C Library only uses elision if built with --enable-lock-elision=yes.

All you need to do is not build glibc with this flag.

Cheers,
Carlos.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86

[Carlos O'Donell]

On Fri, Sep 19, 2014 at 9:59 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
 On Fri, 19 Sep 2014, Carlos O'Donell wrote:
 On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
 h...@debian.org wrote:
  On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
  I can live with that, and I think I can prepare a patch if you want me to.
 
  Here's a minimal patch to glibc that should do it (compile tested).

 The GNU C Library only uses elision if built with --enable-lock-elision=yes.

 All you need to do is not build glibc with this flag.

 Given Jessie's expected lifetime, I'd say the blacklist is a much better
 choice with the data currently available.

Why not ignore this, call it a hardware problem, and let users update
the microcode if their devices are broken?

Cheers,
Carlos.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#592751: Broken on hppa; programs abort with malloc assertion failure

[Carlos O'Donell]

On Thu, Aug 19, 2010 at 11:00 AM, Mehdi Dogguy me...@dogguy.org wrote:
 On 19/08/2010 16:29, Yavor Doganov wrote:
 В 16:15 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
 On 19/08/2010 15:45, Yavor Doganov wrote:
 Thanks, informing upstream.  Can you narrow it down a bit more?

 I narrowed it down to r28600:r28625.


 It's even r28610:r28615.

I'm the person to ask about hppa and NPTL (I wrote the code).

There *was* a vfork bug that was just fixed in glibc that could cause problems.

Does this code use vfork?

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#592751: Broken on hppa; programs abort with malloc assertion failure

[Carlos O'Donell]

On Thu, Aug 19, 2010 at 12:38 PM, dann frazier da...@dannf.org wrote:
 There *was* a vfork bug that was just fixed in glibc that could cause 
 problems.

 Are you referring to this one?

  * Add patches/hppa/cvs-vfork.diff to fix stack frame creating during
    vfork in multithreaded environments.

 fwiw, we are seeing this issue on the latest eglibc, which contains
 this change.

That was the bug. However, the earlier comments in this bug indicate
it might not be vfork related.

The first step is to capture this with gdb and get a backtrace, just
like you would with any other bug. There is nothing difficult about
this, just time consuming.

Once we have a backtrace, either via a core dump, or attached gdb,
then we can talk about the likely cause.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#592751: Broken on hppa; programs abort with malloc assertion failure

[Carlos O'Donell]

On Thu, Aug 19, 2010 at 1:56 PM, Yavor Doganov ya...@gnu.org wrote:
 Do you find anything disturbing in this approach, in particular:

Yes, you don't take into account the alignment requirement of the structure.

 --- Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28611)
 +++ Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28613)
 @@ -203,5 +203,18 @@
  #define        GSNativeChar    char
  #endif

 +/*
 + * Types used to avoid exposing pthread header in NSLock.h
 + * NB. These types should *never* be used except to provide enough space
 + * in a class layout for the type of data actually used by the pthread
 + * implementation of the current platform.
 + */
 +typedef        struct {
 +  uint8_t      dum...@gs_sizeof_cond_t@];
 +} gs_cond_t;
 +typedef        struct {
 +  uint8_t      dum...@gs_sizeof_mutex_t@];
 +} gs_mutex_t;
 +

 @GS_SIZEOF_COND_T@ and @GS_SIZEOF_MUTEX_T@ should be both 48 on hppa.
 (Mehdi/Dann, can you double check that by grepping GSConfig.h?)

 Apparently this trick works on all platforms (including hppa on Lenny,
 where I've run complex programs in my desire to reproduce).

The pthread_mutex_t and pthread_cond_t on hppa are __attribute__
((aligned(16))), which means if you embedded them into another
structure they need to be padded out to that alignment. The dummy
structure you use here doesn't match the alignment and may break ABI.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#587545: FTBFS [hppa]: java.lang.OutOfMemoryError: Cannot create additional threads

[Carlos O'Donell]

On Tue, Jun 29, 2010 at 1:03 PM, dann frazier da...@debian.org wrote:
    [junit] 0 threads=10 idle=0
    [junit] 100 threads=6 idle=6
    [junit] 200 threads=3 idle=3
    [junit] 300 threads=2 idle=2
    [junit] 400 threads=2 idle=2
    [junit] 500 threads=2 idle=2
    [junit] 13458 [main] WARN org.mortbay.log - failed 
 org.mortbay.thread.queuedthreadp...@6d6c7130: java.lang.OutOfMemoryError: 
 Cannot create additional threads

How many threads did it actually try to create?

Given our 8MB stack size, and alignment requirements, you can't create
more than ~368 threads on hppa (glibc/nptl).

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572384: opal_3.6.6~dfsg-4/hppa FTBFS: undefined reference to `non-virtual thunk to PVXMLSession::Trigger()'

[Carlos O'Donell]

On Thu, Mar 18, 2010 at 7:47 AM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 ../../lib_linux_hppa/libopal.so: undefined reference to `non-virtual
 thunk to PVXMLSession::Trigger()'

What does this error mean?

 [...]
 The PVXMLSession::Trigger() functions which give errors are found in
 ptlib, but in both cases the same ptlib package was used, cf.
 https://buildd.debian.org/fetch.cgi?pkg=opal;ver=3.6.6~dfsg-3;arch=hppa;stamp=1255622898
 and
 https://buildd.debian.org/fetch.cgi?pkg=opal;ver=3.6.6~dfsg-4;arch=hppa;stamp=1268343033

 Unpacking libpt2.6.5 (from .../libpt2.6.5_2.6.5-1_hppa.deb) ...
 and
 Unpacking libpt2.6.5 (from .../libpt2.6.5_2.6.5-1_hppa.deb) ...

You could try running with LD_DEBUG=1 which will generate a trace of
all the dynamic loader actions for the working and non-working cases,
and compare how the symbols are being resolved?

This is useful for example if your dynamic libraries are being built
incorrectly by libtool, which has been the cause of other failures
I've seen in the past.

 So I would rather expect a failure due to the compiler (4.3-4.4), which
 is different:
 Toolchain package versions: libc6-dev_2.9-26 linux-libc-dev_2.6.30-8
 g++-4.3_4.3.4-5 gcc-4.3_4.3.4-5 binutils_2.19.91.20090927-1
 libstdc++6_4.4.1-6 libstdc++6-4.3-dev_4.3.4-5
 and
 Toolchain package versions: libc6-dev_2.10.2-6 dpkg-dev_1.15.5.6
 linux-libc-dev_2.6.32-9 g++-4.4_4.4.3-3 gcc-4.4_4.4.3-3
 binutils_2.20.1-2 libstdc++6_4.4.3-3 libstdc++6-4.4-dev_4.4.3-3

Yes, 4.3 is different from 4.4, I have CC'd John David Anglin our GCC
expert to see if he is aware of any known issues.

 Are you aware of such a problem on hppa architecture (the other
 architectures build well, and there is no #define ...HPPA... in .cpp
 files)?  Maybe this is linked to
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558999 ?

No, I would expect the linker to detect this problem (as it does in
the case of the bug example).

 I'm not aware of any issues myself. I've CCed the HPPA porter list to see
 if they have any ideas.

I'm not aware of any issues associated with the compiler.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570889: #570889 ant: FTBFS on kfreebsd-* and hppa: Bus error

[Carlos O'Donell]

On Thu, Feb 25, 2010 at 9:23 AM, Petr Salinger petr.salin...@seznam.cz wrote:
 The file, which have to be copied, have size 1701,
 but two pages (2*4096) are mmaped. It is allowed on both
 Linux and FreeBSD.
 When the 2nd page of that file would be accessed, it would
 generate SIGBUS.

 The question is of course whether it really happens and why ?
 Petr

 gcc tst.c -o tst
 tst  tst.c

 ---
    #include stdio.h
    #include sys/mman.h

     int main()
     {

     char *p = mmap(0, 8192,PROT_READ,MAP_PRIVATE,0,0);

File descriptor 0 is standard input and you can't mmap that.

You should also check the return of mmap.

Could you please provide a new test case?

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570889: #570889 ant: FTBFS on kfreebsd-* and hppa: Bus error

[Carlos O'Donell]

On Thu, Feb 25, 2010 at 7:22 PM, Petr Salinger petr.salin...@seznam.cz wrote:
 On Thu, Feb 25, 2010 at 9:23 AM, Petr Salinger petr.salin...@seznam.cz
 wrote:

 The file, which have to be copied, have size 1701,
 but two pages (2*4096) are mmaped. It is allowed on both
 Linux and FreeBSD.
 When the 2nd page of that file would be accessed, it would
 generate SIGBUS.

 The question is of course whether it really happens and why ?

 File descriptor 0 is standard input and you can't mmap that.
 You should also check the return of mmap.
 Could you please provide a new test case?

 Please really try to run the example code,
 for me (pagesize 4096) it gives:

 0x800636000 32
 0x800636000 0
 Bus error

 The example code just illustrates what might happen in
 failure of ant. The affected architectures directly in
 ant build have been only kfreebsd-* and hppa.

 Now it looks like wider problem - #571532, #571542, #571397.

Does ant actually try to mmap stdin? That's a bug in ant.

POSIX says you may only mmap a file, shared memory object,
or typed memory object. The stdin file descriptor is neither
of those things therefore you can't mmap stdin.

One might argue the bug is that the Linux kernel allows the
mmap to succeed.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570889: #570889 ant: FTBFS on kfreebsd-* and hppa: Bus error

[Carlos O'Donell]

On Fri, Feb 26, 2010 at 3:14 AM, Petr Salinger petr.salin...@seznam.cz wrote:
 My point is a different one, see in #570889.

 14997 gij-4.4  CALL  open(0x8e59e58,O_RDONLY|O_LARGEFILE,unused0)
 14997 gij-4.4  NAMI .../defaults.properties
 14997 gij-4.4  RET   open 10/0xa
 14997 gij-4.4  CALL  fstat(0xa,0xbfbf29ec)
 14997 gij-4.4  STRU  size=1701
 14997 gij-4.4  RET   fstat 0
 14997 gij-4.4  CALL  mmap(0,0x2000,PROT_READ,MAP_PRIVATE,0xa,0,0)
 14997 gij-4.4  RET   mmap 712716288/0x2a7b3000
 14997 gij-4.4  PSIG  SIGBUS SIG_DFL

 The ant/gij-4.4 mmaps 8192 bytes from file of size 1701
 on architecture with pagesize 4096.

If ant mmap's a file that has only 1701 bytes, on an architecture with
page size of 4906, then any access beyond the first page will cause a
SIGBUS.

POSIX mmap says:
* The system will zero-fill a partial page at the end of an object.
Thus bytes 1701-4095 are zero-filled.
* Access to any whole page past the end of an object shall result in
SIGBUS. Thus access to bytes 4096-8192 will result in a SIGBUS.

If ant is accessing whole pages beyond the length of the object (not
the length of the required mmap) then this is a bug.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: Re: Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash

[Carlos O'Donell]

On Sun, Dec 27, 2009 at 9:47 AM, Luk Claes l...@debian.org wrote:
 What's the status of this bug? It's holding the KDE transition which is
 blocking the Xorg and python transitions...

I'm working on this bug. The current status is under investigation.
I don't have a good idea of what is going on or why it's crashing.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash

[Carlos O'Donell]

On Tue, Dec 22, 2009 at 2:54 PM, Modestas Vainius modes...@vainius.eu wrote:
 when investigating this issue further, I determined that fork() following
 pthread_create() sometimes makes the application crash. In order to reproduce,
 build attached minifail.cpp with:

 $ g++ -I/usr/include/qt4 -lQtCore minifail.cpp -o minifail -O0 -g

Thank you for the test case.

 This means that thread 2 was not started at all and hung at clone().
 Relevant QThread code at
 http://qt.gitorious.org/qt/qt/blobs/4.5/src/corelib/thread/qthread_unix.cpp

I don't believe that it would be stuck at the store instruction which
is pointed to by the PC (iaoqh).

However, I do believe that something is wrong and I am going to
investigate the kde4libs failure tonight.

 I strongly believe that if you fix the first problem, the 2nd one will
 disappear too as their origin is the same. Both tests work just fine on amd64.

 Contrary to what I said previously, the bug is reproducible under strace -f,
 but you have to wait much longer (up to 1th run).

 ii  libc6                         2.10.2-2                      GNU C Library:
 Shared libraries

Thanks. I'll look into this tonight.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#558980: access to hppa machine to work on Bug#558980

[Carlos O'Donell]

On Mon, Dec 14, 2009 at 7:46 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
 If you see transferring control: then the dynamic loader has just
 handed off control the real program, and any fault after that is
 possibly related to the real program.

 That is there, although there are more symbols looked up after it.

This is good news, it means the dynamic loader handed control to the program.

 So I will leave hppa in the arch list, but remove the stack check
 option.

Would it be possible for you to keep open a low severity bug
indicating that this needs to be fixed?

Remember to tag the bug hppa, so that I can track it on our ports
to-do list e.g.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;which=tagdata=hppaarchive=no

We are working through the tagged bugs to try make progress.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#558905: Kernel bug.

[Carlos O'Donell]

IMO this FTBS is a kernel vfork bug. The return register in the parent
is being corrupted.

Using the emacs23 source I was able to produce a trimmed down test
case for the failing vfork.

I have reported this to our kernel developers here:

http://article.gmane.org/gmane.linux.ports.parisc/2403

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#557982: Should be fixed now.

[Carlos O'Donell]

On Tue, Dec 1, 2009 at 9:26 AM, Daniel Burrows dburr...@debian.org wrote:
 debian-hppa, any clue why cwidget would get an error when trying to
 create 50 threads, and how to fix this?

  According to the build logs for 0.5.16-2, it successfully creates
 37 new threads, failing on the 38th.  More annoyingly, it looks like
 sysconf is not reporting the existence of a limit on the number of
 threads the test can create; both tests are trying to create their
 default number of threads (the number of threads to create would have
 been lowered to the limit had sysconf indicated that there was a
 limit -- I thought maybe I had an off-by-one error in how I was
 computing the limit, but apparently that's not the case).

  Anyway, the build looks like it succeeded now that the failed
 pthread_create is ignored.

On hppa you get at *most* ~381 threads with the default 8MB stacks,
and the required shared libraries loaded. Starting 50 threads should
not be a problem.

For the record I can't reproduce the cwidget failure locally, when I
run the test it correctly creates 50 threads, and passes the test.

I will assume this is a kernel/glibc issue and continue to work on
making both more reliable in the future.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#557982: Should be fixed now.

[Carlos O'Donell]

On Mon, Nov 30, 2009 at 4:58 PM, Julien Cristau jcris...@debian.org wrote:
 reopen 557982
 kthxbye

 On Mon, Nov 30, 2009 at 12:28:31 -0800, Daniel Burrows wrote:

   With any luck, this is fixed in 0.5.16-1 in unstable.  I addressed the
 problem by having the tests query for the system limit on the number of
 threads they could create, then stop at that many.  Hopefully that
 should get them to pass on hppa, but obviously I can't test that myself,
 so please let me know if it fails again.

 Looks like it failed again.
 https://buildd.debian.org/fetch.cgi?pkg=cwidget;ver=0.5.16-1;arch=hppa;stamp=1259584731

 debian-hppa, any clue why cwidget would get an error when trying to
 create 50 threads, and how to fix this?

Without more analysis I can't comment on what might be the cause. I
recently ran the LTP nptl01 test and it ran without a problem. This
failure might be a kernel bug, or a glibc bug, or both.

We've done the right thing though, this issue is tagged with hppa and
it shows up on our list here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;which=tagdata=hppaarchive=no

I will add it to my list of failures to review.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#557984: Use of -m64 is invalid on hppa-linux-gnu.

[Carlos O'Donell]

It is not valid to use -m64 on hppa.

We do not have a multi-arch compiler, and we only support the 32-bit userspace.

Has this package ever built for hppa?



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[Carlos O'Donell]

On Mon, Nov 23, 2009 at 8:48 AM, Aurelien Jarno aurel...@aurel32.net wrote:
 Next steps:
 (1) Wait for testsuite results to finish completely. Verify nothing
 has regressed.

No regressions.

 (2) Remove changes to gcc package debian/rules2 and re-run validation.

Some regressions caused by enabling cloog/ppl, however these
regressions do not break the libstdc++6 package in any critical way.

Re-running the test case by hand now works, and the C++ class has the
correct offsets.

 (3) In parallel provide new patch to debian-glibc to fix alignment
 issues with pthread types.

Done.

 (4) Ask debian-glibc team to run a build and look for testsuite regressions.

Done.

 If the test results for (2) and (4) are clean, then I will give the
 green light for a new glibc to be uploaded. This will fix the
 libstdc++6 issues.

The test results for (2) and (4) are clean enough for a release given my QA.

 I guess there is a fifth step need:
 (5) rebuild gcc-4.4 against the fixed glibc.

Aurelian has uploaded a new glibc with the fix and informs me that gcc
is currently rebuilding.

Once I conform that the newly built gcc is OK, we can close this issue
and start building packages again.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[Carlos O'Donell]

On Mon, Nov 23, 2009 at 5:22 AM, Aurelien Jarno aurel...@aurel32.net wrote:
 Carlos O'Donell a écrit :
 On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
 d...@hiauly1.hia.nrc.ca wrote:
 While I set out the glibc types exactly as before (binary compatible),
 the alignment restrictions were changed subtly.
 Excellent debugging!

 I have adjusted the glibc lock structure alignments to try and match
 more accurately the original alignment restrictions.

 I have built a glibc with the new headers, and installed that into my
 test system.

 I'm now rebuilding libstdc++6 against the new headers to determine if
 this fixes the problem.

 I will have results by tomorrow.


 Thanks a lot for the investigation, I really hope this will work.

It worked. I now see 0xb0 as the object offset, which gives a
compatible object layout for the libstdc++ iostream classes.

(gdb) x/16x $ret0 - 0xc
0x409a6f38 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
0x00b0  0x  0x409a72f0  0x401b2b96
0x409a6f48 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16:
 0x401b2b9e  0xff50  0xff50  0x409a72f0
0x409a6f58 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32:
 0x401b2ba6  0x401b2bae  0x  0x409a6ff4
0x409a6f68 _ZTVSt13basic_filebufIcSt11char_traitsIcEE+8:
0x401b2e6e  0x401b2e76  0x401b2e7e  0x401b2e86

I can successfully run apt-get with the new libstdc++6 that I just built.

The testsuite result is cleaner:
~~~
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test

=== libstdc++ Summary ===

# of expected passes5880
# of unexpected failures2
# of expected failures  80
# of unsupported tests  331
~~~

I am still building with
~~~
# Disable cloog/ppl and pch on hppa.
ifneq (,$(findstring $(DEB_TARGET_ARCH), hppa))
  CONFARGS += --without-ppl --without-cloog --disable-libstdcxx-pch
endif
~~~
However, I don't think this made any difference.

Next steps:
(1) Wait for testsuite results to finish completely. Verify nothing
has regressed.
(2) Remove changes to gcc package debian/rules2 and re-run validation.
(3) In parallel provide new patch to debian-glibc to fix alignment
issues with pthread types.
(4) Ask debian-glibc team to run a build and look for testsuite regressions.

If the test results for (2) and (4) are clean, then I will give the
green light for a new glibc to be uploaded. This will fix the
libstdc++6 issues.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[Carlos O'Donell]

On Sun, Nov 22, 2009 at 10:30 AM, John David Anglin
d...@hiauly1.hia.nrc.ca wrote:
  The problem appears to have gone away with head.  I don't see it with
  hpux.
 

 Note that latest version of gcc 4.4 in Debian is built with
 --disable-libstdcxx-pch, but the segfault is this present :(

 Personally, I don't believe the segfault is related to the FAILs
 seen in the libstdc++ testsuite.  As you showed, there is an ABI
 change in the library depending on libc version.  Someone needs
 to generate a backtrace so that we can get some idea what's happening.

Running apt-get with the newly compiled libstdc++6 with
--without-cloog/--without-ppl still cause the segfault.

The glibc locale() function is causing this failure.

The segfault happens when basic_ios is being initialized. The
ios_base::_M_init() calls locale() to create a locale object and
stores this into _M_ios_locale. The assignment is done through an
operator= for the locale type, and this crashes.

Starting program: /usr/bin/apt-get

Program received signal SIGSEGV, Segmentation fault.
std::locale::operator= (this=0xbff01c84, __other=...) at
../../../../src/libstdc++-v3/src/locale.cc:116
116 _M_impl-_M_remove_reference();
Current language:  auto; currently c++
(gdb) bt
#0  std::locale::operator= (this=0xbff01c84, __other=...) at
../../../../src/libstdc++-v3/src/locale.cc:116
#1  0x40390c10 in std::ios_base::_M_init (this=0xbff01fc8) at
../../../../src/libstdc++-v3/src/ios_locale.cc:43
#2  0x403a9858 in std::basic_ioschar, std::char_traitschar ::init
(this=0x4043e890, __sb=0xbff01fc8)
at 
/home/carlos/fsrc/debian/gcc-4.4-4.4.2/build/hppa-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:128
#3  0x405c7eec in ReadConfigFile(Configuration, std::string const,
bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8
#4  0x405c79e8 in ReadConfigDir(Configuration, std::string const,
bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8
#5  0x40606eac in pkgInitConfig(Configuration) () from
/usr/lib/libapt-pkg-libc6.9-6.so.4.8
#6  0x0001d8b8 in main ()
(gdb)

This is the 14th call to std::locale::operator=, but the first call
with an object that was created on the stack.

The object *this a std::locale object, has an invalid _M_impl member,
whose value should be a pointer to an implementation but instead it's
a value of 0x8.

This happens because the original locale object was created at address
0xbff01c20. However, when apt-get calls std::basic_ioschar,
std::char_traitschar ::init it passes in the address 0xbff01c18.
So we went from a constructor using this as 0xbff01c20, to eventually
passing this as 0xbff01c18 to a template. The pointer to the
std::ios_base object is now off by 8 bytes and this causes the crash.

What happened here? Why does ReadConfigFile() think that the object is
in a different location?

Any hints on how to track this down?

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[Carlos O'Donell]

On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
car...@systemhalted.org wrote:
 This happens because the original locale object was created at address
 0xbff01c20. However, when apt-get calls std::basic_ioschar,
 std::char_traitschar ::init it passes in the address 0xbff01c18.
 So we went from a constructor using this as 0xbff01c20, to eventually
 passing this as 0xbff01c18 to a template. The pointer to the
 std::ios_base object is now off by 8 bytes and this causes the crash.

 What happened here? Why does ReadConfigFile() think that the object is
 in a different location?

 Any hints on how to track this down?

The problem is here, we read 0xa8 here from libstdc++6:

(gdb) x/16x $ret0 - 0xc
0x40437778 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
0x00a8  0x  0x40437b30  0x401b2b96
0x40437788 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16:
 0x401b2b9e  0xff58  0xff58  0x40437b30
0x40437798 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32:
 0x401b2ba6  0x401b2bae  0x  0x40437834

Then we add this offset to the base location of the object on the
stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we
would expect.

It looks like the layout of the object in libstdc++.so.6 has changed,
my guess is that the changes I made to the locking types in glibc have
caused the layout to be perturbed.

While I set out the glibc types exactly as before (binary compatible),
the alignment restrictions were changed subtly.

I will go back immediately and review this.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[Carlos O'Donell]

On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
d...@hiauly1.hia.nrc.ca wrote:
 While I set out the glibc types exactly as before (binary compatible),
 the alignment restrictions were changed subtly.

 Excellent debugging!

I have adjusted the glibc lock structure alignments to try and match
more accurately the original alignment restrictions.

I have built a glibc with the new headers, and installed that into my
test system.

I'm now rebuilding libstdc++6 against the new headers to determine if
this fixes the problem.

I will have results by tomorrow.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[Carlos O'Donell]

On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno aurel...@aurel32.net wrote:

 I confirm, it's what I see in the testsuite log:

 | 77
 | __signbitl
 | version status: incompatible
 | GLIBCXX_3.4
 | type: function
 | status: added

If __signbitl is the only failure in the abi_check, then that's easy
to fix, the testsuite needs to be updated.

With cloog/ppl disabled I still get 7 testsuite failures, so I'll have
to dig into each failure tommorow and see what's wrong.

~~~
Running target unix
FAIL: abi_check
FAIL: 26_numerics/complex/13450.cc (test for excess errors)
UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce
executable
FAIL: 26_numerics/complex/pow.cc (test for excess errors)
UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test
for excess errors)
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)
UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation
failed to produce executable

=== libstdc++ Summary ===

# of expected passes5873
# of unexpected failures7
# of unexpected successes   1
# of expected failures  79
# of unresolved testcases   3
# of unsupported tests  331
~~~

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[Carlos O'Donell]

On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno aurel...@aurel32.net wrote:
 Domenico Andreoli a écrit :
 On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
 On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose d...@debian.org wrote:
 On 05.11.2009 14:30, Domenico Andreoli wrote:
 frankly i do not know what to do next, besides trying to rebuild gcc-4.4
 4.4.2-1 with latest eglibc to see if it is the culprit
 or rebuild against eglibc-2.9. could you do this as a test?
 yes, build started

 the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current
 gcc 4.4.2-1 is built with eglibc 2.9-26 [0].  should i try building
 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL?

 At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to
 NPTL.

 I have done some more tests, showing it's a bit more complicated than
 that. apt-get from stable/testing/unstable:
 - works with libstdc++6 built against eglibc 2.9
 - segfaults with libstdc++6 built against eglibc 2.10.1

 Then I tried to rebuild apt against the broken libstdc++6.
 Surprisingly this new apt-get:
 - works with libstdc++6 built against eglibc 2.10.1
 - segfaults with libstdc++6 built against eglibc 2.9

 So in short, it seems that using eglibc 2.10.1 to build libstdc++6
 triggers an ABI change on this library. I haven't investigated more for
 now, I am not sure when I'll have time to do it.

This is not surprising, Dave has already pointed out that the debian
libstdc++6 testsuite run clearly has an ABI failure e.g.
~~~
FAIL: abi_check
~~~

I'm running a build with --without-cloog/--without-ppl to see if that
corrects the testsuite failures.

We need to stop allowing packages to build if the testsuite runs aren't clean.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#556653: FTBS on hppa

[Carlos O'Donell]

On Tue, Nov 17, 2009 at 8:05 AM, Francesco Paolo Lovergine
fran...@debian.org wrote:
 make[2]: Leaving directory 
 `/build/buildd-cmake_2.8.0-1-hppa-6PIkTw/cmake-2.8.0/Build/Bootstrap.cmk'
 loading initial cache file 
 /build/buildd-cmake_2.8.0-1-hppa-6PIkTw/cmake-2.8.0/Build/Bootstrap.cmk/InitialCacheFlags.cmake
 Segmentation fault

 Relevant buildd output:
 https://buildd.debian.org/fetch.cgi?pkg=cmake;ver=2.8.0-1;arch=hppa;stamp=1258382304

I can reproduce this. It appears to be a miscompilation of cmake by
g++. I will look into a workaround for you.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: Status?

[Carlos O'Donell]

What is the status of this bug?

Is it up to the package maintainer to disable cloog/ppl for hppa and
try the build again?

Speaking professionally, CodeSourcery enables cloog/ppl for our
toolchain products, but we do a lot of additional testing to verify
everything is working properly.

At the end of the day, without a way to fail the source only upload
build when the FAIL list changes, this will continue to be a problem
for source only upload architectures like hppa. This type of problem
could happen to any architecture. We need stricter build failure
controls. I would suggest that the debian gcc package maintain a known
good FAIL/XFAIL list and fail the build if that doesn't match. When a
build fail happens the porters (like myself) should be contacted
immediately to determine the cause of the regressions and fix the
problem.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa

[Carlos O'Donell]

On Sun, Nov 8, 2009 at 2:47 PM, Carlos O'Donell car...@systemhalted.org wrote:
 On Sun, Nov 8, 2009 at 1:42 PM, Carlos O'Donell car...@systemhalted.org 
 wrote:
 Always the same crash for all the failures I've looked at. Hopefully
 this is something trivial that was missed.

 The current libc is missing my patches to fix pthread_attr_setstack()
 and pthread_attr_getstack() for hppa.

With this patches:
http://www.parisc-linux.org/~carlos/local-stack-grows-up.diff

I know see this for the libjava testsuite in gcc trunk.
~~~
=== libjava Summary ===

# of expected passes2568
# of unexpected failures3
# of untested testcases 3
~~~

I've already asked Aurelien to apply the above listed patch.

There is a regression in glibc, tst-attr3 fails randomly under load,
but it isn't related to this code. I will be tracking that down
independently of this patch.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa

[Carlos O'Donell]

On Mon, Nov 9, 2009 at 9:37 PM, Matthias Klose d...@debian.org wrote:
 looking at the gcc-4.4 g++/libstdc++ test results I see regressions as well;
 is this reproducible for you?

What regressions are you seeing?

I have a check-g++ running right now against glibc 2.10.1-0exp2. I'll
comment when this is done.

Does the gcc package do something similar to glibc and fail the build
of the testsuite results fail to match expected results?

In such cases the debian-glibc team contacts the porters to help sort
out why the testsuite had changed, thus avoiding an upload that breaks
userspace.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa

[Carlos O'Donell]

On Tue, Nov 10, 2009 at 10:32 AM, Carlos O'Donell
car...@systemhalted.org wrote:
 On Mon, Nov 9, 2009 at 9:37 PM, Matthias Klose d...@debian.org wrote:
 looking at the gcc-4.4 g++/libstdc++ test results I see regressions as well;
 is this reproducible for you?

 What regressions are you seeing?

 I have a check-g++ running right now against glibc 2.10.1-0exp2. I'll
 comment when this is done.

=== g++ Summary ===

# of expected passes21250
# of unexpected failures26
# of expected failures  157
# of unresolved testcases   14
# of unsupported tests  168

=== libstdc++ Summary ===

# of expected passes6913
# of unexpected failures1
# of unexpected successes   1
# of expected failures  86
# of unsupported tests  97

I'm seeing this with gcc upstream trunk compiled against glibc-2.10.1-0exp2.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa

[Carlos O'Donell]

On Mon, Nov 2, 2009 at 11:17 AM, Carlos O'Donell
car...@systemhalted.org wrote:
 On Mon, Nov 2, 2009 at 5:01 AM, Aurelien Jarno aurel...@aurel32.net wrote:
 Hi HPPA porters,

 Could someone please have a look at this problem? It seems to be due to
 the NPTL switch.

 I'm already looking at the gcj breakage so I'll have a look at this. Thanks.

~~~
=== libjava Summary ===

# of expected passes877
# of unexpected failures842
# of untested testcases 842
~~~

The testsuite failures are all caused by a crash in the garbage collector.

#0  GC_push_all_eager (bottom=value optimized out, top=value optimized out)
at ../../../gcc-trunk/boehm-gc/mark.c:1468
#1  0x42ac7aec in GC_push_all_stacks () at
../../../gcc-trunk/boehm-gc/pthread_stop_world.c:307
#2  0x42ac0f14 in GC_push_roots (all=1, cold_gc_frame=0xbff01708
C\222\254DB\253U\24)
at ../../../gcc-trunk/boehm-gc/mark_rts.c:646
#3  0x42ac0188 in GC_mark_some (cold_gc_frame=0xbff01708 C\222\254DB\253U\24)
at ../../../gcc-trunk/boehm-gc/mark.c:326
#4  0x42ab58ec in GC_stopped_mark (stop_fu...@0x438c166e: 0x42ab5514
GC_never_stop_func)
at ../../../gcc-trunk/boehm-gc/alloc.c:531
#5  0x42ab6094 in GC_try_to_collect_inner (stop_fu...@0x438c166e:
0x42ab5514 GC_never_stop_func)
at ../../../gcc-trunk/boehm-gc/alloc.c:378
#6  0x42ac2214 in GC_init_inner () at ../../../gcc-trunk/boehm-gc/misc.c:789
#7  0x42ac2500 in GC_init () at ../../../gcc-trunk/boehm-gc/misc.c:493
#8  0x42abb3f4 in GC_init_gcj_malloc (mp_index=0, mp=0x40247a5e)
at ../../../gcc-trunk/boehm-gc/gcj_mlc.c:60
#9  0x41d40c28 in _Jv_InitGC () at ../../../gcc-trunk/libjava/boehm.cc:537
#10 0x41d2cd58 in _Jv_RegisterNewClasses (classes=0x1242c)
at ../../../gcc-trunk/libjava/java/lang/natClassLoader.cc:364
#11 0x00010c84 in _Jv_global_static_constructor () at emptystring.java:13
#12 0x00010eb4 in __do_global_ctors_aux ()
#13 0x00010598 in _init ()
#14 0x00010e00 in __libc_csu_init ()
#15 0x40a22ffc in __libc_start_main (ma...@0x126be: 0x126d0, argc=1,
ubp_av=0xbff0102c,
in...@0x1269e: 0x10dc8 __libc_csu_init, fi...@0x12676: 0x126d0,
rtld_fi...@0x4024787e: 0x4023708c _dl_fini,
stack_end=0xbff011c0) at libc-start.c:181
#16 0x00010650 in _start ()
(gdb)

Always the same crash for all the failures I've looked at. Hopefully
this is something trivial that was missed.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa

[Carlos O'Donell]

On Sun, Nov 8, 2009 at 1:42 PM, Carlos O'Donell car...@systemhalted.org wrote:
 Always the same crash for all the failures I've looked at. Hopefully
 this is something trivial that was missed.

The current libc is missing my patches to fix pthread_attr_setstack()
and pthread_attr_getstack() for hppa.

HPPA is an architecture under which the stack grows up and the default
implementation does not take that into account.

The boehm-gc then uses the wrong stack values during garbase
collection initialization and thus every gcj built application
crashes.

I will work with Aurelian on putting out a fixed libc, until then gcj
will not work correctly.

Sorry about the inconvenience. It appears that the glibc testsuite is
self-consistent, and because both set and get functions are affected
the glibc tests actually pass.

I didn't notice this because I don't normally bootstrap java.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554218: perl: FTBFS on hppa: Thread creation failed

[Carlos O'Donell]

On Wed, Nov 4, 2009 at 2:45 AM, Niko Tyni nt...@debian.org wrote:
 tag 554218 fixed-upstream
 thanks

 On Tue, Nov 03, 2009 at 05:15:06PM -0400, Carlos O'Donell wrote:

 This is a bug in the perl test case.

 The error number 11 is EAGAIN, which means it needs to retry the
 thread creation.

 Thanks! I should probably have done some more homework first myself, sorry
 about that. I was thinking of signal 11 which led me to the wrong track.

Thank you for contacting the debian-hppa porters. I'm glad this is resolved!

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554218: perl: FTBFS on hppa: Thread creation failed

[Carlos O'Donell]

On Tue, Nov 3, 2009 at 3:36 PM, Niko Tyni nt...@debian.org wrote:
 Package: perl
 Version: 5.10.1-6
 Severity: serious

 perl/5.10.1-6 failed to build on paer, see

  https://buildd.debian.org/fetch.cgi?pkg=perlarch=hppaver=5.10.1-6stamp=1256782011file=logas=raw

 5.10.1-5 built OK, and as there were no related source changes in -6,
 I assume the libc NPTL switch is the culprit.

 Cc'ing the debian-hppa list. Could somebody please look into this?
 I don't know if perl needs to be recompiled against libc6 2.10 first or
 if it shows up with the system perl too.

 It should be enough to just run 'cd ext/threads-shared  perl t/stress.t'
 but I don't quite have the heart to try it out on paer and its chroot
 still has libc6 2.9 anyway.

  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  Thread creation failed: pthread_create returned 11 at 
 ../ext/threads-shared/t/stress.t line 77.
  # Warning: 13 threads failed
  # Note: errno 12 = ENOMEM
  # Test failed: 37 threads timed out
  ext/threads-shared/t/stress...FAILED at test 
 1

This is a bug in the perl test case.

The error number 11 is EAGAIN, which means it needs to retry the
thread creation.

POSIX says:
~~~
[EAGAIN]
The system lacked the necessary resources to create another
thread, or the system-imposed limit on the total number of threads in
a process {PTHREAD_THREADS_MAX} would be exceeded.
~~~

There are several code paths during thread creation that may return
EAGAIN, and the testsuite should handle that.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa

[Carlos O'Donell]

On Mon, Nov 2, 2009 at 5:01 AM, Aurelien Jarno aurel...@aurel32.net wrote:
 Hi HPPA porters,

 Could someone please have a look at this problem? It seems to be due to
 the NPTL switch.

I'm already looking at the gcj breakage so I'll have a look at this. Thanks.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#546619: upcoming 4.5.19 release works on hppa

[Carlos O'Donell]

Frederik,

Your upcoming release 4.5.19 works on hppa. Thanks!

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#546619: strace for hppa is critically broken

[Carlos O'Donell]

Package: strace
version: 4.5.18-1
Severity: grave
Architecture: hppa
Tags: Patch

Strace is *unusable* on hppa.

This bug supercedes bug #437928, updates the patches listed there, and
fixes the most recent issues.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437928

Problems:
* Traced process function descriptors are accessed causing faults.
* More than maximum number of syscall arguments accessed causing upeek failures.
* Missing syscalls.
* Incorrect processing of some IPC syscalls.

Please apply the attached patch to fix all of these issues.

It is critical that strace be fixed, the debian-porters are attempting
to track down buildd instability issues and without a working strace
this makes it difficult.

Cheers,
Carlos.
From: Carlos O'Donell car...@systemhalted.org

Miscellaneous hppa fixes

Add missing syscalls, handle IPC syscalls correctly,
avoid manipulationg function pointers, and handle
syscall arguments correctly.

This patch is based on work by Kyle McMartin and 
Helge Deller.

	* ipc.c (sys_shmat): hppa does not have a kernel 
	multiplexer for IPC.
	* linux/hppa/syscallend.h: Add missing syscalls.
	* signal.c (sys_sigaction): Avoid manipulating
	function pointers.
	(sys_rt_sigaction): Likewise.

Signed-off-by: Carlos O'Donell car...@systemhalted.org
---

diff -urN strace-4.5.18_orig/ipc.c strace-4.5.18/ipc.c
--- strace-4.5.18_orig/ipc.c	2007-01-15 15:25:52.0 -0500
+++ strace-4.5.18/ipc.c	2009-09-13 21:58:31.0 -0400
@@ -387,7 +387,8 @@
 		}
 		if (syserror(tcp))
 			return 0;
-#ifdef LINUX
+/* HPPA does not use an IPC multiplexer.  */
+#ifdef LINUX  !defined(HPPA) 
 		if (umove(tcp, tcp-u_arg[2], raddr)  0)
 			return RVAL_NONE;
 		tcp-u_rval = raddr;
diff -urN strace-4.5.18_orig/linux/hppa/syscallent.h strace-4.5.18/linux/hppa/syscallent.h
--- strace-4.5.18_orig/linux/hppa/syscallent.h	2008-07-17 21:23:49.0 -0400
+++ strace-4.5.18/linux/hppa/syscallent.h	2009-09-13 22:06:20.0 -0400
@@ -197,10 +197,10 @@
 	{ 4,	TI,	sys_msgrcv,		msgrcv		}, /* 189 */
 	{ 4,	TI,	sys_msgget,		msgget		}, /* 190 */
 	{ 4,	TI,	sys_msgctl,		msgctl		}, /* 191 */
-	{ 4,	TI,	sys_shmat,		shmat			}, /* 192 */
-	{ 4,	TI,	sys_shmdt,		shmdt			}, /* 193 */
-	{ 4,	TI,	sys_shmget,		shmget		}, /* 194 */
-	{ 4,	TI,	sys_shmctl,		shmctl		}, /* 195 */
+	{ 3,	TI,	sys_shmat,		shmat			}, /* 192 */
+	{ 1,	TI,	sys_shmdt,		shmdt			}, /* 193 */
+	{ 3,	TI,	sys_shmget,		shmget		}, /* 194 */
+	{ 3,	TI,	sys_shmctl,		shmctl		}, /* 195 */
 	{ 5,	0,	sys_getpmsg,		getpmsg		}, /* 196 */
 	{ 5,	0,	sys_putpmsg,		putpmsg		}, /* 197 */
 	{ 2,	TF,	sys_lstat64,		lstat64		}, /* 198 */
@@ -302,4 +302,25 @@
 	{ 4,	TD,	printargs,		vmsplice		}, /* 294 */
 	{ 6,	0,	sys_move_pages,		move_pages		}, /* 295 */
 	{ 3,	0,	sys_getcpu,		getcpu		}, /* 296 */
-	{ 5,	TD,	sys_epoll_pwait,	epoll_pwait		}, /* 297 */
+	{ 6,	TD,	sys_epoll_pwait,	epoll_pwait		}, /* 297 */
+	{ 3,	TF,	sys_statfs64,		statfs64		}, /* 298 */
+	{ 3,	TD,	sys_fstatfs64,		fstatfs64		}, /* 299 */
+	{ 4,	0,	printargs,		kexec_load		}, /* 300 */
+	{ 4,	TD|TF,	sys_utimensat,		utimensat		}, /* 301 */
+	{ 3,	TD,	printargs,		signalfd		}, /* 302 */
+	{ 4,	TD,	printargs,		timerfd		}, /* 303 */
+	{ 1,	TD,	sys_eventfd,		eventfd		}, /* 304 */
+	{ 6,	TF,	sys_fallocate,		fallocate		}, /* 305 */
+	{ 2,	TD,	sys_timerfd_create,	timerfd_create	}, /* 306 */
+	{ 4,	TD,	sys_timerfd_settime,	timerfd_settime	}, /* 307 */
+	{ 2,	TD,	sys_timerfd_gettime,	timerfd_gettime	}, /* 308 */
+	{ 4,	TD|TS,	printargs,		signalfd4		}, /* 309 */
+	{ 2,	TD,	printargs,		eventfd2		}, /* 310 */
+	{ 1,	0,	printargs,		epoll_create1		}, /* 311 */
+	{ 3,	TD,	printargs,		dup3			}, /* 312 */
+	{ 2,	TD,	printargs,		pipe2			}, /* 313 */
+	{ 1,	TD,	printargs,		inotify_init1		}, /* 314 */
+	{ 5,	TD,	printargs,		preadv		}, /* 315 */
+	{ 5,	TD,	printargs,		pwritev		}, /* 316 */
+	{ 4,	TP|TS,	printargs,		rt_tgsigqueueinfo	}, /* 317 */
+	{ 5,	0,	printargs,		perf_counter_open	}, /* 318 */
diff -urN strace-4.5.18_orig/signal.c strace-4.5.18/signal.c
--- strace-4.5.18_orig/signal.c	2008-08-19 21:59:40.0 -0400
+++ strace-4.5.18/signal.c	2009-09-13 22:00:50.0 -0400
@@ -1120,11 +1120,19 @@
 	else if (umove(tcp, addr, sa)  0)
 		tprintf({...});
 	else {
-		if (sa.SA_HANDLER == SIG_ERR)
+ 		/* Architectures using function pointers, like
+ 		 * hppa, may need to manipulate the function pointer
+ 		 * to compute the result of a comparison. However,
+ 		 * the SA_HANDLER function pointer exists only in 
+ 		 * the address space of the traced process, and can't
+ 		 * be manipulated by strace. In order to prevent the 
+ 		 * compiler from generating code to manipulate 
+ 		 * SA_HANDLER we cast the function pointers to long. */
+		if ((long)sa.SA_HANDLER == (long)SIG_ERR)
 			tprintf({SIG_ERR, );
-		else if (sa.SA_HANDLER == SIG_DFL)
+		else if ((long)sa.SA_HANDLER == (long)SIG_DFL)
 			tprintf({SIG_DFL, );
-		else if (sa.SA_HANDLER == SIG_DFL) {
+		else if ((long)sa.SA_HANDLER == (long)SIG_DFL) {
 #ifndef USE_PROCFS

Bug#494191: eperl: Hangs on hppa

[Carlos O'Donell]

On Fri, Aug 8, 2008 at 4:04 AM, Niko Tyni [EMAIL PROTECTED] wrote:
 On Thu, Aug 07, 2008 at 08:51:51PM +0200, Rafael Laboissiere wrote:
 Package: eperl
 Version: 2.2.14-15.1+b1
 Severity: serious
 Justification: renders package unusable on hppa

 eperl hangs on hppa, even for this trivial case:

 eperl /dev/null

 See #486069: embedding perl hangs on hppa without PERL_SYS_INIT3() since 
 5.10.0

 There's a list of probably broken packages there that I haven't had the
 time to go through yet.

 Cc'ing the debian-hppa and debian-perl lists again in the hope somebody
 could pick this up and test them.

I'm not clear on the action item here? What do you need tested?

Background:
~~

The locked state of a lock is 0 on hppa, which means that if you don't
initialize your locks (as documented), they begin in the locked state
e.g. bss initialized to zero.

You must use PERL_SYS_INIT3() on hppa, I don't know how it worked without it.

As hppa porters we spend a lot of time tracking down uninitialized
locks (or memset'd 0 locks), which just happen to work on every other
architecture.

Note: As of the NPTL port for hppa, we consciously changed this to
match all other architectures e.g. unlocked is zero.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#489906: glibc: tst-regex fails on hppa

[Carlos O'Donell]

On Tue, Jul 22, 2008 at 4:00 AM, Aurelien Jarno [EMAIL PROTECTED] wrote:
 For those that are not on IRC, I have made a lot of progress on this
 bug. The problem comes from the patch any/cvs-strerror_r.diff. However,
 this patch looks ok, actually comes from upstream and fix a bug. It
 seems it only triggers a lock bug on hppa.

 FYI you will find below the part of the patch that causes the problem in
 case of tst-regex. It's only a change in the locks type.

The only think I can think of is a miscompilation. If you turn down
the optimization to -O1 on that file, does it help?

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#489906: glibc: tst-regex fails on hppa

[Carlos O'Donell]

On Tue, Jul 8, 2008 at 12:21 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
 Package: libc6
 Version: 2.7-12
 Severity: critical

 tst-regex fails on hppa, which IMHO is not something acceptable for a
 release architecture.

 -- System Information:
 Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores)

This is clearly not the machine or kernel tuple which the test is
failing on? :-)

What machine and kernel are you using?

What provides the kernel headers?

Do you have a recipe for building locally?

e.g.
# put unstable sources list in your /etc/apt/sources.list
apt-get build-dep glibc
apt-get source glibc
dpkg-buildpackage -rfakeroot

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#489856: glibc: FTBFS on hppa

[Carlos O'Donell]

On Tue, Jul 8, 2008 at 4:49 AM, Miguel Gea Milvaques
[EMAIL PROTECTED] wrote:
 Package: glibc
 Version: 2.7-12
 Severity: serious
 Justification: no longer builds from source


 It fails to build in hppa. See buildd logs [1].

 [1]
 http://buildd.debian.org/fetch.cgi?pkg=glibc;ver=2.7-12;arch=hppa;stamp=1213186288

The tst-regex test can hang for any number of reasons. The workaround
is to timeout the test.

Workaround is already upstream here:
http://sourceware.org/bugzilla/show_bug.cgi?id=6653

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#489856: glibc: FTBFS on hppa

[Carlos O'Donell]

On Tue, Jul 8, 2008 at 12:04 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
 Workaround is already upstream here:
 http://sourceware.org/bugzilla/show_bug.cgi?id=6653


 I don't really like this workaround, this just means that every program
 that use a regex and an UTF-8 locale will hang...

In case I wasn't clear, the solution is to backport the patch for
BZ#6653, thus allowing tst-regex to timeout *instead* of timing out
the buildd.

Cheers,
Carlos.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#489856: glibc: FTBFS on hppa

[Carlos O'Donell]

On Tue, Jul 8, 2008 at 12:09 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
 Carlos O'Donell a écrit :
 On Tue, Jul 8, 2008 at 12:04 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
 Workaround is already upstream here:
 http://sourceware.org/bugzilla/show_bug.cgi?id=6653

 I don't really like this workaround, this just means that every program
 that use a regex and an UTF-8 locale will hang...

 In case I wasn't clear, the solution is to backport the patch for
 BZ#6653, thus allowing tst-regex to timeout *instead* of timing out
 the buildd.

 I understand, that with the patch the build will succeed. But that just
 means we will have a broken glibc in unstable. I consider that test
 important enough to not ignore it.

Eventually all the tests will be migrated to the test-skeleton
framework, and then the buildd will *never* timeout. Relying on the
tests to timeout the buildd will eventually cause a broken glibc to be
uploaded. There should be a post-build step that scans the error logs
and fails the build.

I posted a patch for this in 2004 here:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg08830.html

Aurel, what do you think?

 FYI, I am working on the problem, it *seems* the problem is due to the
 switch to 2.6.25 kernel headers.

Thanks.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#434799: FTBFS (hppa): undefined reference to `THREAD_GSCOPE_RESET_FLAG'

[Carlos O'Donell]

On 7/26/07, dann frazier [EMAIL PROTECTED] wrote:
 Package: glibc
 Version: 2.6-4
 Severity: serious

 From:
  
 http://buildd.debian.org/fetch.cgi?pkg=glibcver=2.6-4arch=hppastamp=1185478685file=log

 [snip]
 gcc-4.2   -nostdlib -nostartfiles -shared -o 
 /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so \
   -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both 
 -Wl,-z,defs   \
   /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os 
 -Wl,--version-script=/build/buildd/glibc-2.6/build-tree/hppa-libc/ld.map  
 \
   -Wl,-soname=ld.so.1 -T 
 /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so.lds
 /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function 
 `_dl_fixup':
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:110: undefined 
 reference to `THREAD_GSCOPE_RESET_FLAG'
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:103: undefined 
 reference to `THREAD_GSCOPE_SET_FLAG'
 /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function 
 `_dl_profile_fixup':
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:195: undefined 
 reference to `THREAD_GSCOPE_SET_FLAG'
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:203: undefined 
 reference to `THREAD_GSCOPE_RESET_FLAG'
 /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function 
 `_dl_scope_free':
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:195: undefined 
 reference to `THREAD_GSCOPE_WAIT'
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:181: undefined 
 reference to `THREAD_GSCOPE_WAIT'
 /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function 
 `add_to_global':
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:162: undefined 
 reference to `atomic_write_barrier'
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:145: undefined 
 reference to `THREAD_GSCOPE_WAIT'
 /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function 
 `dl_open_worker':
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:478: undefined 
 reference to `atomic_write_barrier'
 /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function 
 `_dl_close_worker':
 /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-close.c:499: undefined 
 reference to `THREAD_GSCOPE_WAIT'
 collect2: ld returned 1 exit status
 make[3]: *** [/build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so] Error 1
 make[3]: Leaving directory `/build/buildd/glibc-2.6/build-tree/glibc-2.6/elf'
 make[2]: *** [elf/subdir_lib] Error 2
 make[2]: Leaving directory `/build/buildd/glibc-2.6/build-tree/glibc-2.6'
 make[1]: *** [all] Error 2
 make[1]: Leaving directory `/build/buildd/glibc-2.6/build-tree/hppa-libc'
 make: *** [/build/buildd/glibc-2.6/stamp-dir/build_libc] Error 2

Aurelian already has posted a patch for this. I also have a local
patch for this but I haven't pushed upstream. Thanks for the report
Dan.

Cheers,
Carlos.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#189552: You cannot remove conffiles and expect dpkg -i to reinstall them.

[Carlos O'Donell]

I'm helping cleanup some of the dpkg bugs so here goes.

In response to the poster here that says magicfilter is no longer
properly installing the filters, he is incorrect.

The filters are conffiles as far as dpkg is concerned. If you move the
conffiles away, remove the package, and reinstall. There is no reason
for dpkg to touch the conffiles. Infact it would be wrong if they were
reinstalled.

You must issue a purge before the reinstall for the conffiles to be
installed.

I would preculde any and all problems with magicfilter and dpkg, I went
through the process described the bug initiator without any problems,
including both debug display levels (-D2 and -D100).

Test system:
ii  magicfilter  1.2-58   automatic printer filter
ii  libc62.3.2.ds1-18 GNU C Library: Shared libraries
ii  dpkg 1.10.24  Package maintenance system for 
Debian

Thus a solution for the submitter is the following:

a. Copy the conffiles away.
b. dpkg -P package
c. dpkg -i package.deb
d. Put some conffiles back.

There is a secondary issue of dpkg crashing usind -D2, I cannot
reproduce this with the current dpkg.

IMO this is the same issue as seen with the xlibs_4.2.1-6_i386.deb
package. A question to the submitter? Did you delete the files and then
expect that a reinstall would solve the problem?

The file xkb/keymaps/xfree86 is a conffile of xlibs, and again follows
the policy manual. The conffile will *not* be overwritten or reinstalled
until after a purge.

IMO both this and bug #189555 at non-issues.

The real issue is dpkg crashing at -D2.

Cheers,
Carlos.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]