Regress tests fail under windows 32-bit install when returning status

[robe2]

Now that we have regress tests, they work great under 64-bit, not so much under 32-bit.

This is testing with 1.2.2

At a glance all the tests fail because of the status output
In all the tests, the status output should be 200, but instead I get random numbers returned back

  SELECT status
  FROM http_get('http://httpbin.org/status/202');

yields:

status   

! -----------
! 232402072

I get a different number each time I run it.

[robe2]

Has something to do with this line I think.

values[RESP_STATUS] = Int64GetDatum(status);

because if I change to

values[RESP_STATUS] = status;

The status comes thru correctly, but then it crashes later in the regression tests, so the isn't the right change, but perhaps something other than Int64GetDatum(status) is called for.

[pramsey]

Maybe cf664b8 helps

[robe2]

Well it fixes the status issue like my above, but also crashes in the later tests like my above change.

I went back to test your interrupt to make sure the crashing wasn't there before and crashing looks to be new with change.

[robe2]

Okay what's particularly annoying is if I manually run each test in the instance, it doesn't crash, but for some reason running all the tests in a batch makes it crash. Perhaps something is being cleaned up after each individual test (if run separately), that doesn't as part of a batch.

[robe2]

Wait maybe I was lucky before, can make it crash running this one 1-3 times in a row.

This is the one where I think it consistently crashes in the tests.

SELECT status,
content::json->'data' AS data,
content::json->'args' AS args,
content::json->'url' AS url,
content::json->'method' AS method
FROM http_put('http://httpbin.org/anything?foo=bar','payload','text/plain');

Returns right answer when it passes I think though.

[robe2]

Here is the backtrace of the crash

#0 0x7691aba6 in wcsnicmp () from C:\Windows\syswow64\msvcrt.dll
#1 0x6988179b in http_readback (buffer=0xdc5ed0d, size=1, nitems=16384,
instream=0x288e83c) at http.c:272
#2 0x7081de94 in libcurl-4!curl_mvfprintf ()
from C:\ming32gcc481\projects\gdal\rel-2.2.1w32gcc481\bin\libcurl-4.dll
#3 0x0dc5ed0d in ?? ()
#4 0x00000000 in ?? ()

Which seems to point to this line in the http_readback function

	memcpy(buffer, si->data + si->cursor, realsize);

[pramsey]

Thanks, that last little clue did it. I looked carefully at that function yesterday but failed to see it: I wasn't fulfilling the callback contract correctly, so it was doing terrible, terrible things reading out of bounds. c211356 should hopefully have fixed that.

[robe2]

yap that fixed it.