==00:00:01:09.081 1762== 48 bytes in 2 blocks are definitely lost in loss record 545 of 991
==00:00:01:09.081 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.081 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.081 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.081 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.081 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.081 1762== by 0x4E52AC3: init_cache (cache.c:67)
==00:00:01:09.081 1762== by 0x4E69530: charybdis_main (ircd.c:762)
==00:00:01:09.081 1762== by 0x400815: main (main.c:8)
==00:00:01:09.100 1762== 2,808 bytes in 117 blocks are definitely lost in loss record 960 of 991
==00:00:01:09.100 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.100 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.100 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.100 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.100 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.100 1762== by 0x4E5337A: load_help (cache.c:301)
==00:00:01:09.100 1762== by 0x4E698AA: charybdis_main (ircd.c:848)
==00:00:01:09.100 1762== by 0x400815: main (main.c:8)
==00:00:01:09.100 1762== 5,328 (5,304 direct, 24 indirect) bytes in 221 blocks are definitely lost in loss record 971 of 991
==00:00:01:09.100 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.100 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.100 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.100 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.100 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.100 1762== by 0x4E53278: load_help (cache.c:266)
==00:00:01:09.100 1762== by 0x4E698AA: charybdis_main (ircd.c:848)
==00:00:01:09.100 1762== by 0x400815: main (main.c:8)
==01:17:20:36.920 5966== 429 bytes in 3 blocks are possibly lost in loss record 899 of 1,020
==01:17:20:36.920 5966== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.920 5966== by 0x4E73867: rb_strdup (rb_memory.h:70)
==01:17:20:36.920 5966== by 0x4E7674C: conf_set_connect_fingerprint (newconf.c:1421)
==01:17:20:36.920 5966== by 0x4E78D55: conf_call_set (newconf.c:2562)
==01:17:20:36.920 5966== by 0x4E6A33D: yyparse (ircd_parser.y:215)
==01:17:20:36.920 5966== by 0x4E7FFC7: read_conf (s_conf.c:834)
==01:17:20:36.920 5966== by 0x4E81718: read_conf_files (s_conf.c:1419)
==01:17:20:36.920 5966== by 0x4E69567: charybdis_main (ircd.c:775)
==01:17:20:36.920 5966== by 0x400815: main (main.c:8)
==01:17:20:36.919 5966== 280 bytes in 8 blocks are definitely lost in loss record 876 of 1,020
==01:17:20:36.919 5966== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.919 5966== by 0x4E93F4F: rb_strdup (rb_memory.h:70)
==01:17:20:36.919 5966== by 0x4E95280: ssl_process_cipher_string (sslproc.c:476)
==01:17:20:36.919 5966== by 0x4E95540: ssl_process_cmd_recv (sslproc.c:561)
==01:17:20:36.919 5966== by 0x4E9582A: ssl_read_ctl (sslproc.c:632)
==01:17:20:36.919 5966== by 0x56CBAB6: rb_select_epoll (epoll.c:199)
==01:17:20:36.919 5966== by 0x56C4EB5: rb_select (commio.c:2085)
==01:17:20:36.919 5966== by 0x56C7FD6: rb_lib_loop (rb_lib.c:228)
==01:17:20:36.919 5966== by 0x4E69987: charybdis_main (ircd.c:872)
==01:17:20:36.919 5966== by 0x400815: main (main.c:8)
==01:17:20:36.906 5966== 48 bytes in 1 blocks are definitely lost in loss record 544 of 1,020
==01:17:20:36.906 5966== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.906 5966== by 0x4E93F0C: rb_malloc (rb_memory.h:41)
==01:17:20:36.906 5966== by 0x4E961E8: start_zlib_session (sslproc.c:901)
==01:17:20:36.906 5966== by 0x4E86FAC: server_estab (s_serv.c:877)
==01:17:20:36.906 5966== by 0x13B2921A: mr_server (m_server.c:304)
==01:17:20:36.906 5966== by 0x4E7AF03: handle_command (parse.c:241)
==01:17:20:36.906 5966== by 0x4E7A96A: parse (parse.c:157)
==01:17:20:36.906 5966== by 0x4E7A3DC: client_dopacket (packet.c:354)
==01:17:20:36.906 5966== by 0x4E798D6: parse_client_queued (packet.c:98)
==01:17:20:36.906 5966== by 0x4E79FAC: read_packet (packet.c:282)
==01:17:20:36.906 5966== by 0x56CBAB6: rb_select_epoll (epoll.c:199)
==01:17:20:36.906 5966== by 0x56C4EB5: rb_select (commio.c:2085)
[ircd/match.c:316]: (error) Shifting a negative value is undefined behaviour
[librb/src/patricia.c:55]: (error) Shifting a negative value is undefined behaviour
[modules/m_alias.c:64]: (portability) '(void*)message' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[modules/m_time.c:111]: (warning) %u in format string (no. 9) requires 'unsigned int' but the argument type is 'signed int'.
[modules/m_time.c:111]: (warning) %u in format string (no. 10) requires 'unsigned int' but the argument type is 'signed int'.
[librb/src/dictionary.c:819]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[librb/src/radixtree.c:1080]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[ircd/s_user.c:351] -> [ircd/s_user.c:357]: (warning) Either the condition '0!=source_p' is redundant or there is possible null pointer dereference: source_p.
[extensions/ip_cloaking_3.0.c:109]: (warning, inconclusive) The buffer 'buf' may not be null-terminated after the call to strncpy().
[ircd/chmode.c:256]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_help.c:100]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_knock.c:169]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:628]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:727]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:601]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:704]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:739]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:763]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:768]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:774]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:781]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:786]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:791]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:804]: (style) Clarify calculation precedence for '&' and '?'.
[ircd/wsproc.c:372]: (style) Unused variable: len
[modules/core/m_modules.c:382]: (style) Unused variable: i
[modules/m_stats.c:741]: (style) Unused variable: amsg
[ircd/authproc.c:390]: (style) Unused variable: iter
[ircd/authproc.c:391]: (style) Unused variable: client_p
Links that are 'no-export' are not distributed to the rest of the IRC network (including local peers).
This provides a core primitive for 'anycasting' services (but the actual issue of synchronizing data in
a services package is left to the authors of the services package).
On FreeBSD 4.8, fork(2) doesn't actually behave like fork(2).
Namely, kqueue(2) descriptors are not inherited by the child.
IOW, we can't fork(2) after we get the kqueue(2) descriptor.
So we'll just have to rely on people to actually read the
server log file if they want to understand why their server
is dying during startup.
