[tor-bugs] #17827 [Tor]: Different return type of backtrace function on FreeBSD

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Dec 16 12:16:02 UTC 2015


#17827: Different return type of backtrace function on FreeBSD
---------------------------------------+-----------------------------------
 Reporter:  cypherpunks                |          Owner:
     Type:  defect                     |         Status:  reopened
 Priority:  Medium                     |      Milestone:  Tor:
Component:  Tor                        |  0.2.8.x-final
 Severity:  Normal                     |        Version:  Tor:
 Keywords:  027-backport freebsd easy  |  0.2.5.2-alpha
Parent ID:                             |     Resolution:
  Sponsor:                             |  Actual Points:
                                       |         Points:
---------------------------------------+-----------------------------------
Changes (by cypherpunks):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 It seems compilation is now failing on Linux. When we use a size_t input
 for `backtrace_symbols` and `backtrace_symbols_fd` on Linux the integer
 precision is implicitly decreased by stuffing it in the int parameter of
 these functions. This leads to the following errors.

 {{{
 src/common/backtrace.c:99:39: error: implicit conversion loses integer
 precision: 'size_t' (aka 'unsigned long') to 'int'
 [-Werror,-Wshorten-64-to-32]
   symbols = backtrace_symbols(cb_buf, depth);
             ~~~~~~~~~~~~~~~~~         ^~~~~
 src/common/backtrace.c:142:34: error: implicit conversion loses integer
 precision: 'size_t' (aka 'unsigned long') to 'int'
 [-Werror,-Wshorten-64-to-32]
     backtrace_symbols_fd(cb_buf, depth, fds[i]);
     ~~~~~~~~~~~~~~~~~~~~         ^~~~~
 src/common/backtrace.c:178:41: error: implicit conversion loses integer
 precision: 'size_t' (aka 'unsigned long') to 'int'
 [-Werror,-Wshorten-64-to-32]
     symbols = backtrace_symbols(cb_buf, depth);
               ~~~~~~~~~~~~~~~~~         ^~~~~
 3 errors generated.
 }}}

 We can solve these errors by either casting the depth parameter to int
 (which would then be implicitly cast back to size_t on FreeBSD) or use
 preprocessor checks to account for the differences between Linux and
 FreeBSD.

 My preference is the later solution because it looks cleaner IMO and we
 already do such checks in `clean_backtrace` to handle stack manipulation
 on different platforms. What does anybody else think?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17827#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list