Segfault when using ratop + Ctrl-R to redraw

Carter Bullard carter at qosient.com
Mon Oct 22 16:29:30 EDT 2012


Hey Jesse,
Sorry for the delay.  All bugs are important.  We have the highest respect for
digital arachnids, and treat all with the same respect, but we especially
respect the ones that generate dumps  !!!  ;O)

OK, Ctrl-R reverses the direction of the flow located by the cursor.
If the cursor is not on a line, then it does seem to generate an error.
But it seems to be fixed in argus-clients-3.0.7.x, so please give it a test run.

Carter 

On Oct 17, 2012, at 4:21 PM, Jesse Bowling <jessebowling at gmail.com> wrote:

> In my continued series of unimportant bugs, I've found that I can consistently crash ratop using the Ctrl-R keystroke. My poor memory recalled the redraw command as being Ctrl-R, but in fact it's Ctrl-D. While Ctrl-D works fine, Ctrl-R causes a segfault. Running Ubuntu 10.04 on 2.6.32-44-generic #98-Ubuntu SMP Mon Sep 24 17:27:10 UTC 2012 x86_64.
> 
> Starting program: /usr/local/bin/ratop
> [Thread debugging using libthread_db enabled]
> 
> [New Thread 0x7ffff6757700 (LWP 21221)]                                                                                                                                                                              2012/10/17.15:35:12 EDT
>                                        ratop -r
> 
> RaTopLoop() Idle.
> (Hit Ctrl-R)
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff6757700 (LWP 21221)]
> 0x000000000040cfaa in ArgusProcessCommand (parser=0x7ffff7e9e010, status=40, ch=18) at ./ratop.c:2845
> 2845    ./ratop.c: No such file or directory.
>         in ./ratop.c
> (gdb) where
> #0  0x000000000040cfaa in ArgusProcessCommand (parser=0x7ffff7e9e010, status=40, ch=18) at ./ratop.c:2845
> #1  0x00000000004096ea in ArgusCursesProcess (arg=0x0) at ./ratop.c:1781
> #2  0x00007ffff79439ca in start_thread () from /lib/libpthread.so.0
> #3  0x00007ffff724616d in clone () from /lib/libc.so.6
> #4  0x0000000000000000 in ?? ()
> (gdb) up
> #1  0x00000000004096ea in ArgusCursesProcess (arg=0x0) at ./ratop.c:1781
> 1781    in ./ratop.c
> (gdb) backtrace full
> #0  0x000000000040cfaa in ArgusProcessCommand (parser=0x7ffff7e9e010, status=40, ch=18) at ./ratop.c:2845
>         startline = 0
>         ns = 0xb8c6a0
>         retn = 40
>         x = 0
> #1  0x00000000004096ea in ArgusCursesProcess (arg=0x0) at ./ratop.c:1781
>         queue = 0xb544b0
>         tvbuf = {tv_sec = 0, tv_usec = 11956}
>         tvp = 0x7ffff6756e50
>         i = 0
>         ch = 18
>         in = {__fds_bits = {1, 0 <repeats 15 times>}}
>         blocked_signals = {__val = {18446744067132882943, 18446744073709551615 <repeats 15 times>}}
>         done = 0
> #2  0x00007ffff79439ca in start_thread () from /lib/libpthread.so.0
> No symbol table info available.
> #3  0x00007ffff724616d in clone () from /lib/libc.so.6
> No symbol table info available.
> #4  0x0000000000000000 in ?? ()
> No symbol table info available.
> 
> I'm still using version 3.0.6.2, and haven't yet upgraded to later versions or applied the patch you sent earlier. So perhaps the issue has already been fixed, and shame on me in that case...I'll get the latest clients tonight and try to replicate the issue.
> 
> Cheers,
> 
> Jesse
> 
> -- 
> Jesse Bowling
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121022/ff6cc21d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121022/ff6cc21d/attachment.bin>


More information about the argus mailing list