[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