Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/212d4a02bb2700bbc18e26e0f9f80a5281053128 for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/f48c7eb63ae43c55e6c70450757b33fdce8c58f3 for binaries and test log.

This could happen for one of several reasons:

1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts (please tweak those patches in contrib/test-scripts)
2. It adds/modifies tests which test network rules (thanks for doing that), which conflicts with a patch applied at test time
3. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
4. The test suite fails on either Linux i386 or Win32
5. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)

If you believe this to be in error, please ping BlueMatt on freenode or TheBlueMatt here.

This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

@TheBlueMatt: The error on pulltester doesn't seems to be related to these changes, right?

I'm a bit wary of merging fixes that I don't understand, although it would be ok for 0.8.2.

Can you debug where it crashes when the premature returns are not done?

Candidates are:

clientModel->getLastBlockDate()
clientModel->getVerificationProgress()

If clientModel would not be set at all it would crash with a SIGSEGV so I don't think that could be it. For the rest the function only updates Qt controls, a very unlikely cause of crashes.

Yes, I'm trying to debug this further. But at least if 0.8.2 have to come out quick, this hotfix might be better than nothing...

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/af338a7890c3ab6a8530518c52c3b833af89c3d8 for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

Meh, it doesn't fix it. It just bypasses it in that special case...

Looks like in that environment it always crashes when it tries to show the progress bar...

Now it hangs when I launch it with reindex, and it does it too in 0.8.1...

Adding a -noprogressbar option would be overkill, right?

So are we facing a Qt bug here? What Qt version is your version of Bitcoin-Qt using?

I really doubt it's a Qt bug.
That kind of isolates it to clientModel->getVerificationProgress() (as this is new in 0.8.2)
Should be pretty easy to find out. Can you try commenting it out and replacing it with a fixed number and see if it still hangs?
Edit: and yes, a -noprogressbar option is out if the question :)

@laanwj What is that magic number here telling?
progressBar->setMaximum(1000000000);

@rdponticelli Did you try yet what laanwj suggested above?

Replacing clientModel->getVerificationProgress() by a constant it works.

Might be the problem that on this setup the only block available is the genesis block?

@Diapolo just an arbitrary number AFAIK

@rdponticelli Good, that at least isolates the issue. So that function has a bug that makes it crash with only the genesis block. At least on your setup. I have not noticed this myself, when starting with an empty data directory. I'm unable to reproduce it.

@laanwj and/or @Diapolo: Is it intended and correct that BitcoinGUI::setNumBlocks is called twice at startup?