Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:56:43Zhttps://gitlab.torproject.org/legacy/trac/-/issues/348Excessive loggin at warning2020-06-13T13:56:43ZTracExcessive loggin at warningActual version is 23, not 24. Installed with vidalia package pre-made for Mac Os X.
Problem: I'm getting LOTS of log messages like:
Oct 25 08:17:16 stbmac Tor[14520]: add_nickname_list_to_smartlist(): Nickname list includes 'serifos' w...Actual version is 23, not 24. Installed with vidalia package pre-made for Mac Os X.
Problem: I'm getting LOTS of log messages like:
Oct 25 08:17:16 stbmac Tor[14520]: add_nickname_list_to_smartlist(): Nickname list includes 'serifos' which is known but down.\n
Oct 25 08:17:17 stbmac Tor[14520]: add_nickname_list_to_smartlist(): Nickname list includes 'lefkada' which is known but down.\n
These go away if I tell my system to stop using tor. I get these every time
something on my system that pays attention to my HTTP proxy settings tries
to open a connection.
In my config file, I have EntryNodes and ExitNodes set to a large set of
high bandwidth nodes located on my continent (as an attempt to make Tor run
faster -- it was too slow out of the box with no config help).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: keybounce0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/347Some controller signals only work on unix2020-06-13T13:56:43ZRoger DingledineSome controller signals only work on unixcontrol_signal_check() and control_signal_act hard-code the
signal numbers to be the ones used in unix.
But handle_control_signal() uses the system-defined values for them.
One of these behaviors is wrong.
E.g., USR1 and USR2 (among p...control_signal_check() and control_signal_act hard-code the
signal numbers to be the ones used in unix.
But handle_control_signal() uses the system-defined values for them.
One of these behaviors is wrong.
E.g., USR1 and USR2 (among possibly others) don't work on OS X from the
controller.
[Automatically added by flyspray2trac: Operating System: All]0.1.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/346memory leak in router_rebuild_store() in routerlist.c2020-06-13T13:56:42ZTracmemory leak in router_rebuild_store() in routerlist.ctor/src/or % cat routerlist.c.diff
268c268
< smartlist_t *lst = smartlist_create();
---
> smartlist_t *lst;
283d282
< smartlist_free(lst);
321,322d319
< smartlist_free(old_routers);
< smartlist_free(routers);
333a331...tor/src/or % cat routerlist.c.diff
268c268
< smartlist_t *lst = smartlist_create();
---
> smartlist_t *lst;
283d282
< smartlist_free(lst);
321,322d319
< smartlist_free(old_routers);
< smartlist_free(routers);
333a331,332
> smartlist_free(old_routers);
> smartlist_free(routers);
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: fookoowahttps://gitlab.torproject.org/legacy/trac/-/issues/344tor terminates when running out of memory2020-06-13T13:56:42ZTractor terminates when running out of memoryI am running a tor 0.1.1.24-1~~sarge.1 server on a virtual server (OpenVZ).
One thing about OpenVZ is that the amount of memory available to the virtual machine varies all the time.
The server shuts down when it runs out of memory:
Logf...I am running a tor 0.1.1.24-1~~sarge.1 server on a virtual server (OpenVZ).
One thing about OpenVZ is that the amount of memory available to the virtual machine varies all the time.
The server shuts down when it runs out of memory:
Logfile entry:
Oct xx xx:xx:xx.xxx [err] _tor_realloc(): Out of memory. Dying.
I would like tor to keep running when it runs out of memory - perhaps it can just close a few connections,
stop accepting new connections for a while, discard some buffers etc?
Tor terminating because it runs out of memory is not listed at
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#head-43d0c843cb6c453ad1231c48c11196a46fae9540
so I think perhaps this is a bug?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: snpost 0.2.0.xNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/342No connections after start of next interval of AccountingStart?2020-06-13T13:56:41ZTracNo connections after start of next interval of AccountingStart?The server 'roundabout' started a new interval on 4th Oct. 00:00.
By this time no traffic amount is logged as related to Tor (as of 4th Oct. 18:38) although notices.log
shows the messages that the server should be waked up at 08:05:24 l...The server 'roundabout' started a new interval on 4th Oct. 00:00.
By this time no traffic amount is logged as related to Tor (as of 4th Oct. 18:38) although notices.log
shows the messages that the server should be waked up at 08:05:24 local time.
torrc has the following settings:
AccountingStart month 4 00:00
AccountingMax 145 GB
The file /var/log/tor/notices.log shows the following:
---snip---
Oct 04 00:00:00.011 [notice] accounting_set_wakeup_time(): Configured hibernation. This interval began at 2006-10-04 00:00:00; the scheduled wake-up time is 2006-10-04 08:05:24; we expect to exhaust our quota for this interval around 2006-11-03 20:43:24; the next interval begins at 2006-11-04 00:00:00 (all times local)
Oct 04 00:00:01.031 [notice] consider_hibernation(): Commencing hibernation. We will wake up at 2006-10-04 08:05:24 local time.
Oct 04 00:00:01.031 [notice] hibernate_go_dormant(): Going dormant. Blowing away remaining connections.
Oct 04 00:26:28.771 [notice] I learned some more directory information, but not enough to build a circuit.
Oct 04 00:56:57.609 [notice] I learned some more directory information, but not enough to build a circuit.
[....]
Oct 04 07:44:40.899 [notice] I learned some more directory information, but not enough to build a circuit.
Oct 04 08:15:10.531 [notice] I learned some more directory information, but not enough to build a circuit.
[....]
Oct 04 17:30:22.398 [notice] I learned some more directory information, but not enough to build a circuit.
Oct 04 18:00:54.076 [notice] I learned some more directory information, but not enough to build a circuit.
Oct 04 18:31:24.745 [notice] I learned some more directory information, but not enough to build a circuit.
---snap---
[....] means the messages repeated with different timestamps.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Maschi0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/341Mac OS X: bad permissions for log file2020-06-13T13:56:41ZTracMac OS X: bad permissions for log fileFollowing Apple guidelines, the location of Tor log file is incorrect (should be in /var/log/). A link is made from /var/log/tor to //Library/Tor/var/log/tor.
However, permissions are wrong when compared to other system logs and applicat...Following Apple guidelines, the location of Tor log file is incorrect (should be in /var/log/). A link is made from /var/log/tor to //Library/Tor/var/log/tor.
However, permissions are wrong when compared to other system logs and application Console.app cannot read it. File should be owned by root:admin
and permissions set to -rw-r-----
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: Steff-XAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/340WinXP VC++ Debug Error2020-06-13T13:56:40ZTracWinXP VC++ Debug ErrorA few days ago I installed the tor 0.1.1.23 bundle on WinXP SP2 (XP2500+, 1gb).
I configured it as a middle-man only server. It's behind a NAT router.
Today I found a MS VC++ Debug Library error on my desktop:
Debug Error!
Program...A few days ago I installed the tor 0.1.1.23 bundle on WinXP SP2 (XP2500+, 1gb).
I configured it as a middle-man only server. It's behind a NAT router.
Today I found a MS VC++ Debug Library error on my desktop:
Debug Error!
Program: D:\Net\Tor\tor.exe
This application has requested the runtime to terminate it in an unusual way
Please contact the application's support team for more information
I clicked on Retry to "debug" and got the standard XP fault window. Unfortunately
I neglected to save the appcompat file containing the details.
Vidalia seemed to be hung after this. I terminated Vidalia, restarted it (which
restarted tor) and all is running fine again.
Not much to go on, I know. I'll add details if it happens again.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: torsrv-ishttps://gitlab.torproject.org/legacy/trac/-/issues/339getinfo address doesn't work2020-06-13T13:56:40ZAndrew Lewmangetinfo address doesn't workgetinfo address
552 Unrecognized key "address"
line 1524 of control.c states:
" } else if (!strcmp(question, "address")) {
uint32_t addr;
if (router_pick_published_address(get_options(), &addr) < 0)
return -1;
*answer...getinfo address
552 Unrecognized key "address"
line 1524 of control.c states:
" } else if (!strcmp(question, "address")) {
uint32_t addr;
if (router_pick_published_address(get_options(), &addr) < 0)
return -1;
*answer = tor_dup_addr(addr);
"
Is this getinfo address only for servers?
If so, the control-spec.txt doesn't state this.
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/legacy/trac/-/issues/338dump stats uses keyid for IP2020-06-13T13:56:40ZAndrew Lewmandump stats uses keyid for IPSep 20 20:01:05.814 [notice] Service configured in "/var/lib/tor/hidden_service/":
Sep 20 20:01:05.814 [notice] Intro point at $370DBEAB52857D89333B66B4DDDA5AA2F95FADE1: circuit is open
Sep 20 20:01:05.814 [notice] Intro point at $B5...Sep 20 20:01:05.814 [notice] Service configured in "/var/lib/tor/hidden_service/":
Sep 20 20:01:05.814 [notice] Intro point at $370DBEAB52857D89333B66B4DDDA5AA2F95FADE1: circuit is open
Sep 20 20:01:05.814 [notice] Intro point at $B59573CCCED8E8A96B6DDA70C818F65CC3799532: circuit is open
Sep 20 20:01:05.814 [notice] Intro point at $8CCA8F718E687F2B38CAAECF114278ADE7ACC597: circuit is open
Should the keyids be nicknames?
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/legacy/trac/-/issues/337getinfo entry-guard should display nicknames2020-06-13T13:56:39ZAndrew Lewmangetinfo entry-guard should display nicknamesIn the controller, getinfo entry-guards displays:
getinfo entry-guards
250+entry-guards=
$445B04E58D03405934CD67937C404F97237BCD6F up
$16D48CCAB785608CD5683378BFC0A6C88A21C086 up
$F5A69E872302685259F1EDDAB3FD69FD9AA43C77 up
$8C727AB7F60F...In the controller, getinfo entry-guards displays:
getinfo entry-guards
250+entry-guards=
$445B04E58D03405934CD67937C404F97237BCD6F up
$16D48CCAB785608CD5683378BFC0A6C88A21C086 up
$F5A69E872302685259F1EDDAB3FD69FD9AA43C77 up
$8C727AB7F60FFB21E37C9D864079E73F31FD2F6A down 2006-09-20 20:50:25
$4DEC68FA337D184C67DD7112BA6AC40E2F6151EB up
$F6AECB92287C4864FE60D981FC39A8EBA8FCEC37 up
I'd like it to display nicknames.
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/legacy/trac/-/issues/336controller gives us unnamed (ambiguous) nicknames2020-06-13T13:56:39ZRoger Dingledinecontroller gives us unnamed (ambiguous) nicknamesIt looks like the controller circ events mention nicknames of servers, even when
they are unnamed and there are multiple servers with that nickname. They should
be listing keyid.
[Automatically added by flyspray2trac: Operating System: ...It looks like the controller circ events mention nicknames of servers, even when
they are unnamed and there are multiple servers with that nickname. They should
be listing keyid.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/335Malformed extendcircuit from a controller can crash Tor2020-06-13T13:56:39ZedmanmMalformed extendcircuit from a controller can crash TorIf the controller is naughty and doesn't follow the control-spec.txt for EXTENDCIRCUIT, it can crash Tor.
Tested with 0.1.1.23 and 0.1.2.1-alpha.
[edmanm@adrastea:~]$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Es...If the controller is naughty and doesn't follow the control-spec.txt for EXTENDCIRCUIT, it can crash Tor.
Tested with 0.1.1.23 and 0.1.2.1-alpha.
[edmanm@adrastea:~]$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
authenticate
250 OK
extendcircuit 0 pasiphae thorforlife yargh
Connection closed by foreign host.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000008
0x00029c78 in handle_control_extendcircuit (conn=0x1588160, len=20457776, body=0x4 <Address 0x4 out of bounds>) at control.c:1751
1751 if (get_purpose(smartlist_get(args,2), 1, &intended_purpose) < 0) {
(gdb) bt
#0 0x00029c78 in handle_control_extendcircuit (conn=0x1588160, len=20457776, body=0x4 <Address 0x4 out of bounds>) at control.c:1751
#1 0x0002d7cc in connection_control_process_inbuf_v1 (conn=0x1588160) at control.c:2417
#2 0x0002e158 in connection_control_process_inbuf (conn=0x1588160) at control.c:2609
#3 0x00020300 in connection_handle_read (conn=0x1588160) at connection.c:1313
#4 0x00040bd4 in conn_read_callback (fd=25165824, event=1, _conn=0xbffff348) at main.c:405
#5 0x00073ba0 in event_base_loop (base=0x500ac0, flags=0) at event.c:256
#6 0x00040830 in tor_main (argc=591304, argv=0xbffff808) at main.c:1164
#7 0x000019ec in _start (argc=3, argv=0xbffff808, envp=0xbffff818) at /SourceCache/Csu/Csu-57.0.82/crt.c:272
#8 0x00001890 in start ()
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/334segmentation fault in controller code2020-06-13T13:56:38ZTracsegmentation fault in controller codeversion -- 0.1.2.1-alpha
gdb backtrace --
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
#0 handle_control_getinfo (conn=0x83c1580, len=<value optimized out>,
body=0x837bdd8 "stream-...version -- 0.1.2.1-alpha
gdb backtrace --
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
#0 handle_control_getinfo (conn=0x83c1580, len=<value optimized out>,
body=0x837bdd8 "stream-status\r\n") at control.c:1455
1455 if (CIRCUIT_IS_ORIGIN(circ))
(gdb) bt
#0 handle_control_getinfo (conn=0x83c1580, len=<value optimized out>,
body=0x837bdd8 "stream-status\r\n") at control.c:1455
#1 0x0807941c in connection_control_process_inbuf_v1 (conn=0x83c1580) at control.c:2414
#2 0x0807962d in connection_control_process_inbuf (conn=0x83c1580) at control.c:2609
#3 0x080672a6 in connection_process_inbuf (conn=0x89, package_partial=1) at connection.c:2066
#4 0x0806a0dd in connection_handle_read (conn=0x83c1580) at connection.c:1313
#5 0x0808d799 in conn_read_callback (fd=4, event=2, _conn=0x83c1580) at main.c:405
#6 0xb7d29c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#7 0xb7d29f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#8 0xb7d29dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
#9 0xb7d29cb0 in event_dispatch () from /usr/lib/libevent-1.1a.so.1
#10 0x0808d397 in tor_main (argc=1, argv=0xbfef6724) at main.c:1164
#11 0x080acda2 in main (argc=Cannot access memory at address 0x89
) at tor_main.c:22
#12 0xb7c09ea8 in __libc_start_main () from /lib/tls/libc.so.6
#13 0x0804c781 in _start () at ../sysdeps/i386/elf/start.S:119
--
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: fookoowahttps://gitlab.torproject.org/legacy/trac/-/issues/333Torrc file cannot be updated in Standard User mode2020-06-13T13:56:37ZTracTorrc file cannot be updated in Standard User modeWhen running Tor using Vidalia in Standard User mode on a Mac, Vidalia reports that the torrc file in Macintosh HD/Library/Tor/ cannot be edited or saved as torrc.orig.1. This does not occur as an Administrator. This happens on new and...When running Tor using Vidalia in Standard User mode on a Mac, Vidalia reports that the torrc file in Macintosh HD/Library/Tor/ cannot be edited or saved as torrc.orig.1. This does not occur as an Administrator. This happens on new and updated installations. My workaround has been to use the Torrc Configurator web page to create a new torrc, then save this in the Macintosh HD/Library/Tor/ folder, overwriting the original torrc. This does not solve the issue as warning alerts occur about the problem in Vidalia, however Tor does seem to function afterwards.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: jwbeck17https://gitlab.torproject.org/legacy/trac/-/issues/332does not build with -O02020-06-13T13:56:37Zweasel (Peter Palfrader)does not build with -O0tor trunk does not build without -O2. That's because apparently
gcc doesn't inline extern INLINE fooo functions() without -O2.
gcc -g -O0 -Wall -g -O0 -o tor buffers.o circuitbuild.o circuitlist.o circuituse.o command.o config.o con...tor trunk does not build without -O2. That's because apparently
gcc doesn't inline extern INLINE fooo functions() without -O2.
gcc -g -O0 -Wall -g -O0 -o tor buffers.o circuitbuild.o circuitlist.o circuituse.o command.o config.o connection.o connection_edge.o connection_or.o control.o cpuworker.o directory.o dirserv.o dns.o hibernate.o main.o onion.o policies.o relay.o rendcommon.o rendclient.o rendmid.o rendservice.o rephist.o router.o routerlist.o routerparse.o eventdns.o tor_main.o ../common/libor.a ../common/libor-crypto.a -lz -lssl -lcrypto -lpthread -ldl -levent -lssl -lcrypto
circuitbuild.o: In function `circuit_n_conn_done':
/tmp/buildd/tor-trunk/src/or/circuitbuild.c:357: undefined reference to `TO_ORIGIN_CIRCUIT'
circuitbuild.o: In function `ap_stream_wants_exit_attention':
/tmp/buildd/tor-trunk/src/or/circuitbuild.c:1052: undefined reference to `TO_EDGE_CONN'
/tmp/buildd/tor-trunk/src/or/circuitbuild.c:1052: undefined reference to `TO_EDGE_CONN'
circuitbuild.o: In function `choose_good_exit_server_general':
/tmp/buildd/tor-trunk/src/or/circuitbuild.c:1142: undefined reference to `TO_EDGE_CONN'
[...]
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/331ExitPolicy should reject nntps2020-06-13T13:56:36ZTracExitPolicy should reject nntpsThe default exit policy rejects nntp but not nntps.
The following line is missing:
ExitPolicy reject *:563
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: JensThe default exit policy rejects nntp but not nntps.
The following line is missing:
ExitPolicy reject *:563
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: JensAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/330DNS at exit should tolerate broken providers (aka "Earthlink")2020-06-13T13:56:36ZNick MathewsonDNS at exit should tolerate broken providers (aka "Earthlink")See http://slashdot.org/article.pl?sid=06/09/03/1359221
Some ISPs have decided that implementing the internet correctly is not so worthwhile
as pointing people towards their advertising. Sadly, some Tor exit server operators
have signe...See http://slashdot.org/article.pl?sid=06/09/03/1359221
Some ISPs have decided that implementing the internet correctly is not so worthwhile
as pointing people towards their advertising. Sadly, some Tor exit server operators
have signed up for these ISPs, and every time they attempt to resolve a nonexistant DNS
entry, they get the IP for the ISP's "oops! let's help you out!" site rather than the
correct error code.
Exit nodes could detect this pretty easily by periodically attempting to lookup a few
guaranteed-to-be-nonexistant domains, and seeing whether they resolve to anything. If
they do, the exit node could
a) switch to using the root nameservers
b) treat any IP returned by such test resolves as equivalent to a "no such domain" error.
c) warn the operator
d) ... ?
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/329do_main_loop() error, no buffer space available, TOR crash2020-06-13T13:56:36ZTracdo_main_loop() error, no buffer space available, TOR crashUpon opening this page http://www.vanjongeleu.nl/, Privoxy start generating this message in the log:
Sep 04 16:03:54 Privoxy(02716) Request: www.vanjongeleu.nl/index2.php?page=home&subpage=homeNieuws
Sep 04 16:03:54 Privoxy(02820) Error...Upon opening this page http://www.vanjongeleu.nl/, Privoxy start generating this message in the log:
Sep 04 16:03:54 Privoxy(02716) Request: www.vanjongeleu.nl/index2.php?page=home&subpage=homeNieuws
Sep 04 16:03:54 Privoxy(02820) Error: write to: www.vanjongeleu.nl failed: WSAECONNABORTED - Software caused connection abort.
This causes TOR to crash with the following error:
sep 04 15:57:36:750 [Error] do_main_loop(): libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]
Using Firefox 1.5.0.6, and the TOR-package "Tor 0.1.1.23" on Windows XP Pro with SP2 and all the latest patches installed.
The error is repeatable all the time.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: ziesjoemhttps://gitlab.torproject.org/legacy/trac/-/issues/328Valid flags should only apply for naming authorities?2020-06-13T13:56:36ZRoger DingledineValid flags should only apply for naming authorities?Right now authorities mark servers as valid unless they manually decide not to.
Part of the goal of the 'naming' flag for authorities is to specify whether they
want to futz with their configuration and express opinions, or just leave i...Right now authorities mark servers as valid unless they manually decide not to.
Part of the goal of the 'naming' flag for authorities is to specify whether they
want to futz with their configuration and express opinions, or just leave it to
run.
I think we should make clients decide whether a server is valid based on a majority
of naming authorities, rather than a majority of all authorities.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/327Build failure and warnings with svn 83082020-06-13T13:56:35ZTracBuild failure and warnings with svn 8308Hi,
I use NetBSD 3_Stable...
First, there is a mistake in src/common/compat.h. I interpreted what I thought you meant and created this diff:
clarity 141 -> svn di src/common/compat.h
Index: src/common/compat.h
=========================...Hi,
I use NetBSD 3_Stable...
First, there is a mistake in src/common/compat.h. I interpreted what I thought you meant and created this diff:
clarity 141 -> svn di src/common/compat.h
Index: src/common/compat.h
===================================================================
--- src/common/compat.h (revision 8308)
+++ src/common/compat.h (working copy)
@@ -90,7 +90,7 @@
#endif
/* GCC has several useful attributes. */
-#ifdef __GNUC__ && __GNUC_MAJOR__ >= 3
+#if defined(__GNUC__) && __GNUC_MAJOR__ >= 3
#define ATTR_NORETURN __attribute__((noreturn))
#define ATTR_PURE __attribute__((pure))
#define ATTR_MALLOC __attribute__((malloc))
****
In addition, after fixing this, I find the following warnings as probable mistakes:
util.c: In function `tor_strlower':
util.c:311: warning: subscript has type `char'
util.c: In function `tor_strupper':
util.c:322: warning: subscript has type `char'
----
config.c: In function `get_default_nickname':
config.c:1740: warning: subscript has type `char'
I don't know if this functions properly, I do not want to install until it builds clean.
--gene
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: yancm