cunit is crashing on test_ShpDumerDestroy()

[robe]

This is testing the GUI loader on Windows. Might have something to do with Mark's recent change.

Suite: GUI Shapefile Loader File List Test
  Test: test_append_file() ... passed
  Test: test_find_file() ... passed
  Test: test_traversal() ... passed
  Test: test_remove_first() ... passed
  Test: test_remove_last() ... passed
  Test: test_remove_middle() ... passed
  Test: test_find_index() ... passed
Suite: Shapefile Loader File pgsql2shp Test
  Test: test_ShpDumperCreate() ... passed
  Test: test_ShpDumperDestroy() ... make[2]: *** [check] Error 5

[mcayland]

I was unable to reproduce the crash locally, but I noticed that the config initialiser wasn't being called which would have left some pointers intialised with random data. Hence a call to ShpDumperDestroy() would try to free random pointer values which could cause a crash.

Could you try a checkout ≥ r7533 and let me know if that fixes the issue? Incidentally we should probably fix the regression tests so that "make check" runs even if —with-gui is not specified during configure.

[pramsey]

No problems on OSX either, but yes, I was going to say: 95% of these in the past have turned out to be unintitialized pointers in the state structures.

[robe]

It's still a problem for me. It doesn't crash on my 9.1beta2 windows build,

but does on my 9.0.2 and 8.4.4 windows builds.

It wasn't crashing before you made your changes Mark. I'm running r7544.

I guess I can try to upgrade to the latest release of both PGs and see if the problem goes away.

[mcayland]

Hmmm that doesn't make much sense at all You don't need to upgrade PostgreSQL as liblwgeom is being used as a standalone library. A couple of things to try:

1) Did you try a complete "make clean" and "make" when you did an "svn up"?

2) Can you get a gdb backtrace from the process as it crashes? Something like:

make clean ./configure —with-gui make cd loader make check cd cunit gdb cu_tester

Then from within gdb:

run (crash) bt

[robe]

Well I upgraded and it didn't help. So you are right.

Does it make a difference that I compile with mingw build but I test with VC++ build and I'm on Windows 7. This vaguely reminds me of that issue we had way back when that could only be exhibited in the pgsql2shp or was it shp2pgsql on Windows 7. Didn't even show on Windows XP. I'm sure those aren't related but it reminded me of it.

Yap my automated script does all that sh autogen.sh make clean stuff. I svn up all the time.

Okay will try that. Weird it doesn't happen on my pg9.1 beta 2. I thought it was maybe the order of my building leaving junk behind but consistently fails on 8.4, 9.0 and passes on 9.1beta2

[robe]

I'll give the dbg thing a try next.

[robe]

MArk,

This is what run (crash) bt

gives:

Program received signal SIGSEGV, Segmentation fault.
0x6310224a in closePGconn () from c:\projects\pg\pg90\bin\libpq.dll

That's actually mingw libpq.dll though so maybe it wouldn't be an issue if I switched path to my vc++ one. Though admittedly like I said it worked before you last set of changes.

[mcayland]

Great - thanks for this. I think I've got it now - how does r7546 look?

[robe]

Mark, Better but still crashes. When I run in

run (crash) bt mode — it passes with flying colors. What do you make of that?

(gdb) run (crash) bt
Starting program: c:\projects\PostGIS\trunk\loader\cunit/cu_tester.exe (crash) bt
[New Thread 3372.0x1160]


     CUnit - A Unit testing framework for C - Version 2.1-0
     http://cunit.sourceforge.net/


Suite: GUI Shapefile Loader File List Test
  Test: test_append_file() ... passed
  Test: test_find_file() ... passed
  Test: test_traversal() ... passed
  Test: test_remove_first() ... passed
  Test: test_remove_last() ... passed
  Test: test_remove_middle() ... passed
  Test: test_find_index() ... passed
Suite: Shapefile Loader File pgsql2shp Test
  Test: test_ShpDumperCreate() ... passed
  Test: test_ShpDumperDestroy() ... passed

--Run Summary: Type      Total     Ran  Passed  Failed
               suites        2       2     n/a       0
               tests         9       9       9       0
               asserts     124     124     124       0

Program exited normally.
(gdb) 

[mcayland]

Hmmm there is obviously a bit of a theme here - I can see several internal state variables that could also potentially cause a crash in a similar way. How does r7547 look?

[robe]

yap that seemed to hit the spot.