Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi,

>Note: I didn't put an entry to close this bug because I intend to

>retitle it, lower the severity, and still look for a cause/fix.  This
>seems better to me than closing the bug and opening a new one for follow

>up.

looks good to me, sponsored!
G:

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

I've prepared a new package and uploaded it to mentors:

https://mentors.debian.net/debian/pool/main/x/xerces-c/xerces-c_3.1.4+debian-2.dsc


If someone wants to test and/or upload it, I would appreciate it.

Note: I didn't put an entry to close this bug because I intend to
retitle it, lower the severity, and still look for a cause/fix.  This
seems better to me than closing the bug and opening a new one for follow
up.


Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Fri, Dec 16, 2016 at 08:25:02AM +, Gianfranco Costamagna wrote:
> Hi,
> 
> 
> >export DEB_BUILD_MAINT_OPTIONS=noopt
> 
> >
> >to the top of d/rules and rebuilding should do it.
> 
> 
> it worked:
> DEB_BUILD_OPTIONS=noopt dpkg-buildpackage
> 
> [...]
> 

Interesting.  Under the emulator some of the floating point tests fail.
But it is an emulator, so maybe it's not perfect.

I also compared compiler defaults between Ubuntu and Debian, and tried
some other flags and settings that might be relevant, but so far I
haven't found anything else that's helpful.

I'd still like to find the root cause and fix it, but in the interest of
getting it solved before the freeze, I'd like to build the s390x
package with O1 and continue building the rest of the archs with O2.

If there are no objections, I can have a package ready for upload later
today.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi,


>export DEB_BUILD_MAINT_OPTIONS=noopt

>
>to the top of d/rules and rebuilding should do it.


it worked:
DEB_BUILD_OPTIONS=noopt dpkg-buildpackage

[...]


dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/libxerces-c-samples/usr/bin/SAXPrint 
debian/libxerces-c-samples/usr/bin/SEnumVal 
debian/libxerces-c-samples/usr/bin/SAX2Count 
debian/libxerces-c-samples/usr/bin/SAXCount 
debian/libxerces-c-samples/usr/bin/EnumVal 
debian/libxerces-c-samples/usr/bin/XInclude 
debian/libxerces-c-samples/usr/bin/PParse 
debian/libxerces-c-samples/usr/bin/StdInParse 
debian/libxerces-c-samples/usr/bin/SAX2Print 
debian/libxerces-c-samples/usr/bin/DOMPrint 
debian/libxerces-c-samples/usr/bin/DOMCount 
debian/libxerces-c-samples/usr/bin/PSVIWriter 
debian/libxerces-c-samples/usr/bin/Redirect 
debian/libxerces-c-samples/usr/bin/MemParse 
debian/libxerces-c-samples/usr/bin/SCMPrint 
debian/libxerces-c-samples/usr/bin/CreateDOMDocument were not linked against 
libicudata.so.57 (they use none of the library's symbols)
dh_installdeb
dh_gencontrol
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dh_md5sums
dh_builddeb
dpkg-deb: building package 'libxerces-c-dev' in 
'../libxerces-c-dev_3.1.4+debian-1_s390x.deb'.
dpkg-deb: building package 'libxerces-c3.1-dbgsym' in 
'../libxerces-c3.1-dbgsym_3.1.4+debian-1_s390x.deb'.
dpkg-deb: building package 'libxerces-c3.1' in 
'../libxerces-c3.1_3.1.4+debian-1_s390x.deb'.
dpkg-deb: building package 'libxerces-c-doc' in 
'../libxerces-c-doc_3.1.4+debian-1_all.deb'.
dpkg-deb: building package 'libxerces-c-samples-dbgsym' in 
'../libxerces-c-samples-dbgsym_3.1.4+debian-1_s390x.deb'.
dpkg-deb: building package 'libxerces-c-samples' in 
'../libxerces-c-samples_3.1.4+debian-1_s390x.deb'.
dpkg-genbuildinfo
dpkg-genbuildinfo: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dpkg-genchanges  >../xerces-c_3.1.4+debian-1_s390x.changes
dpkg-genchanges: info: including full source code in upload
dpkg-source --after-build xerces-c-3.1.4+debian
dpkg-buildpackage: info: full upload (original source is included)



G.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On a whim, I decided to install the Hercules s390 emulator and see if I
could reproduce the problem there.  It's slow (4+ hours to do a build of
xerces) but it appears to work, and the issue shows up there as well.

I started trying to trace down the memory issue in real time, but the
variables I needed to inspect had been optimized out.  As it turns out,
building with reduced/no optimization (I tested both -O1 and -O0) allows
all of the tests to pass except for one (XSValueTest).  Can someone
please confirm this on the porterbox?

Adding

export DEB_BUILD_MAINT_OPTIONS=noopt

to the top of d/rules and rebuilding should do it.

Thanks!

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Wed, Dec 14, 2016 at 07:11:12AM +, Gianfranco Costamagna wrote:
> 
> >So while I'm not sure it will help, there might be benefit to try to get a
> >stack trace from DOMCount.  It's possible there's an exception being
> >thrown but it's getting caught/squashed.  If someone wants to try to get
> >a stack trace, the command will be
> >
> >libtool --mode=execute gdb --args samples/DOMCount samples/data/personal.xml
> >
> >and the steps inside of gdb will be the same as before.
> 
> 
> 
> http://paste.debian.net/902113/
> 
> G.


Segfault trying to read from a buffer...  That goes along well with what
I saw in the previous program, and makes me think I'm on the right track.

Thanks!

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

>So while I'm not sure it will help, there might be benefit to try to get a
>stack trace from DOMCount.  It's possible there's an exception being
>thrown but it's getting caught/squashed.  If someone wants to try to get
>a stack trace, the command will be
>
>libtool --mode=execute gdb --args samples/DOMCount samples/data/personal.xml
>
>and the steps inside of gdb will be the same as before.



http://paste.debian.net/902113/

G.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Tue, Dec 13, 2016 at 11:15:26PM +, Gianfranco Costamagna wrote:
> 
> http://paste.debian.net/902086/
> 
>  ^^ this is the file you requested
> 
> G.

That's great.  As I had hoped, ignoring that exception allows SAXCount
to complete successfully, and with the expected output (despite the
possible memory leak and/or corruption that is still an issue).

It now appears to be failing later in the test process. This time
there's no exception terminating the program, rather, it's just not
printing what it's supposed to be printing.

Although, SAXCount should have caught and handled the exception we saw
there, but somehow it skipped the handler and terminated the program
rather than being caught and handled.

So while I'm not sure it will help, there might be benefit to try to get a
stack trace from DOMCount.  It's possible there's an exception being
thrown but it's getting caught/squashed.  If someone wants to try to get
a stack trace, the command will be

libtool --mode=execute gdb --args samples/DOMCount samples/data/personal.xml

and the steps inside of gdb will be the same as before.


In the mean time, I'll dig back into the source.

Thanks!

Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi,

>Was that the only exception?  If so, that exception gets thrown (and

>handled) even on a successful run.  In which case, can you post the
>test-results.log?


yes, the only one
(gdb) continue
Continuing.
samples/data/personal.xml: 40029473 ms (37 elems, 12 attrs, 134 spaces, 134 
chars)
[Inferior 1 (process 31957) exited normally]
(gdb) 


(mattia please confirm)


http://paste.debian.net/902086/

 ^^ this is the file you requested

G.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Tue, Dec 13, 2016 at 12:06:46PM +, Gianfranco Costamagna wrote:
> Hi
> 
> 
> >Based on the stack trace, the exception is thrown because a managed
> 
> >buffer that is being freed isn't actually registered to the buffer manager.
> >his shouldn't happen, since the only way to get a buffer is to request
> >it from the manager in the first place.  It's possible there's a memory
> >corruption bug somewhere.
> >
> >What I'd like to do is see what happens if the program doesn't abort at
> >that point.  Not freeing the buffer will lead to a memory leak, so it's
> >not a fix, but seeing what happens without the exception being thrown
> >could give useful data.
> >
> >The attached patch comments out the line that throws the exception,
> >causing the function to simply return.  This should let the program
> >continue running, hopefully producing useful output (whether correct or not).
> >
> >Could someone please apply the patch and rebuild?
> 
> 
> http://paste.debian.net/901967/
> 
> does this help?
> 
> G.

Was that the only exception?  If so, that exception gets thrown (and
handled) even on a successful run.  In which case, can you post the
test-results.log?

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi


>Based on the stack trace, the exception is thrown because a managed

>buffer that is being freed isn't actually registered to the buffer manager.
>his shouldn't happen, since the only way to get a buffer is to request
>it from the manager in the first place.  It's possible there's a memory
>corruption bug somewhere.
>
>What I'd like to do is see what happens if the program doesn't abort at
>that point.  Not freeing the buffer will lead to a memory leak, so it's
>not a fix, but seeing what happens without the exception being thrown
>could give useful data.
>
>The attached patch comments out the line that throws the exception,
>causing the function to simply return.  This should let the program
>continue running, hopefully producing useful output (whether correct or not).
>
>Could someone please apply the patch and rebuild?


http://paste.debian.net/901967/

does this help?

G.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

Based on the stack trace, the exception is thrown because a managed
buffer that is being freed isn't actually registered to the buffer manager.
This shouldn't happen, since the only way to get a buffer is to request
it from the manager in the first place.  It's possible there's a memory
corruption bug somewhere.

What I'd like to do is see what happens if the program doesn't abort at
that point.  Not freeing the buffer will lead to a memory leak, so it's
not a fix, but seeing what happens without the exception being thrown
could give useful data.

The attached patch comments out the line that throws the exception,
causing the function to simply return.  This should let the program
continue running, hopefully producing useful output (whether correct or not).

Could someone please apply the patch and rebuild?

Thanks,
Bill

diff --git a/src/xercesc/framework/XMLBufferMgr.cpp b/src/xercesc/framework/XMLBufferMgr.cpp
index 327f8de..2068233 100644
--- a/src/xercesc/framework/XMLBufferMgr.cpp
+++ b/src/xercesc/framework/XMLBufferMgr.cpp
@@ -108,7 +108,7 @@ void XMLBufferMgr::releaseBuffer(XMLBuffer& toRelease)
 }
 
 // It was not a legal buffer
-ThrowXMLwithMemMgr(RuntimeException, XMLExcepts::BufMgr_BufferNotInPool, fMemoryManager);
+//ThrowXMLwithMemMgr(RuntimeException, XMLExcepts::BufMgr_BufferNotInPool, fMemoryManager);
 }
 
 XERCES_CPP_NAMESPACE_END

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

> 
> It still fails the very same way.
> Attached the backtrace I get with the way you said above (without
> exporting anything).  It seems to really be full, what Gianfranco posted
> looks more like the non-full/regular bt, dunno why.

Thanks.  Disregard my other email.

GDB didn't find the debug symbols for the other backtrace, but for yours
it did.  This could help.

Thanks,
Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Mattia Rizzolo]

On Sun, Dec 11, 2016 at 01:54:36PM -0500, Bill Blough wrote:
> On Sun, Dec 11, 2016 at 07:43:08PM +0100, Mattia Rizzolo wrote:
> > On Sun, Dec 11, 2016 at 01:34:18PM -0500, Bill Blough wrote:
> > > I just found a reference in the Debian Maintainer's Guide that says the
> > > default build locale is C.  And it looks like the Ubuntu build is
> > > explicitly setting a locale of C.UTF-8.
> > 
> > Where is that?
> 
> I misspoke, it's not the Debian Maintainer's Guide, but the "Guide for
> Debian Maintainers"
> 
> https://www.debian.org/doc/manuals/debmake-doc/ch07.en.html#utf-8-build

Yeah, well, that's not Debian Policy, so it is not so authoritative...

> > Really, in Debian there is no "default build locale", and I've seen RC
> > bugs for packages failing to build in non-C locales.
> > See also the Reproducible Builds project, which is making sure packages
> > built in different locales are always the same.
> 
> The link above says
> 
>   The default locale of the build environment is C
> 
> I certainly agree that we shouldn't be using arbitrary locales, but here
> I'm talking about using C.UTF-8, which the above link says should be
> used when necessary.

Of course.  What I'm saying is that you can't assume that your build is
going to happen in a known locale.  If your build system depends on a
locale you need to assure that's available and set.

> > > Would you be willing to add
> > > 
> > > LC_ALL := C.UTF-8
> > > export LC_ALL
> > > 
> > > to the top of debian/rules and try another build?
> > 
> > running.

It still fails the very same way.
Attached the backtrace I get with the way you said above (without
exporting anything).  It seems to really be full, what Gianfranco posted
looks more like the non-full/regular bt, dunno why.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
(sid_s390x-dchroot)mattia@zelenka ~/xerces/xerces-c-3.1.4+debian % libtool 
--mode=execute gdb --args samples/SAXCount samples/data/personal.xml
GNU gdb (Debian 7.11.1-2+b1) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/home/mattia/xerces/xerces-c-3.1.4+debian/samples/.libs/SAXCount...done.
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run
Starting program: 
/home/mattia/xerces/xerces-c-3.1.4+debian/samples/.libs/SAXCount 
samples/data/personal.xml
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".

Catchpoint 1 (exception thrown), 0x03fffbcb49b4 in __cxa_throw () from 
/usr/lib/s390x-linux-gnu/libstdc++.so.6
(gdb) bt full
#0  0x03fffbcb49b4 in __cxa_throw () from 
/usr/lib/s390x-linux-gnu/libstdc++.so.6
No symbol table info available.
#1  0x03fffddb4948 in xercesc_3_1::ReaderMgr::popReader 
(this=0x2b2d838) at xercesc/internal/ReaderMgr.cpp:1083
prevEntity = 0x2b3d488
prevReaderThrowAtEnd = true
readerNum = 3
this = 0x2b2d838
#2  0x03fffddb500c in xercesc_3_1::ReaderMgr::skipPastSpaces 
(this=0x2b2d838) at xercesc/internal/ReaderMgr.cpp:273
tmpFlag = true
#3  0x03fffde59ee8 in xercesc_3_1::DTDScanner::scanExtSubsetDecl 
(this=this@entry=0x3ffe398, inIncludeSect=inIncludeSect@entry=false,
isDTD=isDTD@entry=true) at xercesc/validators/DTD/DTDScanner.cpp:2588
nextCh = 
bDoBreak = false
janContentFlag = {fOldVal = false, fValPtr = 0x3ffe3d0}
bAcceptDecl = false
bbSpace = { = {}, fBuffer = 
, fMgr = 0x2b2d8f0}
orgReader = 3
inMarkup = false
inCharData = false
#4  0x03fffdda1b72 in xercesc_3_1::IGXMLScanner::scanDocTypeDecl 
(this=0x2b2d768) at xercesc/internal/IGXMLScanner.cpp:1544
reader = 0x3fffb1ed018
gDTDStr = {68, 84, 68, 0}
declDTD = 0x2b3d488
janDecl = { = {}, fData = 
0x2b3d488}
srcUsed = 0x2b3da68
janSrc = { = {}, fData = 
0x2b3da68}
skippedSomething = true
bbRootName = { = {}, fBuffer = 
@0x2b38e48, fMgr = }
colonPosition = 1
validName = 

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sun, Dec 11, 2016 at 07:43:08PM +0100, Mattia Rizzolo wrote:
> On Sun, Dec 11, 2016 at 01:34:18PM -0500, Bill Blough wrote:
> > I just found a reference in the Debian Maintainer's Guide that says the
> > default build locale is C.  And it looks like the Ubuntu build is
> > explicitly setting a locale of C.UTF-8.
> 
> Where is that?

I misspoke, it's not the Debian Maintainer's Guide, but the "Guide for
Debian Maintainers"

https://www.debian.org/doc/manuals/debmake-doc/ch07.en.html#utf-8-build

> Really, in Debian there is no "default build locale", and I've seen RC
> bugs for packages failing to build in non-C locales.
> See also the Reproducible Builds project, which is making sure packages
> built in different locales are always the same.

The link above says

  The default locale of the build environment is C

I certainly agree that we shouldn't be using arbitrary locales, but here
I'm talking about using C.UTF-8, which the above link says should be
used when necessary.


> 
> > Would you be willing to add
> > 
> > LC_ALL := C.UTF-8
> > export LC_ALL
> > 
> > to the top of debian/rules and try another build?
> 
> running.
> 

Thanks very much.

Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sun, Dec 11, 2016 at 06:20:13PM +, Mattia Rizzolo wrote:
> anyhow, 1) build should not depend on the locale it runs
I'll admit, I don't know a lot about locales, etc., but some of the
tests use files in UTF-8.  Wouldn't that generally require UTF-8 support
from the locale?

> 2) afaik it isn't any different than other archs
Yes, that's true, but I've seen arch-dependent locale issues in the
past.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Mattia Rizzolo]

On Sun, Dec 11, 2016 at 01:34:18PM -0500, Bill Blough wrote:
> I just found a reference in the Debian Maintainer's Guide that says the
> default build locale is C.  And it looks like the Ubuntu build is
> explicitly setting a locale of C.UTF-8.

Where is that?
Really, in Debian there is no "default build locale", and I've seen RC
bugs for packages failing to build in non-C locales.
See also the Reproducible Builds project, which is making sure packages
built in different locales are always the same.

> Would you be willing to add
> 
> LC_ALL := C.UTF-8
> export LC_ALL
> 
> to the top of debian/rules and try another build?

running.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sun, Dec 11, 2016 at 05:57:38PM +, Gianfranco Costamagna wrote:
> Hi,
> 
> >Does anyone know (or can find out) the default locale on the s390
> >systems, and does that differ from the other architectures?
> >
> >env | egrep "(LC|LANG)"
> >
> >should give a list of relevant vars.
> 
> 
> (not sure if it is related to my laptop configuration, I did ssh and 
> copy-pasted)
> 
> locutusofborg@zelenka:~$ uname -a
> Linux zelenka 3.16.0-4-s390x #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) 
> s390x GNU/Linux
> locutusofborg@zelenka:~$ env | egrep "(LC|LANG)"
> LC_PAPER=it_IT.UTF-8
> LC_ADDRESS=it_IT.UTF-8
> LC_MONETARY=it_IT.UTF-8
> LC_NUMERIC=it_IT.UTF-8
> LC_TELEPHONE=it_IT.UTF-8
> LC_IDENTIFICATION=it_IT.UTF-8
> LANG=en_US.UTF-8
> LC_MEASUREMENT=it_IT.UTF-8
> LC_TIME=it_IT.UTF-8
> LC_NAME=it_IT.UTF-8
> 

Hmm... That must be set by ssh based on your local environment.

I just found a reference in the Debian Maintainer's Guide that says the
default build locale is C.  And it looks like the Ubuntu build is
explicitly setting a locale of C.UTF-8.

I've run into locale-related issues that affected one architecture but not
others (though it was i386 vs amd64 in that case), and since we're
dealing with an ICU update, and the runtime exception is dealing with a
bad buffer (which could mean there was a buffer, but it was the
incorrect size), I'm thinking this could be locale related. But
admittedly, it's a shot in the dark.

Would you be willing to add

LC_ALL := C.UTF-8
export LC_ALL

to the top of debian/rules and try another build?  Or I could prepare
another package with the changes if you'd rather not muck with editing
files.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Mattia Rizzolo]

On Sun, Dec 11, 2016 at 6:57 PM Gianfranco Costamagna <
costamagnagianfra...@yahoo.it> wrote:

> (not sure if it is related to my laptop configuration, I did ssh and
> copy-pasted)
>

Yep, ssh transfers LC_* variables.

anyhow, 1) build should not depend on the locale it runs 2) afaik it isn't
any different than other archs

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi,

>Does anyone know (or can find out) the default locale on the s390
>systems, and does that differ from the other architectures?
>
>env | egrep "(LC|LANG)"
>
>should give a list of relevant vars.


(not sure if it is related to my laptop configuration, I did ssh and 
copy-pasted)

locutusofborg@zelenka:~$ uname -a
Linux zelenka 3.16.0-4-s390x #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) s390x 
GNU/Linux
locutusofborg@zelenka:~$ env | egrep "(LC|LANG)"
LC_PAPER=it_IT.UTF-8
LC_ADDRESS=it_IT.UTF-8
LC_MONETARY=it_IT.UTF-8
LC_NUMERIC=it_IT.UTF-8
LC_TELEPHONE=it_IT.UTF-8
LC_IDENTIFICATION=it_IT.UTF-8
LANG=en_US.UTF-8
LC_MEASUREMENT=it_IT.UTF-8
LC_TIME=it_IT.UTF-8
LC_NAME=it_IT.UTF-8




G.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

Does anyone know (or can find out) the default locale on the s390
systems, and does that differ from the other architectures?

env | egrep "(LC|LANG)"

should give a list of relevant vars.

Thanks,
Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sat, Dec 10, 2016 at 08:56:29AM +, Gianfranco Costamagna wrote:
> 
> >  libtool --mode=execute gdb --args samples/SAXCount 
> > samples/data/personal.xml
> > catch throw
> >
> >  bt full
> >continue
> > quit
> >This will hopefully help me to isolate this issue.
> >
> 
> 
> here we are!
> http://paste.debian.net/901516/

Thanks, looking into it.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi,

>

>  libtool --mode=execute gdb --args samples/SAXCount samples/data/personal.xml
> catch throw
>
>  bt full
>continue
> quit
>This will hopefully help me to isolate this issue.
>


here we are!
http://paste.debian.net/901516/


G.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sat, Dec 10, 2016 at 02:25:08AM +0100, Mattia Rizzolo wrote:
> On Fri, Dec 09, 2016 at 08:11:54PM -0500, Bill Blough wrote:
> > > >Or does anyone have other suggestions?
> 
> I have one: please try to CC people (and/or MLs) sooner.  I now noticed
> that you asked for help more than one month ago, but I wasn't aware of
> that at all.  And now the freeze is hovering upon us.

Yes, fair enough.  That's my mistake.

> 
> > In the mean time, would it be possible to get a
> > stack trace showing the exception thrown by any one of the test
> > programs?
> 
> I got a build in the s390x porterbox, and reproduced the failure; at
> least, near enough, mine says
> diff test-results.log ./scripts/sanityTest_ExpectedResult.log
> Binary files test-results.log and ./scripts/sanityTest_ExpectedResult.log 
> differ
> Makefile:950: recipe for target 'check' failed
> Instead of actually showing the diff.
> 
> I'm happy to provide stacktraces and/or core dumps if you can tell me
> how to get them without me needed to figure things out.

After the build completes, from the build root, run

  libtool --mode=execute gdb --args samples/SAXCount samples/data/personal.xml

At the GDB prompt, type

  catch throw

then

  run

It will stop, saying exception thrown. To generate the stack trace, type

  bt full

There will likely be several screens of data.  If you could please
copy/paste them all. Once you're back at the gdb prompt, that's the end of
that trace.

Because there may be multiple exceptions thrown (including as part of
normal operation), I'd appreciate a stack trace of all of them.
Unfortunately, I don't know how many there will be.  On my (working) system
there's only one before successful completion.  Hopefully there won't be
much more than two on the failing system, but depending on the failure
there could be several.

>From the gdb prompt, typing

 continue

will continue execution until the next exception, at which point you can
repeat from the "bt full" step above.

Once you get a message saying the process exited, it's done, and you can
exit by typing

  quit


This will hopefully help me to isolate this issue.

Thanks for your help.

Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Mattia Rizzolo]

On Fri, Dec 09, 2016 at 08:11:54PM -0500, Bill Blough wrote:
> > >Or does anyone have other suggestions?

I have one: please try to CC people (and/or MLs) sooner.  I now noticed
that you asked for help more than one month ago, but I wasn't aware of
that at all.  And now the freeze is hovering upon us.

> In the mean time, would it be possible to get a
> stack trace showing the exception thrown by any one of the test
> programs?

I got a build in the s390x porterbox, and reproduced the failure; at
least, near enough, mine says
diff test-results.log ./scripts/sanityTest_ExpectedResult.log
Binary files test-results.log and ./scripts/sanityTest_ExpectedResult.log 
differ
Makefile:950: recipe for target 'check' failed
Instead of actually showing the diff.

I'm happy to provide stacktraces and/or core dumps if you can tell me
how to get them without me needed to figure things out.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Fri, Dec 09, 2016 at 11:07:54PM +, Gianfranco Costamagna wrote:
> >Can anyone comment on the use of -Bsymbolic_functions in Ubuntu?  If I
> >understand it correctly, it shouldn't have any effect on this, but I
> >have no way to test it other than another upload.
> 
> 
> I still prefer the default -Ofoo different as root cause
> 

According to the build logs, both are being compiled with -O2.  The only
difference I see in the build flags is the symbolic-functions link flag
I referenced earlier.  But as I said, I don't see how that would affect
it.


> >Assuming that's not it, would someone be willing to sponsor access to the 
> >s390x
> >porter box so I can get this sorted out?
> 
> 
> not so easy :/ are you a dm?

Unfortunately, not yet.  I hope to change that soon.


> 
> >Or does anyone have other suggestions?
> 
> 
> https://ufile.io/f0872
> 
> I did a build, and uploaded the whole build directory on that file, including
> 
> a complete build log (in the root directory), let me know if it sounds good 
> to you to debug
> building after export C{,PP,XX}FLAGS=-O3 didn't help either

Thanks, I really appreciate that. I'll look through it and see if I can
find any new leads.  In the mean time, would it be possible to get a
stack trace showing the exception thrown by any one of the test
programs?

Thanks,
Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi Bill,


>I'd really like to get this resolved before the freeze.
>
>Can anyone comment on the use of -Bsymbolic_functions in Ubuntu?  If I
>understand it correctly, it shouldn't have any effect on this, but I
>have no way to test it other than another upload.


I still prefer the default -Ofoo different as root cause

>Assuming that's not it, would someone be willing to sponsor access to the s390x
>porter box so I can get this sorted out?


not so easy :/ are you a dm?

>Or does anyone have other suggestions?


https://ufile.io/f0872

I did a build, and uploaded the whole build directory on that file, including

a complete build log (in the root directory), let me know if it sounds good to 
you to debug
building after export C{,PP,XX}FLAGS=-O3 didn't help either

G.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

I'd really like to get this resolved before the freeze.

Can anyone comment on the use of -Bsymbolic_functions in Ubuntu?  If I
understand it correctly, it shouldn't have any effect on this, but I
have no way to test it other than another upload.

Assuming that's not it, would someone be willing to sponsor access to the s390x
porter box so I can get this sorted out?

Or does anyone have other suggestions?

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi,


> > Hey William, did you have a chance to look at this bug? i couldnt find
> > much on the upstream bug tracker but there is also a 3.1.4 new release
> > you might want to test if fixes this bug else report it upstream.
> > thanks!!
the new release didn't work, but the same build worked on Ubuntu s390x

https://launchpad.net/ubuntu/+source/xerces-c/3.1.4+debian-1~build1/+build/11163393

I know Ubuntu should have a different optimization default for gcc, probably 
-O3,
so this might give some clues about what is wrong in Debian
(also looking for differences in package versions might help)
G.



signature.asc
Description: OpenPGP digital signature

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

I looked at it briefly, but had to refocus on  other issues before I
could really get anywhere. I'll get it sorted out and/or forwarded
shortly.

Thanks for the ping!

On Thu, Nov 03, 2016 at 04:10:27PM -0400, Sandro Tosi wrote:
> On Mon, 8 Aug 2016 13:24:48 + Mattia Rizzolo  wrote:
> > source: xerces-c
> > version: 3.1.3+debian-2.1
> > severity: serious
> >
> > Dear maintainer,
> >
> > your package failed to build on buildds on the s390x architecure only
> > during a rebuild for the transition to icu57, using gcc6 as compiler.
> > You can see the build log at:
> > https://buildd.debian.org/status/fetch.php?pkg=xerces-c=s390x=3.1.3%2Bdebian-2.1%2Bb1=1470418530
> 
> Hey William, did you have a chance to look at this bug? i couldnt find
> much on the upstream bug tracker but there is also a 3.1.4 new release
> you might want to test if fixes this bug else report it upstream.
> thanks!!

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Sandro Tosi]

On Mon, 8 Aug 2016 13:24:48 + Mattia Rizzolo  wrote:
> source: xerces-c
> version: 3.1.3+debian-2.1
> severity: serious
>
> Dear maintainer,
>
> your package failed to build on buildds on the s390x architecure only
> during a rebuild for the transition to icu57, using gcc6 as compiler.
> You can see the build log at:
> https://buildd.debian.org/status/fetch.php?pkg=xerces-c=s390x=3.1.3%2Bdebian-2.1%2Bb1=1470418530

Hey William, did you have a chance to look at this bug? i couldnt find
much on the upstream bug tracker but there is also a 3.1.4 new release
you might want to test if fixes this bug else report it upstream.
thanks!!