Current master crashes in wine

laanwj commented at 5:46 pm on January 7, 2014: member

Current master (cross compiled using gitian) crashes in wine. If this doesn’t happen on windows proper (unsure) this is a low priority issue.

First, after connecting to a few nodes, it gives a warning about the time Warning: Please check that your computer's date and time are correct! If your clock is wrong Bitcoin will not work properly., and then after at most a minute it crashes with a segmentation fault.

It looks like a crash in strftime with a NULL pointer, called some place within the networking code. I’ll need to compile with debugging information to find out more.

No information or messages explaining the crash end up in debug.log.

Diapolo commented at 6:59 am on January 8, 2014: none

I’ve not seen this on Windows recently.

wtogami commented at 9:46 am on January 8, 2014: contributor

https://litecointalk.org/index.php?topic=12526.0 It is unclear if it is related to what @laanwj is experiencing, but we found a network related issue with boost-1.54 on win32 builds. Litecoin’s 0.8.6.1 gitian win32 was upgraded from boost-1.50 to boost-1.54 to match Bitcoin master. Some (but not all) Windows users have an issue where networking just stops randomly after a few hours. getpeerinfo thinks it still has peers but netstat shows they are long gone. GUI still operates, networking just stops and debug.log shows things like this:

02013-12-28 12:40:46 socket send error 10054
12013-12-28 12:40:46 disconnecting node 125.86.21.116:1985

Downgrading back to boost-1.50 seems to fix the issue. I am attempting to narrow it down more.

I think merely upgrading Bitcoin 0.8.6 gitian win32 to boost-1.54 will have the same problem. It is entirely likely bitcoin master gitian win32 is similarly affected.

laanwj commented at 12:38 pm on January 8, 2014: member

Today I’ve been completely unable to reproduce this issue. That may have to do with my attempt at adding debug information; Heisenbug? will try a clean build and see if it brings back the issue.

Edit: yep, without debug information it’s back! :-(

Something all the crashing sessions have in common:

02014-01-08 12:48:30 Added time data, samples 4, offset -281217278672897 (-4686954644548 minutes)
12014-01-08 13:16:15 Added time data, samples 3, offset -281217278672795 (-4686954644546 minutes)
22014-01-08 13:48:31 Added time data, samples 2, offset -281217278672897 (-4686954644548 minutes)
32014-01-08 13:51:32 Added time data, samples 2, offset -281217278672896 (-4686954644548 minutes)

Either all the peers return crazy values, or GetTime returns an invalid value (this is subtracted). My bet is on the second.

Yep, GetTime returns junk (it thinks it’s in the far far future), peer is well-behaved:

02014-01-08 14:55:19 GetTime is 281218667865815, nTime is 1389192919

laanwj commented at 3:39 pm on January 8, 2014: member

Ok this is weird. time(NULL) returns (random?) data in the upper part of the uint64_t. If I add an explicit &0xffffffff in GetTime, it works.

sipa commented at 3:47 pm on January 8, 2014: member

Maybe time_t on windows natively returns a 32-bit integer, but it’s declared as returning a 64-bit one?

laanwj commented at 4:18 pm on January 8, 2014: member

That could be the case. The curious thing is that the upper word is always the same, so it is not random stack corruption being returned:

00000ffc4 52cd7958

sizeof(time_t) is 8 bytes on mingw. So it may indeed be a misdefinition somewhere (but not in bitcoin – it also happens with a minimal test).

laanwj commented at 4:23 pm on January 8, 2014: member

I’ve narrowed down the problem to:

0-D_FILE_OFFSET_BITS=64

This option changes the size of time_t from 4 to 8, and adds the random gunk on time(NULL).

Note: This may be a wine bug. I haven’t tested anything on an actual windows box.

Another thing that’s worth looking at may be why a (huge) time discrepancy causes a segmentation fault in the network code.

laanwj commented at 4:44 pm on January 8, 2014: member

Ok, this is confirmed a wine bug.

wine 1.4 (Ubuntu 12.04):

0281218667872263
1ffc452cd8007
2size=8

wine 1.4.1 (Ubuntu 13.10):

01389199241
152cd7f89
2size=8

Edit: also checked that the crash doesn’t happen when making GetTime() return outrageous times in general. That, too, is a wine issue probably with time_t size conflict.

laanwj closed this on Jan 8, 2014

theuni commented at 10:25 pm on January 8, 2014: member

This looks to be http://sourceforge.net/p/mingw-w64/bugs/279/ . It’s a toolchain issue that will manifest when building with D_FILE_OFFSET_BITS=64 (which is correct). This value should not affect time_t, but in the buggy versions it did.

sizeof(time_t) should be 4 for win32. If it’s 8, the headers are buggy and runtime will be unpredictable. At runtime, a 4byte value is stored in an 8byte var, leaving half uninit’d. Using a recent mingw it’s 4 as expected. I’m assuming gitian’s version still has this bug.

This should be reopened. It’s a build-time issue that may manifest at runtime.

laanwj reopened this on Jan 9, 2014

laanwj commented at 8:08 am on January 9, 2014: member

@theuni In that case we should define _USE_32BIT_TIME_T if mingw. This overrides the file offset bits…

laanwj commented at 8:29 am on January 9, 2014: member

See #3497

FYI the output with -D_FILE_OFFSET_BITS=64 -D_USE_32BIT_TIME_T (correct):

01389256547
152ce5f63
2size=4

laanwj commented at 8:58 am on January 9, 2014: member

Discussion continues in #3497

laanwj closed this on Jan 9, 2014

laanwj referenced this in commit eaafa23cbd on Jan 9, 2014

MathyV referenced this in commit 680d77cd75 on Aug 5, 2014

MarcoFalke locked this on Sep 8, 2021

Current master crashes in wine #3494