Hide Forgot
Description of problem: When I used the dropwatch-1.2-0.el6.i686 on my system(kernel -122.el6.i686), It issues Segmentation fault. Version-Release number of selected component (if applicable): dropwatch-1.2-0.el6.i686 How reproducible: always Steps to Reproduce: 1.yum install dropwatch-1.2-0.el6.i686 2.[root@dhcp-65-10 kaka]# dropwatch 3.dropwatch> start Enabling monitoring... Waiting for activation ack.... Waiting for activation ack.... Kernel monitoring activated. Issue Ctrl-C to stop monitoring Segmentation fault (core dumped) Actual results: Segmentation fault (core dumped) Expected results: Can use it normally. Additional info:
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Thanks for the report, I will look into it. It works fine at x86_64 though...
Seems, we have an excessive memory free, where we don't need it. This makes free_netlink_msg() to touch already freed memory which by-turn lead into sigfault. src/main.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/main.c b/src/main.c index da83242..7914bd9 100644 --- a/src/main.c +++ b/src/main.c @@ -266,7 +266,6 @@ restart: printf("Got an unexpected ack for sequence %d\n", errm->msg.nlmsg_seq); } - free_netlink_msg(msg); return NULL; }
Anton, how do you figure that to be a double free? Do we have a core file of this failure or a backtrace?
from valgrind for example (it's for 64bit): ==3983== Invalid read of size 4 ==3983== at 0x40140E: ??? (in /usr/bin/dropwatch) [cut] ==3983== Address 0x4c57db0 is 16 bytes inside a block of size 56 free'd Above means we touching what we must not. We have garbage there. gdb will show you exact place of sigsegv though, at el6.i686 too. Anton.
Program received signal SIGSEGV, Segmentation fault. 0x007322a3 in malloc_consolidate (av=0x8513a0) at malloc.c:5169 5169 unlink(nextchunk, bck, fwd); (gdb) backtrace #0 0x007322a3 in malloc_consolidate (av=0x8513a0) at malloc.c:5169 #1 0x00734c85 in _int_malloc (av=0x8513a0, bytes=4096) at malloc.c:4373 #2 0x00735c39 in __libc_calloc (n=1, elem_size=4096) at malloc.c:4065 #3 0x00a6922f in nl_recv (handle=0x804c1e0, nla=0xbffff44c, buf=0x804b8fc, creds=0x0) at nl.c:485 #4 0x08049027 in recv_netlink_message (err=0xbffff51c) at main.c:228 #5 0x080491f3 in process_rx_message () at main.c:297 #6 0x0804988c in enter_state_loop () at main.c:537 #7 0x08049a05 in main (argc=1, argv=0xbffff654) at main.c:608
Thank you. I've taken a look, and it turns out your correct. Theres actually two double free cases in the handle_stop and handle_start ack paths. I'd rather fix it by removing the free calls in the ack functions themselvs though, just to consolidate code. Theres still going to be some false positive erros on the part of valgrind because of how I pass some pointers around, but nothing major. I'll fix it in the upstream git this weekend and give you a link on monday. Thanks!
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the dropwatch utility could terminate unexpectedly with a segmentation fault. The failure was caused by a double-free error which occurred while issuing the start and stop messages. This update removes the freeing function calls from the underlying code, which prevents the dropwatch utility from crashing.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0383.html