Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 246483 - net-misc/tor-0.2.0.31 produces sigbus after a few seconds on sparc64
Summary: net-misc/tor-0.2.0.31 produces sigbus after a few seconds on sparc64
Status: VERIFIED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: Sparc64 Linux
: High normal (vote)
Assignee: Gustavo Felisberto (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-12 13:22 UTC by Robert A.
Modified: 2008-11-15 17:52 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge.info,2.87 KB, text/plain)
2008-11-12 13:23 UTC, Robert A.
Details
backtrace (bt.txt,2.00 KB, text/plain)
2008-11-12 13:25 UTC, Robert A.
Details
Patch file to apply the sparc memory alignment patch (missing defs for the _uint8 functions). (tor-0.2.0.31-sparc.patch,1.14 KB, patch)
2008-11-13 23:26 UTC, Ferris McCormick (RETIRED)
Details | Diff
Proposed patch to correct the memory alignment problem reported here. (tor-0.2.0.31-sparc.patch,2.78 KB, patch)
2008-11-14 01:10 UTC, Ferris McCormick (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert A. 2008-11-12 13:22:31 UTC
# 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?
Comment 1 Robert A. 2008-11-12 13:23:34 UTC
Created attachment 171531 [details]
emerge --info
Comment 2 Robert A. 2008-11-12 13:25:09 UTC
Created attachment 171532 [details]
backtrace
Comment 3 Robert A. 2008-11-12 14:28:22 UTC
upstream bug @ http://bugs.noreply.org/flyspray/index.php?do=details&id=862
Comment 4 Robert A. 2008-11-12 16:17:17 UTC
upstream just fixed the issue in r17262.
i wonder why tor is marked stable for sparc..?
Comment 5 Christian Faulhammer (RETIRED) gentoo-dev 2008-11-13 15:04:40 UTC
(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.
Comment 6 Ferris McCormick (RETIRED) gentoo-dev 2008-11-13 16:55:49 UTC
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?
Comment 7 Christian Faulhammer (RETIRED) gentoo-dev 2008-11-13 20:39:22 UTC
(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.
Comment 8 Ferris McCormick (RETIRED) gentoo-dev 2008-11-13 23:22:05 UTC
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.
Comment 9 Ferris McCormick (RETIRED) gentoo-dev 2008-11-13 23:26:14 UTC
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.
Comment 10 Ferris McCormick (RETIRED) gentoo-dev 2008-11-14 01:10:05 UTC
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 11 Ferris McCormick (RETIRED) gentoo-dev 2008-11-14 01:13:50 UTC
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.
Comment 12 Ferris McCormick (RETIRED) gentoo-dev 2008-11-14 01:15:52 UTC
More administrative clean up.  I did a lot of things I hadn't intended, I see.
Comment 13 Robert A. 2008-11-14 11:19:50 UTC
(In reply to comment #10)
> Created an attachment (id=171682) [edit]
> Proposed patch to correct the memory alignment problem reported here.

works for me.
Comment 14 Ferris McCormick (RETIRED) gentoo-dev 2008-11-14 12:45:21 UTC
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.
Comment 15 Christian Faulhammer (RETIRED) gentoo-dev 2008-11-15 17:52:15 UTC
(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.