Обсуждение: recent --with-libxml support
I adjusted my buildfarm config (mongoose) to attempt to build HEAD
--with-libxml. I added the following to build-farm.conf:
if ($branch eq 'HEAD' || $branch ge 'REL8_3')
{ push(@{$conf{config_opts}},
"--with-includes=/usr/include/et:/usr/include/libxml2"); push(@{$conf{config_opts}}, "--with-libxml");
}
As seen, I needed to add an include dir for configure to pass. However,
make check fails now with the backend crashing. This can be seen in the
buildfarm results for mongoose.
According to gentoo portage, I have libxml2 version 2.6.26 installed on my
system.
I am not clear if I should have pointed it at libxml version 1 or 2, but
configure seemed to be happy with libxml2. If it needs version 1, perhaps
configure should do something to keep it from using version 2.
Here is the diff for the xml regression test:
*** ./expected/xml.out Thu Dec 21 16:47:22 2006
--- ./results/xml.out Thu Dec 21 16:59:32 2006
***************
*** 58,68 **** SELECT xmlelement(name element, xmlattributes (1 as one, 'deuce' as two),
'content');
! xmlelement
! ------------------------------------------------
! <element one="1" two="deuce">content</element>
! (1 row)
! SELECT xmlelement(name element, xmlattributes ('unnamed and wrong')); ERROR: unnamed attribute
valuemust be a column reference
--- 58,64 ---- SELECT xmlelement(name element, xmlattributes (1 as one, 'deuce' as two),
'content');
! ERROR: cache lookup failed for type 0 SELECT xmlelement(name element, xmlattributes ('unnamed and
wrong'));ERROR: unnamed attribute value must be a column reference
***************
*** 73,145 **** (1 row)
SELECT xmlelement(name employee, xmlforest(name, age, salary as pay)) FROM emp;
! xmlelement
! ----------------------------------------------------------------------
! <employee><name>sharon</name><age>25</age><pay>1000</pay></employee>
! <employee><name>sam</name><age>30</age><pay>2000</pay></employee>
! <employee><name>bill</name><age>20</age><pay>1000</pay></employee>
! <employee><name>jeff</name><age>23</age><pay>600</pay></employee>
! <employee><name>cim</name><age>30</age><pay>400</pay></employee>
! <employee><name>linda</name><age>19</age><pay>100</pay></employee>
! (6 rows)
!
! SELECT xmlelement(name wrong, 37);
! ERROR: argument of XMLELEMENT must be type xml, not type integer
! SELECT xmlpi(name foo);
! xmlpi
! ---------
! <?foo?>
! (1 row)
!
! SELECT xmlpi(name xmlstuff);
! ERROR: invalid XML processing instruction
! DETAIL: XML processing instruction target name cannot start with "xml".
! SELECT xmlpi(name foo, 'bar');
! xmlpi
! -------------
! <?foo bar?>
! (1 row)
!
! SELECT xmlpi(name foo, 'in?>valid');
! ERROR: invalid XML processing instruction
! DETAIL: XML processing instruction cannot contain "?>".
! SELECT xmlroot (
! xmlelement (
! name gazonk,
! xmlattributes (
! 'val' AS name,
! 1 + 1 AS num
! ),
! xmlelement (
! NAME qux,
! 'foo'
! )
! ),
! version '1.0',
! standalone yes
! );
! xmlroot
! ------------------------------------------------------------------------------------------
! <?xml version="1.0" standalone="yes"?><gazonk name="val" num="2"><qux>foo</qux></gazonk>
! (1 row)
!
! SELECT xmlserialize(content data as character varying) FROM xmltest;
! data
! --------------------
! <value>one</value>
! <value>two</value>
! (2 rows)
!
! -- Check mapping SQL identifier to XML name
! SELECT xmlpi(name ":::_xml_abc135.%-&_");
! xmlpi
! -------------------------------------------------
! <?_x003A_::_x005F_xml_abc135._x0025_-_x0026__?>
! (1 row)
!
! SELECT xmlpi(name "123");
! xmlpi
! ---------------
! <?_x0031_23?>
! (1 row)
!
--- 69,75 ---- (1 row)
SELECT xmlelement(name employee, xmlforest(name, age, salary as pay)) FROM emp;
! server closed the connection unexpectedly
! This probably means the server terminated abnormally
! before or while processing the request.
! connection to server was lost
--
The very powerful and the very stupid have one thing in common.
Instead of altering their views to fit the facts, they alter the facts
to fit their views ... which can be very uncomfortable if you happen to
be one of the facts that needs altering. -- Doctor Who, "Face of Evil"
Jeremy Drake <pgsql@jdrake.com> writes:
> As seen, I needed to add an include dir for configure to pass. However,
> make check fails now with the backend crashing. This can be seen in the
> buildfarm results for mongoose.
Can you provide a stack trace for that crash?
regards, tom lane
On Fri, 22 Dec 2006, Tom Lane wrote:
> Jeremy Drake <pgsql@jdrake.com> writes:
> > As seen, I needed to add an include dir for configure to pass. However,
> > make check fails now with the backend crashing. This can be seen in the
> > buildfarm results for mongoose.
>
> Can you provide a stack trace for that crash?
#0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6
#1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90, data=0x841ffc0 "qux", datalen=138543040) at
stringinfo.c:192
#2 0x0828377f in map_sql_identifier_to_xml_name (ident=0x841ffc0 "qux", fully_escaped=0 '\0') at xml.c:933
#3 0x0811ce83 in transformXmlExpr (pstate=0x84202b8, x=0x8420034) at parse_expr.c:1426
#4 0x0811ac91 in transformExpr (pstate=0x84202b8, expr=0x8420034) at parse_expr.c:238
#5 0x0811ceb4 in transformXmlExpr (pstate=0x84202b8, x=0x8420174) at parse_expr.c:1456
#6 0x0811ac91 in transformExpr (pstate=0x84202b8, expr=0x8420174) at parse_expr.c:238
#7 0x081288a4 in transformTargetEntry (pstate=0x84202b8, node=0x8420174, expr=0x0, colname=0x0, resjunk=0 '\0') at
parse_target.c:74
#8 0x0812890e in transformTargetList (pstate=0x84202b8, targetlist=0x1) at parse_target.c:146
#9 0x080ffcef in transformStmt (pstate=0x84202b8, parseTree=0x84201fc, extras_before=0xbfd882c4,
extras_after=0xbfd882c8)at analyze.c:2102
#10 0x08101421 in do_parse_analyze (parseTree=0x841ffc0, pstate=0x84202b8) at analyze.c:251
#11 0x0810227a in parse_analyze (parseTree=0x84201fc, sourceText=0x841ffc0 "qux", paramTypes=0x841ffc0,
numParams=138543040) at analyze.c:173
#12 0x0820b66e in pg_analyze_and_rewrite (parsetree=0x84201fc, query_string=0x841fb74 "SELECT
xmlconcat(xmlcomment('hello'),\n",' '
<repeats 17 times>, "xmlelement(NAME qux, 'foo'),\n", ' ' <repeats 17
times>, "xmlcomment('world'));", paramTypes=0x0, numParams=0) at
postgres.c:567
#13 0x0820b91e in exec_simple_query ( query_string=0x841fb74 "SELECT xmlconcat(xmlcomment('hello'),\n", ' '
<repeats 17 times>, "xmlelement(NAME qux, 'foo'),\n", ' ' <repeats 17
times>, "xmlcomment('world'));") at postgres.c:875
#14 0x0820d72b in PostgresMain (argc=4, argv=0x83c5c2c, username=0x83c5bfc "jeremyd") at postgres.c:3418
#15 0x081dfbd7 in ServerLoop () at postmaster.c:2924
#16 0x081e132c in PostmasterMain (argc=3, argv=0x83c4550) at
postmaster.c:958
#17 0x081991e0 in main (argc=3, argv=0x83c4550) at main.c:188
--
In Tennessee, it is illegal to shoot any game other than whales from a
moving automobile.
Jeremy Drake <pgsql@jdrake.com> writes:
>> Can you provide a stack trace for that crash?
> #0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6
> #1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90,
> data=0x841ffc0 "qux", datalen=138543040) at stringinfo.c:192
> #2 0x0828377f in map_sql_identifier_to_xml_name (ident=0x841ffc0 "qux",
> fully_escaped=0 '\0') at xml.c:933
Hmm ... it seems to work for me here, using Fedora 5's libxml.
Are you by any chance running this with a non-C locale? The trace
suggests an encoding-mismatch sort of issue...
regards, tom lane
On Fri, 22 Dec 2006, Tom Lane wrote: > Jeremy Drake <pgsql@jdrake.com> writes: > >> Can you provide a stack trace for that crash? > > > #0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6 > > #1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90, > > data=0x841ffc0 "qux", datalen=138543040) at stringinfo.c:192 > > #2 0x0828377f in map_sql_identifier_to_xml_name (ident=0x841ffc0 "qux", > > fully_escaped=0 '\0') at xml.c:933 > > Hmm ... it seems to work for me here, using Fedora 5's libxml. > > Are you by any chance running this with a non-C locale? The trace > suggests an encoding-mismatch sort of issue... Nope. I saw another buildfarm member that looks like it croaked in the same place: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=sponge&dt=2006-12-22%2022:30:02 So I guess it is not just me... -- If you think education is expensive, try ignorance. -- Derek Bok, president of Harvard
Jeremy Drake wrote: > #0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6 > #1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90, > data=0x841ffc0 "qux", datalen=138543040) at stringinfo.c:192 > #2 0x0828377f in map_sql_identifier_to_xml_name (ident=0x841ffc0 > "qux", fully_escaped=0 '\0') at xml.c:933 Obviously the datalen has gone off the map. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> Jeremy Drake wrote:
>> #0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6
>> #1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90,
>> data=0x841ffc0 "qux", datalen=138543040) at stringinfo.c:192
>> #2 0x0828377f in map_sql_identifier_to_xml_name (ident=0x841ffc0
>> "qux", fully_escaped=0 '\0') at xml.c:933
> Obviously the datalen has gone off the map.
I wouldn't put 100% faith in that display, unless Jeremy built with -O0.
If it is accurate then the question is how could mblen fail so badly?
regards, tom lane
On Sat, 23 Dec 2006, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Jeremy Drake wrote:
> >> #0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6
> >> #1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90,
> >> data=0x841ffc0 "qux", datalen=138543040) at stringinfo.c:192
> >> #2 0x0828377f in map_sql_identifier_to_xml_name (ident=0x841ffc0
> >> "qux", fully_escaped=0 '\0') at xml.c:933
>
> > Obviously the datalen has gone off the map.
>
> I wouldn't put 100% faith in that display, unless Jeremy built with -O0.
I built this one with gcc 3.4.5 using --enable-debug --enable-cassert
configure options. I will try with -O0 and see what I get...
--
NAPOLEON: What shall we do with this soldier, Guiseppe?Everything he says is wrong.
GUISEPPE: Make him a general, Excellency,and then everything he says will be right.
-- G. B. Shaw, "The Man of Destiny"
On Fri, 22 Dec 2006, Jeremy Drake wrote: > On Sat, 23 Dec 2006, Tom Lane wrote: > > > Peter Eisentraut <peter_e@gmx.net> writes: > > > Jeremy Drake wrote: > > >> #0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6 > > >> #1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90, > > >> data=0x841ffc0 "qux", datalen=138543040) at stringinfo.c:192 > > >> #2 0x0828377f in map_sql_identifier_to_xml_name (ident=0x841ffc0 > > >> "qux", fully_escaped=0 '\0') at xml.c:933 > > > > > Obviously the datalen has gone off the map. > > > > I wouldn't put 100% faith in that display, unless Jeremy built with -O0. > > I built this one with gcc 3.4.5 using --enable-debug --enable-cassert > configure options. I will try with -O0 and see what I get... I just tried the same thing, but passing CFLAGS="-g -O0" to configure and the xml test passed. Maybe a '\0' termination issue? I also recompiled everything with the defaults again (-O2) and the xml test crashed in the same place. So it is an issue of -O0 works vs -O2 does not. Hate those... -- When I get real bored, I like to drive downtown and get a great parking spot, then sit in my car and count how many people ask me if I'm leaving. -- Steven Wright
Jeremy Drake <pgsql@jdrake.com> writes:
> On Fri, 22 Dec 2006, Tom Lane wrote:
>> Jeremy Drake <pgsql@jdrake.com> writes:
>>> As seen, I needed to add an include dir for configure to pass. However,
>>> make check fails now with the backend crashing. This can be seen in the
>>> buildfarm results for mongoose.
>>
>> Can you provide a stack trace for that crash?
> #0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6
> #1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90,
> data=0x841ffc0 "qux", datalen=138543040) at stringinfo.c:192
> #2 0x0828377f in map_sql_identifier_to_xml_name (ident=0x841ffc0 "qux",
> fully_escaped=0 '\0') at xml.c:933
> #3 0x0811ce83 in transformXmlExpr (pstate=0x84202b8, x=0x8420034)
> at parse_expr.c:1426
> #4 0x0811ac91 in transformExpr (pstate=0x84202b8, expr=0x8420034)
> at parse_expr.c:238
Ah-hah, I've sussed it. sqlchar_to_unicode() calls the
mb2wchar_with_len converters, which are defined to return a *null
terminated* pg_wchar string. So even if you only ask for the conversion
of a single character, you need a 2-pg_wchar array to hold the result,
and that wasn't being allocated. So the code was clobbering a word of
stack space that evidently is critical on some machines and not others.
Fix committed, please see if it works for you now.
regards, tom lane
On Sat, 23 Dec 2006, Tom Lane wrote: > Ah-hah, I've sussed it. sqlchar_to_unicode() calls the > mb2wchar_with_len converters, which are defined to return a *null > terminated* pg_wchar string. So even if you only ask for the conversion > of a single character, you need a 2-pg_wchar array to hold the result, > and that wasn't being allocated. So the code was clobbering a word of > stack space that evidently is critical on some machines and not others. > > Fix committed, please see if it works for you now. The buildfarm run seems to be green now. I am compiling a sandbox to test it manually now, but I'm pretty sure that fixed it. Yep, the make check works there too... -- As long as war is regarded as wicked, it will always have its fascination. When it is looked upon as vulgar, it will cease to be popular. -- Oscar Wilde