< Chris_Stewart_5>
Anyone familiar with this error? crypto/common.h:48:12: runtime error: load of misaligned address 0x7fc1ea516169 for type 'uint32_t'
< Chris_Stewart_5>
Out of memory error possibly?
< gwillen>
hmmm, that doesn't sound good
< Chris_Stewart_5>
gwillen: Seems strange, all tests are passing that I am running but this seems to be happening in the setup/tear down process
< gwillen>
what is it that you're working on that's erroring -- bitcoin-core? Or a private branch thereof?
< gwillen>
that pointer makes me nervous, the last 3 bytes are alphabetic characters in ascii, and a pointer should never be odd
< gwillen>
which can mean the pointer has been partly overwritten with garbage
< Chris_Stewart_5>
it is branch on my repo, I can link if you want.
< Chris_Stewart_5>
the gist of it is generating random permutations of datastructures and testing invariants hold true on it
< gwillen>
feel free to link, although I suspect the problem is that you've introduced a bug somewhere in the form of overwriting memory erroneously
< gwillen>
well, if the problem is a pointer being overwritten, or a use-after-free or something, the real cause of the error could be anywhere prior
< gwillen>
this is the great sadness of debugging C code
< gwillen>
what would be most useful in finding it, I think, would be finding what commit first introduced the problem
< Chris_Stewart_5>
Yes, it is definitely introduced on this commit, the last commit i have on 8469 has everything working (on my machine). This pull request introduces a new dependency that we haven't set up yet :-(
< gwillen>
Chris_Stewart_5: sorry, which commit introduces it? If it's on github, can you link directly to the specific commit? Or if it's not yet, can you push it somewhere I can see it?
< gmaxwell>
Chris_Stewart_5: your error sounds clear enough, "load of misaligned address" though I don't seeh how that makes sense with the code at common.h:48 on my system.
< gmaxwell>
okay thats not mine and that code looks potentially problmatic.
< gmaxwell>
In C, type punning between arbritary types is not permitted. E.g. you cannot take a random character pointer, cast it to an int, and access it. On most CPU architectures which have been invented (x86 and the more recent versions of ARM being the big obvious exceptions) it is forbidden to make a load which isn't naturally aligned, e.g. a load of a 4 byte type has to begin at a 4 byte multiple.
< gmaxwell>
C(++) has special rules that you're allowed to access anything through a character pointer... and so you can use things like memcpy to make unaligned accesses by copying the randomly aligned pointer to a pointer of the right type (thus right alignment) elsewhere (e.g. on the stack.)
< gmaxwell>
_My_ common.h here uses a memcpy, which would have been done specifically to avoid this problem. Are you using an old version of the code? IIRC we fixed some issues with this not so long ago.
< Chris_Stewart_5>
gmaxwell: Yes, I haven't rebased #8469 since I opened it IIRC
< gmaxwell>
(Since I mentioned x86 above, even on x86 there are some instructions e.g. many of the fast SIMD loads, that require natural alignment... so you can't even just assume that since you're on x86 everything is going to be okay).
< gwillen>
heh, I guess I was too quick to assume an unaligned load meant the pointer was the problem
< Chris_Stewart_5>
really? You can't cast a char -> int and still access that piece of memory? Doesn't that make weak typing irrelevant then?
< gmaxwell>
(And on older ARM systems, the CPU actually used the least significant bits of the pointer to trigger hardware byteswapping... so if you tried to read 32-bits from address 1, you'd really get a read of address 0 with the bytes swapped.. which was super duper fun to troubleshoot-- especially with all the x86 linux jockies writing alignment unsafe code, which is probably why arm dropped that rathe
< gmaxwell>
r cool feature. :P)
< gmaxwell>
Chris_Stewart_5: It's undefined behavior if the resulting pointer is not correctly aligned for its type.
< sipa>
gmaxwell: not just alignment
< sipa>
in C++ you just can't access any type through a type pointer that isn't compatible with it
< sipa>
Chris_Stewart_5: you can cast an int to a char and back to int
< gmaxwell>
sipa: I thought it was unconditionally, but googling didn't give me a cite so I said the more limited thing. :P
< gmaxwell>
I also didn't mention, but even on x86 unaligned loads are sometimes non-trivially slower. (the main factor being if the load straddles a cache-line or page boundary, which is never the case for an aligned load)
< sipa>
Chris_Stewart_5: and you can take a pointer to int, cast it to pointer to char, and access the data through the char pointer
< sipa>
Chris_Stewart_5: which is a special exception that only exists for char
< sipa>
but you can't create a char array, and then cast it to int pointer and then access it through the int pointer
< gmaxwell>
so even if you were willing to ignore the C(++) standards and hope the compiler didn't screw you, and even if you were willing to only work on x86, and even if you were sure the result wouldn't use any alignment requiring vector loads... the result would still end up being potentially slower code. :P
< Chris_Stewart_5>
So many little intracies in c/c++. Those casting semantics seem a little strange to me but I guess it is just the way it is :/
< gmaxwell>
Funny, I like C because there are relatively few things to know!
< sipa>
Chris_Stewart_5: it's not strange at all... you shouldn't see the program memory as an array of bytes, which you can arbitrarily treat as objects as you like
< sipa>
Chris_Stewart_5: instead, the memory contains *objects* which have a well-defined type, and you're only allowed to access those objects through compatible pointers
< Chris_Stewart_5>
gmaxwell: I think it boils down to 'X is easier because I learned X first! Y is waaaaay harder because I have to change the way I think' :-)
< gmaxwell>
some of these things were more obvious in the past, objects of different kinds might get allocated out of entirely seperate chunks of memory which weren't even connected to the same hardware.
< sipa>
note that many C/C++ codebases (and even bitcoin core before 0.14) violate that rule usually
< sipa>
Chris_Stewart_5: these rules for example allow the C++ compiler to assume that two pointers of different type never refer to the same object, so a write through one can be known to never invalidate perhaps loaded-in-registers information from the other object
< gmaxwell>
Chris_Stewart_5: dunno about that, the C language specification (at least for ansi C), which is more exact than even exists for most other language is very small (I think about 250 pages) compared to that of other language where their behavior is at all reproducable. (e.g. I think common lisp's spec is about 2000 pages).
< gmaxwell>
same can't be said for C++ however.
< Chris_Stewart_5>
gmaxwell: hah, good point. Seems like every new language has turing complete type systems these days
< gmaxwell>
well it turns out that it's difficult to produce any complex non-linear system that isn't-- with some gryrantions and squinting-- turing complete. C macros are turing complete if you're willing to loop the preprocessor. :) (doubly so because physical computers are not, pedantically, turing complete themselves due to having finite memory/storage.. and many non-turning complete langauges are equi
< gmaxwell>
vilent to a turing machine with bounded-space/time...)
< Chris_Stewart_5>
sipa: I didn't realize that property is preserved. I always get caught up on the whole int and char casting stuff and makes me wondering if there are *more* special cases I don't know about.
< Chris_Stewart_5>
Any way, I suppose my misunderstanding of C/C++ are a little off topic for this channel, rebasing onto master now.
< Chris_Stewart_5>
Hopefully the new defintion fixes my problem
< Chris_Stewart_5>
What is the process for getting a bigger pull request like this merged in any way? Seems like most think it is a good idea, but we need to get some sort of managed dependency set up for rapidcheck
< Chris_Stewart_5>
It is finding stuff, which is encouraging
< Chris_Stewart_5>
Seems like it would be a good idea to encourage this kind of testing for down stream projects such as elements too..
< nemgun>
hello
< bitcoin-git>
[bitcoin] laanwj opened pull request #9979: p2p: Bare minimum to support UNIX sockets (master...2017_03_unix_socket_p2p) https://github.com/bitcoin/bitcoin/pull/9979