[ 
https://issues.apache.org/jira/browse/DISPATCH-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287921#comment-17287921
 ] 

ASF GitHub Bot commented on DISPATCH-1962:
------------------------------------------

jiridanek commented on pull request #1048:
URL: https://github.com/apache/qpid-dispatch/pull/1048#issuecomment-782841264


   One more leak in system_tests_http1_adaptor, which appears only sometimes, 
that needs to be suppressed
   
   ```
   68: ==15712==ERROR: LeakSanitizer: detected memory leaks
   68: 
   68: Indirect leak of 64 byte(s) in 1 object(s) allocated from:
   68:     #0 0x7fc7780f9602 in malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
   68:     #1 0x7fc776378396  (/lib/x86_64-linux-gnu/libc.so.6+0xeb396)
   68:     #2 0x7fc77637bd5d in getaddrinfo 
(/lib/x86_64-linux-gnu/libc.so.6+0xeed5d)
   68:     #3 0x7fc7780d268f  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x7168f)
   68:     #4 0x7fc77572568e in pgetaddrinfo 
/home/travis/build/apache/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:1368
   68:     #5 0x7fc77572568e in pn_proactor_raw_connect 
/home/travis/build/apache/qpid-dispatch/qpid-proton/c/src/proactor/epoll_raw_connection.c:196
   68:     #6 0x7fc7778ce0ad in _do_reconnect 
/home/travis/build/apache/qpid-dispatch/src/adaptors/http1/http1_server.c:449
   68:     #7 0x7fc777a86632 in qd_timer_visit 
/home/travis/build/apache/qpid-dispatch/src/timer.c:201
   68:     #8 0x7fc777a773b6 in handle 
/home/travis/build/apache/qpid-dispatch/src/server.c:1008
   68:     #9 0x7fc777a7d9b7 in thread_run 
/home/travis/build/apache/qpid-dispatch/src/server.c:1122
   68:     #10 0x7fc777a7f7f6 in qd_server_run 
/home/travis/build/apache/qpid-dispatch/src/server.c:1484
   68:     #11 0x402111 in main_process 
/home/travis/build/apache/qpid-dispatch/router/src/main.c:113
   68:     #12 0x401d68 in main 
/home/travis/build/apache/qpid-dispatch/router/src/main.c:367
   68:     #13 0x7fc7762ad82f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
   68: 
   68: -----------------------------------------------------
   68: Suppressions used:
   68:   count      bytes template
   68:       1         24 ^pn_condition$
   68:       1       1536 ^pn_raw_connection$
   68:       1         56 qdr_core_subscribe
   68:      37        120 _ctypes_alloc_format_string
   68:       3        144 ^pn_object_new$
   68:       1        128 ^pn_list$
   68:       1         24 ^pni_record_create$
   68:    5002    3527472 /libpython2.*.so
   68: -----------------------------------------------------
   68: 
   68: SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
   ```
   
   ```
   68: Indirect leak of 64 byte(s) in 1 object(s) allocated from:
   68:     #0 0x7fa6cfbf7602 in malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
   68:     #1 0x7fa6cdda0396  (/lib/x86_64-linux-gnu/libc.so.6+0xeb396)
   68:     #2 0x7fa6cdda3d5d in getaddrinfo 
(/lib/x86_64-linux-gnu/libc.so.6+0xeed5d)
   68:     #3 0x7fa6cfbd068f  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x7168f)
   68:     #4 0x7fa6cd15198e in pgetaddrinfo 
/home/travis/build/apache/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:1369
   68:     #5 0x7fa6cd15198e in pn_proactor_raw_connect 
/home/travis/build/apache/qpid-dispatch/qpid-proton/c/src/proactor/epoll_raw_connection.c:193
   68:     #6 0x7fa6cf30ccd5 in _do_reconnect 
/home/travis/build/apache/qpid-dispatch/src/adaptors/http1/http1_server.c:449
   68:     #7 0x7fa6cf4f35b3 in qd_timer_visit 
/home/travis/build/apache/qpid-dispatch/src/timer.c:201
   68:     #8 0x7fa6cf4e621e in handle 
/home/travis/build/apache/qpid-dispatch/src/server.c:1008
   68:     #9 0x7fa6cf4e771a in thread_run 
/home/travis/build/apache/qpid-dispatch/src/server.c:1122
   68:     #10 0x7fa6cf3c6d91 in _thread_init 
/home/travis/build/apache/qpid-dispatch/src/posix/threading.c:172
   68:     #11 0x7fa6ced936b9 in start_thread 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
   68: 
   68: -----------------------------------------------------
   68: Suppressions used:
   68:   count      bytes template
   68:       4         96 ^pn_condition$
   68:       4       6144 ^pn_raw_connection$
   68:       1         56 qdr_core_subscribe
   68:      37        120 _ctypes_alloc_format_string
   68:       6        336 ^pn_string_grow$
   68:      24       1128 ^pn_object_new$
   68:       4        512 ^pn_list$
   68:       7        168 ^pni_record_create$
   68:    4999    3525904 /libpython2.*.so
   68: -----------------------------------------------------
   68: 
   68: SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
   ```


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Make LSan suppressions more targeted and specific (within reason)
> -----------------------------------------------------------------
>
>                 Key: DISPATCH-1962
>                 URL: https://issues.apache.org/jira/browse/DISPATCH-1962
>             Project: Qpid Dispatch
>          Issue Type: Test
>    Affects Versions: 1.15.0
>            Reporter: Jiri Daněk
>            Priority: Major
>         Attachments: dispatch_leaking_agent.png
>
>
> There are some unfortunate suppressions in {{tests/lsan.supp}} at this moment:
> {code}
> leak:*libwebsockets*
> {code}
> This is way too broad. It suppresses leaks in Dispatch files, since it 
> matches e.g. {{src/http-libwebsockets.c}}.
> The stars at the beginning and end are actually assumed implicitly. If you do 
> not want substring match, you have to do ^foo$. LSan suppression format is 
> simplistic, very unlike Valgrind's.
> {code}
> leak:run_unit_tests.c
> {code}
> Same thing, any leaks revealed by running unit_tests get suppressed. This 
> suppression suppresses all leak traces that include run_unit_tests.c anywhere 
> in the stack. What't the point of running such tests under leak detector, 
> then?
> {code}
> leak:run_unit_tests.c
> leak:^libqpid-proton.so$
> {code}
> Same thing. The patterns suppress all leaks that include Python (or Proton) 
> anywhere in the stacktrace. That means there are huge blind spots where 
> dispatch leaks can hide. This is a weakness of the lsan.supp syntax (Valgrind 
> suppressions can be much more targeted and discerning).
> h3. Python leaks
> Leaks are known and there is ongoing effort to fight them: 
> https://bugs.python.org/issue1635741 (https://bugs.python.org/issue25302) and 
> https://www.python.org/dev/peps/pep-3121
> Here's valgrind suppression file from somebody who actually investigated the 
> Python leaks and identified the harmless ones: 
> https://github.com/libgit2/pygit2/blob/master/misc/valgrind-python.supp
> One example of a hidden leak in dispatch, which is revealed by making Python 
> suppressions more targetted:
> {code}
> 9: Direct leak of 56 byte(s) in 1 object(s) allocated from:
> 9:     #0 0x7f78a3606e8f in __interceptor_malloc 
> (/nix/store/g40sl3zh3nv52vj0mrl4iki5iphh5ika-gcc-10.2.0-lib/lib/libasan.so.6+0xace8f)
> 9:     #1 0x7f78a2d64afb in qd_malloc ../include/qpid/dispatch/ctools.h:229
> 9:     #2 0x7f78a2d657da in qdr_core_subscribe 
> ../src/router_core/route_tables.c:149
> 9:     #3 0x7f78a2c83072 in IoAdapter_init ../src/python_embedded.c:711
> 9:     #4 0x7f78a2353a6c in type_call 
> (/nix/store/r85nxfnwiv45nbmf5yb60jj8ajim4m7w-python3-3.8.5/lib/libpython3.8.so.1.0+0x165a6c)
> {code}
> The problem is in
> {code}
> class Agent:
>     ...
>     def activate(self, address):
>         ...
>         self.io = IoAdapter(self.receive, address, 'L', '0', 
> TREATMENT_ANYCAST_CLOSEST)
> {code}
> IoAdapter refers to Agent (through the bound method reference self.receive) 
> and Agent refers to IoAdapter (through property self.io). Since IoAdapter is 
> implemented in C and does not implement support for Python's cyclic GC, there 
> is no way to break the cycle.
> Heap dump in attachment. The bound method is at the top of the picture. 
> (Ignore the Mock objects, I was trying to simplify the picture while not 
> getting crashes due to too much meddling).
> h3. Random observations
> It is possible to build special Debug build of Python, which has tools to 
> detect leaks, asserts to prevent negative refcounts, etc. 
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-memory-alloc-label
> Use the following to detect python leaks (instead of valgrind)
> https://docs.python.org/3/library/tracemalloc.html
> Use https://pypi.org/project/objgraph (with graphviz) to view heap object 
> trees. The following renders the picture as a png under /tmp and prints the 
> path to stdout.
> {code}
> int ret = PyRun_SimpleString("import objgraph; 
> objgraph.show_backrefs(config.global_agent, max_depth=10)\n\n");
> PyErr_PrintEx(0);
> assert(ret == 0);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to