ST_GeomFromGML crashes in Windows compiled in MingW

[robe]

I managed to get the libxml2 to compile on one of my boxes, but this crashes server

SELECT 'point_1', ST_AsEWKT(ST_GeomFromGML('<gml:Point><gml:coordinates>1,2</gml:coordinates></gml:Point>'));

Though this gives invalid as expected

SELECT 'xml_3', ST_AsEWKT(ST_GeomFromGML('<foo/>'));

I compiled using libxml2 2.7.6

​ftp://xmlsoft.org/libxml2/libxml2-sources-2.7.6.tar.gz

[colivier]

Regina,

Could you try with this debug trace lwgeom_in_gml.c and send back the output result ?

Thanks in advance,

[robe]

Olivier,

Sorry for taking so long to get back to you. Under a lot of time pressures with other projects this week so you probably won't here much from me for at least another week or 2.

Regarding the attached. It doesn't compile for me at all. Gives errors like

lwgeom_in_gml.c:2179: warning: type defaults to `int' in declaration of `name'
lwgeom_in_gml.c:2179: error: syntax error before '<' token
lwgeom_in_gml.c:2181: warning: type defaults to `int' in declaration of `name'
lwgeom_in_gml.c:2181: error: syntax error before '<' token
lwgeom_in_gml.c:2183: warning: type defaults to `int' in declaration of `name'
lwgeom_in_gml.c:2183: error: syntax error before '<' token
lwgeom_in_gml.c:2185: warning: type defaults to `int' in declaration of `name'
lwgeom_in_gml.c:2185: error: syntax error before '<' token
lwgeom_in_gml.c:2187: warning: type defaults to `int' in declaration of `name'
lwgeom_in_gml.c:2187: error: syntax error before '<' token
lwgeom_in_gml.c:2189: warning: type defaults to `int' in declaration of `name'
lwgeom_in_gml.c:2189: error: syntax error before '<' token
lwgeom_in_gml.c:2195: warning: type defaults to `int' in declaration of `geom'
lwgeom_in_gml.c:2195: error: redefinition of 'geom'
lwgeom_in_gml.c:2173: error: previous definition of 'geom' was here
lwgeom_in_gml.c:2195: error: redefinition of 'geom'
lwgeom_in_gml.c:247: error: previous definition of 'geom' was here
lwgeom_in_gml.c:2195: error: syntax error before ')' token
lwgeom_in_gml.c:2197: error: syntax error before ')' token
lwgeom_in_gml.c:2223: warning: type defaults to `int' in declaration of `xa'
lwgeom_in_gml.c:2223: error: redefinition of 'xa'
lwgeom_in_gml.c:2149: error: previous definition of 'xa' was here
lwgeom_in_gml.c:2223: error: redefinition of 'xa'
lwgeom_in_gml.c:1401: error: previous definition of 'xa' was here
lwgeom_in_gml.c:2223: warning: data definition has no type or storage class
lwgeom_in_gml.c:2223: error: syntax error before '<' token

and goes on and on. The gml in BTW works fine on my OpenSUSE 10.3 (using the same libxml source) (haven't tried my more finicky 11). Even going thru the gardent test seems to work fine.

I think its an issue with compiling libxml2 under mingW. I searched, and it seems stories are the same with the libxml crashing when compiled under mingw. Possibly threading issues or something. the compile of libxml2 also gives a ton of warnings about exceeded length of the form

.libs/lt-testModule.c:285: warning: string length `1611' is greater than the length `509' ISO C89 compilers are required to support

So I fear this may be beyond my abilities to solve. Perhaps Mark can take a stab at it when he has the time to see if there is a trick to getting this to behave correctly.

My newer mingw 4.4 compiler refuses to even compile the libxml2.

Thanks, Regina

[robe]

I did a test putting in notices and (had to put in error too because the crash prevented me from seeing the notices). Anyrate as far as I can tell -- it starts failing in parse_gml_data function r4734 -- line 846

Which looks like

if (!strcmp((char *) xa->name, "pos")) {

So I guess its either the strcmp or whatever the xa->name is returning. For what its worth none of the other code I saw in our codebase does a

strcmp((char *) ... in one step.

They always seem to declare the variable char * and use the variable, though that may be a stylistic feature rather than for some fundamental reason.

[pramsey]

The patch in trunk at r4744 fixed regression issues for me.

[robe]

Still crashes on MingW :(

[colivier]

Paul,

• Did you tryed the latest trunk version on mingw before to patch ?
• Did you have any compiler warning about uninitialized vars ?

Regina

• I (finnaly) got a win32 box, i will be able to do some test next week after PgDay
• Upon your previous post, it's possible that's more an libxml2 install issue

[pramsey]

Replying to colivier:

• Did you tryed the latest trunk version on mingw before to patch ?

No, I don't have MinGW, but I did have a crash on OS/X which initializing fixed.

• Did you have any compiler warning about uninitialized vars ?

Yes, a few, and I put initializers on those.

[colivier]

Regina,

I followed UserWikiWinCompile instructions, but i'm unable to install successfull GEOS (3.1.1 or SVN one), so PostGIS can't be compile either... The only thing i can tell is that Libxml2 2.7.6 compile without peculiar problem.

I attach a screen capture related to GEOS error. If anyone have an idea...

[colivier]

Screen capture, about GEOS error in make install step

[robe]

Olivier,

I haven't tested against 3.1.1 in a while. Been doing all my testing against GEOS 3.2.0rc1 and GEOS 3.2SVN. Its kind of cruel to give people GEOS 3.1 with 1.5 anyway since the fast buffering, new buffer features and hausdo... they would miss out on.

From what I can tell from your screen -- it looks like you have some remnants of libgeos-3-2 in there (note the /usr/local/bin/libgeos-3-2-0.dll (or that justa bad message in the geos code. Try using the GEOS 3.2 instead (note the changes you'll need to hack in your mingw I noted) to get geos 3.2 to compile.

[robe]

Forgot to mention. I did a retest after the latest code reorg and I'm thinking its not libxml but the strcmp

if (!strcmp((char *) xa->name, "pos")) {

I'm pretty sure the xa->name and xa->next are gong thru fine so it seems to be its that strcmp maybe space istn't big enough or something. I still don't understand the whole string compare thing in c. Even tsting against the libxml precompiled download form site -- it crashes in same location.

[colivier]

Regina,

You're right the install problem was the dual GEOS install. I (finnaly) succeed to install the whole stuff with Mingw (not exactly a piece of cake) !

With my install everything is fine with in_gml.sql and in_kml.sql

Postgis: r4813 Geos: 3.2.0 RC1 Libxml2: 2.7.6

I really suspect you're libxml2 installation to be the problem. Is it possible for you (or someone else) to test it on an another box ?

[robe]

Strange. Maybe its something else I install getting in the way or I'm not compiling libxml right. I have another box I can try on later. Nicklas -- you have a mingw install -- if its not asking too much -- can you try compiling and doing the simple

SELECT ST_GeomFromGML('<gml:Point><gml:coordinates>1,2</gml:coordinates></gml:Point>')

to see if it works.

Olivier - what is your mingw gcc and mingw/msys versions? On my gcc 3.5 box, I was able to compile and install without errors (except libxml make checks fail), but got crashes when doing the above test. On my upgraded mingw running gcc 4.4, I can't compile libxml at all.

[robe]

One thing I forgot to mention. I was testing against the Enterprisedb compiled PostgreSQL 8.3/8.4, not my mingw compiled version. I do that because sometimes they behave differently. For example plr works fine under my mingw compiled postgresql 84, but I for the life of me can't even get it to load in the visual c++ compiled EDB packaged PostgreSQL. So that I know I will eventually have to bite the bullet and figure out how to compile plr under vc++.

[colivier]

Regina,

• gcc 3.4.5

mingw 3.14 (i guess)

Nicklas

Indeed if libxml no present (or not well installed) ST_GeomFromGML will not be available. I just commit an enhanced postgis_full_version() to show libml2 version if any. (r4885). On previous postgis version this information is available only at the end on configure step.

[robe]

Hmm I think I'm running mingw 5.04, though not sure that matters. I did conclude its not the VC++ PG build, since it crashes under my mingw pg compiled version too. Though it starts off with a gml namespace is not defined in the logs and then crashes.

I'm going to try Mark's backtrace instructions next to narrow it down more once I get gdb loaded.

Olivier -- can you attach your postgis dll and libxml dlls so I can test on my box to verify its not some other dependency I have and just isolated to those (or the libxml). I'm guessing if I still have a crash with your working copy -- then its something else on my boxes I have installed causing the problem.

Thanks, Regina

[robe]

Here is the backtrace from both my PostgreSQL 8.4 (VC++ EDB build as well as my MingW build)

Under postgresql VC++ build
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7700.0xb20]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x68f22718 in parse_gml_data ()
   from C:\Program Files\PostgreSQL\8.4\lib\postgis-1.5.dll
#2  0x68f22e13 in parse_gml ()
   from C:\Program Files\PostgreSQL\8.4\lib\postgis-1.5.dll
#3  0x68f2430f in geom_from_gml ()
   from C:\Program Files\PostgreSQL\8.4\lib\postgis-1.5.dll
#4  0x004dbc69 in postgres!get_attavgwidth ()
#5  0x00caf708 in ?? ()
#6  0x00caf708 in ?? ()
#7  0x00caf6e8 in ?? ()
#8  0x03f8ca20 in ?? ()
#9  0x03f8c5d8 in ?? ()
#10 0x000186cf in ?? ()
#11 0x03a653d0 in ?? ()
#12 0x00000000 in ?? ()

------

MingW postgres 8.4

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6288.0x1198]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x68f22718 in parse_gml_data ()
   from C:\projects\pg\pg84\lib\postgresql\postgis-1.5.dll
#2  0x68f22e13 in parse_gml ()
   from C:\projects\pg\pg84\lib\postgresql\postgis-1.5.dll
#3  0x68f2430f in geom_from_gml ()
   from C:\projects\pg\pg84\lib\postgresql\postgis-1.5.dll
#4  0x0050363c in ExecMakeFunctionResult ()
#5  0x00506cd3 in ExecEvalExprSwitchContext ()
#6  0x0056988f in evaluate_expr ()
#7  0x0056a07f in simplify_function ()
#8  0x0056a767 in eval_const_expressions_mutator ()
#9  0x0052a733 in expression_tree_mutator ()
#10 0x0056a58a in eval_const_expressions_mutator ()
#11 0x0052ac57 in expression_tree_mutator ()
#12 0x0056a58a in eval_const_expressions_mutator ()
#13 0x0056b6ad in eval_const_expressions ()
#14 0x0055c36b in preprocess_expression ()
#15 0x03997ee0 in ?? ()
#16 0x00000001 in ?? ()
#17 0xffffffff in ?? ()
#18 0x00000000 in ?? ()

[colivier]

Regina,

Commited a patch as r4890 related to your backtrace. Worst to be tested again. I send you my .dll stuff quite soon (not the win32 laptop with me)

Tks !

[robe]

Olivier, Nope still fails with same back trace :(

Exact error I see in logs before crash is below, but of course I don't think this has anything to do with it since if I take out the gml namespaces it still crashes.

namespace error : Namespace prefix gml on Point is not defined <gml:Point><gml:coordinates>1,2</gml:coordinates></gml:Point>

namespace error : Namespace prefix gml on coordinates is not defined <gml:Point><gml:coordinates>1,2</gml:coordinates></gml:Point>

[colivier]

Regina,

I've attach postgis.dll For libxml2 dll i reach trac max size file limit, so i put them there: <​http://oslandia.com/ticket_273/>

Namespace in only defined for libxml2 if defined with an URI, so what about this test:

SELECT 'ns_1', ST_AsEWKT(ST_GeomFromGML('<gml:Point xmlns:gml="http://www.opengis.net/gml"><gml:coordinates>1,2</gml:coordinates></gml:Point>'));

[robe]

Olivier,

Okay your postgis.dll works. I see one major difference now. You have the libxml statically compiled into the postgis.dll so your file is 4.9mb (you have proj statically compiled too bTW) while mine is under a megabyte. I think the stories I was seeing about crashing were with dynamically linked like what I was doing.

1) How do you create a statically linked version -- I thought I tried but maybe I didn't -- can you give me your compile statement for libxml2 and postgis.

2) From a licensing standpoint -- is there an issue with statically compiling in the libxml. It does create one less dependency -- though a heftier postgis.dll. Probably adds another 1 megabyte to the postgis.dll file which its small anyway.

[colivier]

Regina,

1) Libxml2:

./configure --prefix=/c/postgres
# make
# make install

PostGIS:

# ./configure \
      --prefix=/c/postgres \
      --with-pgconfig=/c/postgres/bin/pg_config \
      --with-geosconfig=/c/postgres/bin/geos-config \
      --with-projdir=/c/postgres
# export PATH=/c/postgres/bin:$PATH
# make clean
# make
# make install

2) Libxml2 is released under MIT license, so not a problem to link/use it the way you want.

[mcayland]

Regina, have you checked your entire hard disk to make sure you don't have any other libxml DLLs in any of your system paths? Also where are you storing the final DLL - in WINDOWS/SYSTEM or in the PostgreSQL bin/ directory?

[robe]

Mark,

Yap I did and had deleted all of them (except the one provided by EDB) (that fixed my inability to statically link). But still doesn't work when dynamically linking. I ended up just statically linking and that works fine. Latest experimental builds have it statically linked in.

I figure its safer anyway since PostgreSQL at least the windows version uses libxml2 also though they name it differently so if you are okay with the static solution feel free to close this out.

[mcayland]

I think I'd feel a lot better finding out *why* the dynamic link fails before consigning ourselves to large DLLs (I suspect there is a per-connection startup cost when loading DLLs into the backend).

I notice your backtrace is incomplete because you don't have debugging enabled in your running PostgreSQL. For full debug, you need to compile PostgreSQL with "CFLAGS=-O0 ./configure --enable-debug", rebuild PostGIS against the new PGXS Makefile generated from this installation and then get the backtrace again. You should be able to see the values of all the variables on the line in question to see why it's crashing.

HTH,

Mark.

[robe]

I would be interested too out of plain curiosity and jsut to make sure there isn't some other ogre in the code. I question if its better than staically linked though and suspect it may be worse. Doesn't the postgis.dll depend on libxml2-2.dll anyway in which case it would have to load both and possibly more costly.

Is the cost based on the size of the dll or is the cost the same regardless of size? In which case you are paying doubly -- one to load each dll in memory as opposed to one dll.

I mean if I have a dynamically linked libxml2-2.dll -- postgis.dll doesn't even load if the dll is not present in the PostgreSQL/bin folder as I recall. Will have to double-check that.

[mcayland]

Replying to robe:

I would be interested too out of plain curiosity and jsut to make sure there isn't some other ogre in the code. I question if its better than staically linked though and suspect it may be worse. Doesn't the postgis.dll depend on libxml2-2.dll anyway in which case it would have to load both and possibly more costly.

Yes, it would be good to have an idea of exactly what the issue is before we resolve it.

Is the cost based on the size of the dll or is the cost the same regardless of size? In which case you are paying doubly -- one to load each dll in memory as opposed to one dll.

AIUI a shared library is loaded once into memory, but any references to the functions by another DLL are then "fixed up" at load time. So thinking about it now perhaps it's more a memory usage issue rather than a startup time issue?

I mean if I have a dynamically linked libxml2-2.dll -- postgis.dll doesn't even load if the dll is not present in the PostgreSQL/bin folder as I recall. Will have to double-check that.

IIRC Windows searches the current directory first for a DLL, followed by all of the locations in PATH before it fails.

Any luck on getting a full debug stack trace?

ATB,

Mark.

[robe]

Mark, Does this work for you? This is backtrace against a PostgreSQL 8.4.0 mingw compiled against r4962 trunk.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4324.0x1464]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x68f286fd in parse_gml_coordinates (xnode=0x41628e0, hasz=0x140f3df "")
    at lwgeom_in_gml.c:623
#2  0x68f28f2e in parse_gml_data (xnode=0x41628e0, hasz=0x140f3df "", 
    root_srid=0x140f3d8) at lwgeom_in_gml.c:871
#3  0x68f291dd in parse_gml_point (xnode=0x4162740, hasz=0x140f3df "", 
    root_srid=0x140f3d8) at lwgeom_in_gml.c:934
#4  0x68f2ac5e in parse_gml (xnode=0x4162740, hasz=0x140f3df "", 
    root_srid=0x140f3d8) at lwgeom_in_gml.c:1544
#5  0x68f2778d in geom_from_gml (fcinfo=0x140f4a0) at lwgeom_in_gml.c:108
#6  0x0052df66 in ExecMakeFunctionResult (fcache=0x416dcc0, 
    econtext=0x416e108, isNull=0x140f737 "", isDone=0x0) at execQual.c:1685
#7  0x0052e91c in ExecEvalFunc (fcache=0x416dcc0, econtext=0x416e108, 
    isNull=0x140f737 "", isDone=0x0) at execQual.c:2116
#8  0x005320f4 in ExecEvalExprSwitchContext (expression=0x416dcc0, 
    econtext=0x416e108, isNull=0x140f737 "", isDone=0x0) at execQual.c:4095
#9  0x005afae2 in evaluate_expr (expr=0x416beb0, result_type=32796, 
    result_typmod=-1) at clauses.c:3842
#10 0x005af194 in evaluate_function (funcid=33359, result_type=32796, 
    result_typmod=-1, args=0x416be98, func_tuple=0x41364c0, context=0x140f9d0)
    at clauses.c:3449
#11 0x005aecf6 in simplify_function (funcid=33359, result_type=32796, 
    result_typmod=-1, args=0x140f830, allow_inline=1 '\001', 
    context=0x140f9d0) at clauses.c:3253
#12 0x005ad382 in eval_const_expressions_mutator (node=0x416bd70, 
    context=0x140f9d0) at clauses.c:2134
#13 0x0055ce3b in expression_tree_mutator (node=0x416bd98, 
    mutator=0x5ad1b5 <eval_const_expressions_mutator>, context=0x140f9d0)
    at nodeFuncs.c:1898
#14 0x005ae8b7 in eval_const_expressions_mutator (node=0x416bd98, 
    context=0x140f9d0) at clauses.c:2951
#15 0x0055cf5a in expression_tree_mutator (node=0x415b6e8, 
    mutator=0x5ad1b5 <eval_const_expressions_mutator>, context=0x140f9d0)
    at nodeFuncs.c:1944
#16 0x005ae8b7 in eval_const_expressions_mutator (node=0x415b6e8, 
    context=0x140f9d0) at clauses.c:2951
#17 0x005ad174 in eval_const_expressions (root=0x415c798, node=0x415b6e8)
    at clauses.c:2027
#18 0x0059d2c3 in preprocess_expression (root=0x415c798, expr=0x415b6e8, 
    kind=1) at planner.c:540
#19 0x0059cf89 in subquery_planner (glob=0x415b700, parse=0x415b610, 
    parent_root=0x0, hasRecursion=0 '\000', tuple_fraction=0, 
    subroot=0x140faac) at planner.c:375
#20 0x0059cb93 in standard_planner (parse=0x415b610, cursorOptions=0, 
    boundParams=0x0) at planner.c:190
#21 0x0059ca60 in planner (parse=0x415b610, cursorOptions=0, boundParams=0x0)
    at planner.c:122
#22 0x005fa88a in pg_plan_query (querytree=0x415b610, cursorOptions=0, 
    boundParams=0x0) at postgres.c:697
#23 0x005fa932 in pg_plan_queries (querytrees=0x416be20, cursorOptions=0, 
    boundParams=0x0) at postgres.c:756
#24 0x005fabca in exec_simple_query (
    query_string=0x415b180 "\nSELECT ST_GeomFromGML('<gml:Point><gml:coordinates                                             >1,2</gml:coordinates></gml:Point>')") at postgres.c:920
#25 0x005feb28 in PostgresMain (argc=4, argv=0x4085458, 
    username=0x234280 "postgres") at postgres.c:3614
#26 0x005c9d10 in BackendRun (port=0x140fdd0) at postmaster.c:3393
#27 0x005ca74c in SubPostmasterMain (argc=3, argv=0x232cc0)
    at postmaster.c:3866
#28 0x0055934f in main (argc=3, argv=0x232cc0) at main.c:165
(gdb) 

[mcayland]

Right - that's much better as it's fairly obviously failing in xmlFree(). This looks to me as if it's the same problem as this: http://trac.osgeo.org/postgis/changeset/3463.

Windows won't allow you to malloc/free memory across different DLL boundaries; so it looks to me as if either the GML code is allocating memory with lwalloc() which it is then attempting to free with xmlFree(), or the other way around.

Olivier, any thoughts on this?

[colivier]

Mark,

Ok that's a good point, I've read back on each *Free in the code and i did't find any mix between lwalloc and xmlFree.

But i've found that xmlNsPtr Structures should be free with xmlFreeNsList instead of xmlFree (but i must investigate further this point).

[pramsey]

Remove particular case of xmlFree

[pramsey]

You'll be pleased (?) to know that I can duplicate this in my MinGW build too. I tried removing the free at lwgeom_in_gml.c:623 (see the attached patch) but it still crashes. I don't have a debug version built yet, so I have no meaningful stack trace. I'm going to rebuild, but it'll take pretty much all day, due to slowness of MinGW + VM.

[colivier]

Yeap i'm pleased ;)

And now two questions:

1) Could you try with removing lwfree from is_gml_namespace function (about line 170)

2) Did you have to do something special under MinGW to have a dynamic library flavour ?

[pramsey]

I'll do (1) when I get home. On (2) it just popped out that way, following the Windows Build instructions on the Wiki.

[robe]

Wow so I managed to get both of you on the windows bandwagon. This is certainly more than what I could have hoped for.

FWIW -- this is the way I toggle back and forth between static compile and link. Well seems to work for me anyway but all this stuff is still cryptic to me.

My make check wa actually passing last time I tried except I think for one small error.

cd /c/projects/libxml/libxml2-2.7.6 
make uninstall
make clean

#to create linked
./configure --prefix=/c/projects/libxml/libxml2-2.7.6release --enable-shared --disable-static

# to create static
./configure --prefix=/c/projects/libxml/libxml2-2.7.6release --disable-shared CCFLAGS=LDFLAGS="-Wl,-static" CFLAGS=-O2

make && make install && make check

I haven't put it up yet since I assume we will want link dll which as Paul said is what happened when I follow just standard build. Though I fear this problem is more serious than just the way we are freeing memory in windows. I'll have to dig up the reports I have read about it - but as I recall seemed to be a common issue with libxml in windows (though those reports may be dated).

[pramsey]

How do you get your stack traces in Windows, Regina? For reasons passing understanding, postgres --single won't run for me (says I have admin privs) while running postgres in shared mode works fine, with the same user. On UNIX I generally run postgres in --single mode and then pass in the crashing SQL.

[mcayland]

Have you tried the instructions I typed up on the wiki?

http://trac.osgeo.org/postgis/wiki/DevWikiGettingABackTrace

[pramsey]

Good instructions. I ended up just reducing the priv on my account and running in --single. My trace is no more informative than yours.

colivier I see no lwfree in is_gml_namespace.

[colivier]

Paul,

You're right there'isnt any, here a diff:

Index: lwgeom_in_gml.c
===================================================================
--- lwgeom_in_gml.c	(revision 4995)
+++ lwgeom_in_gml.c	(working copy)
@@ -161,13 +161,11 @@
 			if (	(*p)->prefix == NULL ||
 				!xmlStrcmp(xnode->ns->prefix, (*p)->prefix)) {
 
-				xmlFree(ns);
 				return true;
 			}
 		}
 	}
 
-	xmlFree(ns);
 	return false;
 }

[pramsey]

No change, colivier. I don't think it's your code, I think it's libxml2+mingw+dll.

[robe]

Paul,

Good instructions. I ended up just reducing the priv on my account and running in --> single. My trace is no more informative than yours.

Your trace is not any more informative than mine? or Olivier's

The way I do it -- I compiled my PostgreSQL under MingW with debug mode as Mark said (I updated Mark's instructions in a Tip section for that).

Then what I do after that of course after init Dbing my MingW PostgreSQL install.

I have my MingW install running under Port 8434 and then I manually start it from windows dos shell with this command

"C:\projects\pg\pg84\bin\pg_ctl" start -D "C:\projects\pg\pg84\data" -U postgres

Then I connect to it using pgAdmin III, run my query -- do contd. bt dance -- as per Mark's instructions .

But I'm running on Windows XP. Haven't tried under Vista or my Windows 7 yet - don't have those boxes set up.

I have yet to compile PostgreSQL under VS -- have it almost compiling -- still have to drag in some dependencies. Then I should be able to do a more detailed debug under that too and maybe fix my damn R so PL/R will work under my regular windows installs.

[pramsey]

Under VCC perhaps we could use the pre-compiiled libxml2 binaries? Incidentally, I switched to libxml2 2.6.32 and things "worked" but I think that's because I ended up with a static compile instead of a dynamic one? How did you tell?

(Update, maybe not, depends.exe reports my postgis dll still depends on libxml2-2.dll.)

[robe]

You can tell two ways. You can check with depends.exe or look at the size of the postgis-1.5.dll. If its static it will be much fatter than your original since it will have the libxml embedded in it.

The libxml added about another 1 mb to the .dll file. though we can probably reduce that by disabling stuff we don't need.

[robe]

Wait so libxml 2.6 works dynamically? Hmm I had trouble compiling that I think. How did you compile the 2.6 -- regular ./configure? I'll have to give that another try.

[pramsey]

Regular configure line, just set the prefix.

[robe]

Paul,

I tried and succeeded, and it doesn't crash, but I think its all a lie. True depends claims postgis..dll depends on libxml-2-2.dll, but I think its lying or the software is lying to it.

For two reasons 1) This new postgis dll is twice the size of the dynamic one I built 2) I deleted the friend it claims it needs from my PostgreSQL/bin (that being libxml-2-2 whatever

3) Ran the select postgis_libxml_version() -- which happily said "2.6.32" 4) restarted postgresql service

so where or where is it finding its playmate?

I hate it when machines lie or start telling half-truths. I thought machines are supposed to love you unconditionally :)

[pramsey]

I think for now we change the wiki page to specify libxml 2.6 and move on.

[robe]

Why 2.6. As I said I think 2.6 is really statically compiled so 2.6 or above works fine if we are statically compiling anyway.

[robe]

I think this problem is resolved, but I'm trying to retrace my steps to figure out the culprit. On my test box I can build PostGIS 2.0.0 and PostGIS 1.5.2 with dynamically linking to libxml 2.7.6. When I do that the resulting postgis-.dll is much smaller and clearly has a libxml-2-2.dll dependency, but doesn't crash with the above examples.

On the box we usually use to build on, dynamically linking still results in a crashing postgis-..dll with the above examples. I thought maybe it was the libxml-2-2.dll, but swapping out with the one built on our production still works.

I'm suspecting its upgrading the auto conf or lib tool that did the trick but haven't verified yet. On my test box I'm running a newer version (of at least libtool)

[robe]

Hasn't been an issue lately so closing this out.