[BLOCKING] /root/repo/xgboost/src/objective/regression_obj.cu:65: Check failed: preds.Size() == info.labels_.Size() (904 vs. 3616) labels are not correctly providedpreds.size=904, label.size=3616

[pseudotensor]

1dac5e2 on fresh build off dmlc

failxgbregression.zip

@hcho3 seems to be major regression after recent fixes. Seems all regression problems have the issue.

[pseudotensor]

I get this on all or most (not sure) regression problems

[hcho3]

Can you try running the same thing with 0ff84d9 ? #4147 might have introduced the bug.

[trivialfis]

@pseudotensor It might be my fault on #4147 . But I ran your script fine:

...
[535]	validation_0-rmse:0.14538
[536]	validation_0-rmse:0.145462
[537]	validation_0-rmse:0.145495
[538]	validation_0-rmse:0.145489
[539]	validation_0-rmse:0.145514
[540]	validation_0-rmse:0.145533
[541]	validation_0-rmse:0.145551
[542]	validation_0-rmse:0.145574
[543]	validation_0-rmse:0.145422
[544]	validation_0-rmse:0.145423
[545]	validation_0-rmse:0.145428
Stopping. Best iteration:
[445]	validation_0-rmse:0.145298

[trivialfis]

@hcho3 If confirmed that PR is to blame, I will summit a PR to revert and reopen the closed bug since I can't reproduce.

[pseudotensor]

Ok, I will check different hash

[hcho3]

@pseudotensor @trivialfis I actually reproduced the bug on my Linux machine with the latest master. On the other hand, with commit hash 0ff84d9, the example runs fine.

[hcho3]

Let's see if there is a quick fix for this

[hcho3]

Okay, found the issue: somehow the variable num in

xgboost/src/data/data.cc

Lines 140 to 141 in c8c472f

	void MetaInfo::SetInfo(
	const char* key, const void* dptr, DataType dtype, size_t stride, size_t num) {

is not correct. The num should have been 904 in the given example but now is being set to 3616.

[trivialfis]

@hcho3 Thanks! Seems my master branch is one commit behind. Sorry about that. Looking into this.

[hcho3]

@trivialfis I actually have a one-liner fix. Trying to fix the test test_np_view now

[trivialfis]

@hcho3 Yap. the length from Python call should be divided by data.dtype.itemsize:

xgboost/python-package/xgboost/core.py

Line 225 in c8c472f

length = len(data.base)

[hcho3]

@trivialfis It turns out that len(data.base) may mean different things. Sometimes it shows the number of bytes, and sometimes it shows the number of elements. Rather than dealing with NumPy internals, I'd prefer to simply make copies.

[trivialfis]

@hcho3 Okay, I will revert it tomorrow. Really need some sleep now. It's 6AM at my place...

[hcho3]

@trivialfis I'll take care of it. Good night

[hcho3]

@pseudotensor Fix is available at #4165. Thanks for reporting the bug.

[pseudotensor]

Thanks!