# tor Nov 12 13:51:11.139 [notice] Tor v0.2.0.31 (r16744). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux sparc64) Nov 12 13:51:11.143 [notice] Initialized libevent version 1.4.4-stable using method epoll. Good. Nov 12 13:51:11.144 [notice] Opening Socks listener on 127.0.0.1:9050 Bus error # same happenes for 0.2.0.30-r1. unsetting cflags, cxxflags, makeopts and ldflags doesnt help. is anyone successfully running tor on gentoo/sparc64?
Created attachment 171531 [details] emerge --info
Created attachment 171532 [details] backtrace
upstream bug @ http://bugs.noreply.org/flyspray/index.php?do=details&id=862
upstream just fixed the issue in r17262. i wonder why tor is marked stable for sparc..?
(In reply to comment #4) > upstream just fixed the issue in r17262. > i wonder why tor is marked stable for sparc..? As I don't have access to sparc hardware, I would like to ask the sparc team to fix this issue. Thanks.
It's marked stable because it passed its tests and appears to work for me. Sparc can't fix it, nor would we if as indicated upstream already has done so, although we can revert to ~sparc if you wish. Now, Comment #4 suggests that there is a problem someplace that I don't trigger (a bus error would be use of an unaligned data item on sparc). Comment #4 also says that release r17262 for tor fixes this problem. So it seems to me that the fix is to put that version into the tree, no?
(In reply to comment #6) > It's marked stable because it passed its tests and appears to work for me. > Sparc can't fix it, nor would we if as indicated upstream already has done so, > although we can revert to ~sparc if you wish. Now, Comment #4 suggests that > there is a problem someplace that I don't trigger (a bus error would be use of > an unaligned data item on sparc). Comment #4 also says that release r17262 for > tor fixes this problem. So it seems to me that the fix is to put that version > into the tree, no? That's a version control revision of the Subversion repository of Tor upstream. I know why Sparc marked it stable...I did it long enough myself for x86. :) Anyway, the commit needed is http://cvs.seul.org/viewcvs/viewcvs.cgi?rev=17262&root=Tor&view=rev, so please prepare a patch against 0.2.31 sources, test it and commit -r2 with stable keywords for sparc. Maybe tomorrow I can prepare that patches myself and commit a version which you will then test and keyword.
I can generate the patch and apply it, but the patch is against a somewhat newer version of tor, apparently (line numbers are a bit different). More seriously, the patch uses functions or macros get_uint8 and set_uint8 for some memory references, but those give: ============= buffers.c: In function ‘fetch_var_cell_from_buf’: buffers.c:961: warning: implicit declaration of function ‘get_uint8’ ============== for example, and later bomb with undefined externals. The fix looks right, but I don't see offhand where those are defined. I'll poke around a bit tomorrow; I'm done with it for today.
Created attachment 171671 [details, diff] Patch file to apply the sparc memory alignment patch (missing defs for the _uint8 functions). This patch applies the fix from upstream to try to avoid unaligned data references on sparc.
Created attachment 171682 [details, diff] Proposed patch to correct the memory alignment problem reported here. This patch applies the upstream fix and also defines the set_uint8, get_uint8 functions analogously to the [get,set]_uint[8,16] functions. I have added it to the cvs tree and have also added a vevision bump to net-misc/tor-0.2.0.31-r1 which does apply the patch and then builds tor successfully. This version of tor still passes all its tests and works for me, but then so did the previous version. I have not marked it stable on sparc; there's no point doing that until we know how it works for the reporter Robert Annessi <robert@annessi.at>. Also, this is an unconditional change in tor, so other architectures will need to retest. Perhaps we should apply the patch with use sparc && epatch ... but that assumes that sparc is the only architecture with potential alignment problems, and I don't know that such is the case. This code should be safe on anything. (I know you asked for an -r2, but that would be for -0.2.0.30. :) )
Comment on attachment 171671 [details, diff] Patch file to apply the sparc memory alignment patch (missing defs for the _uint8 functions). Make it obsolete for real. I thought I did that.
More administrative clean up. I did a lot of things I hadn't intended, I see.
(In reply to comment #10) > Created an attachment (id=171682) [edit] > Proposed patch to correct the memory alignment problem reported here. works for me.
Thanks, I'll mark it stable for sparc then. I'll make one further remark. I have no idea why upstream uses set_uint8 and get_uint8, nor do I know if they intend them as functions or as macros. After all, one way or another, uint8 is just (unsigned char), and there are no alignment problems with that. I used them in order to keep upstream's patch intact, but the original error was triggered by uint16 (the original tor code for that was indeed poor coding practice), but I don't think the uint8 changes are needed. I'll look at is as time permits, but for now, 0.2.0.31-r1 is stable for sparc (and 0.2.0.31 is ~sparc). I'm marking this as fixed based on Robert's report (and indeed this should fix the problem he reported), but I doubt that it's what upstream will ultimately release.
(In reply to comment #14) > I'm marking this as fixed based on Robert's report (and indeed this should fix > the problem he reported), but I doubt that it's what upstream will ultimately > release. Thanks...I will track upstream as usual.
