I am debugging an application crash using the net-snmp library. The backtrace is as follows:
#0 0x001a1c7e in _snmp_parse (sessp=0x0, session=<value optimized out>, pdu=0xb6183858, data=0xa3401248 "\301", length=12097984) at snmp_api.c:4408
#1 0x001a20bb in snmp_resend_request (slp=0x0, rp=0xb6184818, incr_retries=1) at snmp_api.c:6383
#2 0x00b89944 in send_trap_to_sess (sess=0xb6122848, template_pdu=0xa3401440) at agent_trap.c:945
#3 0x00b8ab46 in netsnmp_send_traps (trap=-1, specific=-1, enterprise=0xbbd080, enterprise_length=10, vars=0xa5400468, context=0x0, flags=0)
at agent_trap.c:839
#4 0x00b8b0fa in send_enterprise_trap_vars (trap=-1, specific=-1, enterprise=0xbbd080, enterprise_length=10, vars=0xa5400468) at agent_trap.c:863
#5 0x00b8b153 in send_trap_vars (trap=-1, specific=-1, vars=0xa5400468) at agent_trap.c:975
#6 0x00b8b1fe in send_v2trap (vars=0xa5400468) at agent_trap.c:1049
#7 0x00288382 in applicationBaseClass::sendTraps (temp=0x161d3018) at appBaseClass.cpp:750
#8 0x00288311 in applicationBaseClass::sendTrapsByTimer (temp=0x161d3018) at appBaseClass.cpp:736
#9 0x00ac05f3 in check_timers () at exec_timer.c:383
I installed the net-snmp-debuginfo to get the source files. The details:
net-snmp-libs-5.5-57.el6_8.1.i686
net-snmp-utils-5.5-57.el6_8.1.i686
net-snmp-debuginfo-5.5-57.el6_8.1.i686
net-snmp-5.5-57.el6_8.1.i686
We can see that the source files correspond to the net-snmp version installed - 5.5-57
Now my application is linking to net-snmp :
[root#stg blr]# lsof -p 4043 | grep snmp
serv_trans 4043 root mem REG 8,2 1760620 4031 /usr/lib/libnetsnmpmibs.so.20.0.0
serv_trans 4043 root mem REG 8,2 701880 4978 /usr/lib/libnetsnmp.so.20.0.0
serv_trans 4043 root mem REG 8,2 313568 3982 /usr/lib/libnetsnmpagent.so.20.0.0
serv_trans 4043 root mem REG 8,2 157008 4017 /usr/lib/libnetsnmphelpers.so.20.0.0
So the application is rightly linking with the net-snmp libraries of version 5.5-57
Now, to the backtrace. The stack seems to be incorrect. It is not showing the exact call sequence. For example, in the frame 2, the line number that gdb shows- 6383 -is actually a declaration statement.
#1 0x001a20bb in snmp_resend_request (slp=0x0, rp=0xb6184818, incr_retries=1) at snmp_api.c:6383
6383 u_char *pktbuf = NULL, *packet = NULL;
What could be I missing? I seem to be having the right source files for gdb. Why isn't the stack trace from gdb not pointing to the exact sequence of events?
Related
It's OK for me to use the command line like this.
ffmpeg -i test1.mp4 -i test2.mp4 -filter_complex "movie='test1.mp4',scale=640:360[v1];movie='test2.mp4',scale=640:360[v2];[v1][v2]concat" testout.mp4
This is my configuration code.
AVFilterInOut* inputs = avfilter_inout_alloc();
AVFilterInOut* outputs = avfilter_inout_alloc();
...
avfilter_graph_parse_ptr(filter->filterGraph,
"movie='test1.mp4',scale=640:360[v1];movie='test2.mp4',scale=640:360[v2];[v1][v2]concat",
&inputs, &outputs, NULL)
avfilter_graph_config(filter->filterGraph, NULL)
Reported error
[h264 # 0000026dfecef780] Application has requested 17 threads. Using a thread count greater than 16 is not recommended.
[h264 # 0000026dffae9d00] Application has requested 17 threads. Using a thread count greater than 16 is not recommended.
Output pad "default" with type video of the filter instance "in" of buffer not connected to any destination
How can I configure the filter correctly？
I am learning to use the LLDB.py module in python and am trying to run the following example I found on http://lldb.llvm.org/python-reference. I already added lldb.so to PYTHONPATH. Here is the result I got:
Creating a target for './a.out'
a.out
SBBreakpoint: id = 1, name = 'main', module = a.out, locations = 1
SBProcess: pid = 0, state = launching, threads = 0, executable = a.out
It seems like the program doesn't get started, the state of process is always Launching. Is there any configuration problems or any missing codes?
import lldb
import os
def disassemble_instructions(insts):
for i in insts:
print i
# Set the path to the executable to debug
exe = "./a.out"
# Create a new debugger instance
debugger = lldb.SBDebugger.Create()
# When we step or continue, don't return from the function until the process
# stops. Otherwise we would have to handle the process events ourselves which, while doable is
#a little tricky. We do this by setting the async mode to false.
debugger.SetAsync (False)
# Create a target from a file and arch
print "Creating a target for '%s'" % exe
target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)
if target:
# If the target is valid set a breakpoint at main
main_bp = target.BreakpointCreateByName ("main", target.GetExecutable().GetFilename());
print main_bp
# Launch the process. Since we specified synchronous mode, we won't return
# from this function until we hit the breakpoint at main
process = target.LaunchSimple (["./story.txt"], None, os.getcwd())
# Make sure the launch went ok
if process:
# Print some simple process info
state = process.GetState ()
print process
if state == lldb.eStateStopped:
# Get the first thread
thread = process.GetThreadAtIndex (0)
if thread:
# Print some simple thread info
print thread
# Get the first frame
frame = thread.GetFrameAtIndex (0)
if frame:
# Print some simple frame info
print frame
function = frame.GetFunction()
# See if we have debug info (a function)
if function:
# We do have a function, print some info for the function
print function
# Now get all instructions for this function and print them
insts = function.GetInstructions(target)
disassemble_instructions (insts)
else:
# See if we have a symbol in the symbol table for where we stopped
symbol = frame.GetSymbol();
if symbol:
# We do have a symbol, print some info for the symbol
print symbol
}
I'd like to print the output of a program in php in "real time" (buffers are not important). The process takes a long time and having the (partial) data earlier would be very helpful.
Usually I'd use plain passthru() but this is done in CakePHP and it doesn't output anything until I do this:
$this->response->file($file, array('download' => true));
return $this->response;
If I just remove these lines and swap the exec() with a passthru() I get a MissingViewException
Error: [MissingViewException] View file "Songs/download.ctp" is missing.
And If I do this
$this->response=$out; #$out being the output of exec()
return $this->response;
I get this
2015-08-10 01:18:06 Error: Fatal Error (1): Call to a member function body() on string in [/storage/www/sonerezh/lib/Cake/Controller/Controller.php, line 960]
2015-08-10 01:18:06 Error: [InternalErrorException] Internal Server Error
Request URL: /songs/download/2307
Stack Trace:
#0 /storage/www/sonerezh/lib/Cake/Error/ErrorHandler.php(213): ErrorHandler::handleFatalError(1, 'Call to a membe...', '/storage/www/so...', 960)
#1 [internal function]: ErrorHandler::handleError(1, 'Call to a membe...', '/storage/www/so...', 960, Array)
#2 /storage/www/sonerezh/lib/Cake/Core/App.php(931): call_user_func('ErrorHandler::h...', 1, 'Call to a membe...', '/storage/www/so...', 960, Array)
#3 /storage/www/sonerezh/lib/Cake/Core/App.php(904): App::_checkFatalError()
#4 [internal function]: App::shutdown()
#5 {main}
What can I do?
You could try this (not tested):
$this->response->body(function () {
passthru ('./program') ;
}) ;
return $this->response ;
More information here.
Note: I assumed your were using CakePHP 3 since CakeResponse::file does not exist in CakePHP 2.
I have a core generated. /var/log/messages displays this line:
Jan 29 07:50:40 NetAcc-02 kernel: LR.exe[15326]: segfault at 51473861 ip 081e2dba sp 00240030 error 4 in LR.exe[8048000+34c000]
Jan 29 07:50:52 NetAcc-02 abrt[20696]: saved core dump of pid 15252 (/home/netacc/active/LR.exe) to /var/spool/abrt/ccpp-2015-01-29-07:50:40-15252.new/coredump (1642938368 bytes)
Jan 29 07:50:52 NetAcc-02 abrtd: Directory 'ccpp-2015-01-29-07:50:40-15252' creation detected
Jan 29 07:50:54 NetAcc-02 abrtd: Executable '/home/netacc/active/LR.exe' doesn't belong to any package
Jan 29 07:50:54 NetAcc-02 abrtd: Corrupted or bad dump /var/spool/abrt/ccpp-2015-01-29-07:50:40-15252 (res:2), deleting
Does the last line mean that the core is corrupted? Because a bt of my corefile seems to be corrupted:
#0 0x081e2dba in CfaPepDecision (pBuf=0xa0d6735, pIp=0x5147384d, u2DirectFlag=1, ppepserver=0x67684e6f, paccl=0x45517377, pPepMode=0x6a31396c "") at /home/TAN/release/rel/idu-sw/pep/pep/src/pepcfa.c:498
#1 0x52367331 in ?? ()
#2 0x0a0d6735 in gProfileVsatTable ()
#3 0x5147384d in ?? ()
#4 0x75417875 in ?? ()
#5 0x38000200 in ?? ()
Strangely the gProfileVsatTable is a global array!
The address pIp = 0x5147384d is out of bounds in gdb.
Any inputs are helpful.
Because a bt of my corefile seems to be corrupted:
This is usually the result of analyzing the wrong binary. Invoke GDB like this:
gdb /home/netacc/active/LR.exe \
/var/spool/abrt/ccpp-2015-01-29-07:50:40-15252.new/coredump
Make sure that you have not updated the binary since Jan 29 07:50:52. In particular, make sure you did not rebuild the binary with different options after the crash.
My program is statically compiled with dietlibc. It is compiled on ubuntu x64 (compiled for x86 using the -m32 flag) and is run on a centos x86.
The compiled size is only about 100KB. I compile it with -ggdb3 and no optimization flags.
My program uses signal.h to handle a SIGSEGV signal and then calls abort().
The program runs without problems for days but sometimes segfaults. This is when I get weird backtraces that I do not understand:
username#ubuntu:~/Desktop$ gdb -c core.28569 program-name
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=i386-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from program-name...done.
[New Thread 28569]
Core was generated by `program-name'.
Program terminated with signal 6, Aborted.
#0 0x00914410 in __kernel_vsyscall ()
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
Function "info_command" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
.gdbinit:8: Error in sourced command file:
Argument required (one or more breakpoint numbers).
(gdb) bt
#0 0x00914410 in __kernel_vsyscall ()
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x914411.
#1 0x0804d7f4 in __unified_syscall ()
#2 0xbf8966c0 in ?? ()
#3
#4 0x2054454e in ?? ()
#5 0x20524c43 in ?? ()
#6 0x2e352e33 in ?? ()
#7 0x32373033 in ?? ()
#8 0x2e203b39 in ?? ()
#9 0x2054454e in ?? ()
#10 0x20524c43 in ?? ()
#11 0x2e302e33 in ?? ()
#12 0x32373033 in ?? ()
#13 0x4d203b39 in ?? ()
#14 0x61696465 in ?? ()
#15 0x6e654320 in ?? ()
#16 0x20726574 in ?? ()
#17 0x36204350 in ?? ()
#18 0x203b302e in ?? ()
#19 0x54454e2e in ?? ()
#20 0x43302e34 in ?? ()
#21 0x00000029 in ?? ()
#22 0xbf8989a8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) bt full
#0 0x00914410 in __kernel_vsyscall ()
No symbol table info available.
#1 0x0804d7f4 in __unified_syscall ()
No symbol table info available.
#2 0xbf8966c0 in ?? ()
No symbol table info available.
#3
No symbol table info available.
#4 0x2054454e in ?? ()
No symbol table info available.
#5 0x20524c43 in ?? ()
No symbol table info available.
#6 0x2e352e33 in ?? ()
No symbol table info available.
#7 0x32373033 in ?? ()
No symbol table info available.
#8 0x2e203b39 in ?? ()
No symbol table info available.
#9 0x2054454e in ?? ()
No symbol table info available.
#10 0x20524c43 in ?? ()
No symbol table info available.
#11 0x2e302e33 in ?? ()
No symbol table info available.
#12 0x32373033 in ?? ()
No symbol table info available.
#13 0x4d203b39 in ?? ()
No symbol table info available.
#14 0x61696465 in ?? ()
No symbol table info available.
#15 0x6e654320 in ?? ()
No symbol table info available.
#16 0x20726574 in ?? ()
No symbol table info available.
#17 0x36204350 in ?? ()
No symbol table info available.
#18 0x203b302e in ?? ()
No symbol table info available.
#19 0x54454e2e in ?? ()
No symbol table info available.
#20 0x43302e34 in ?? ()
No symbol table info available.
#21 0x00000029 in ?? ()
No symbol table info available.
#22 0xbf8989a8 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) quit
It's a stack overrun.
#4 0x2054454e in ?? ()
That looks like text, " TEN" or "NET "
#5 0x20524c43 in ?? ()
" RLC" or "CLR "
And so on.
Treat the addresses as if they were text - see if you can identify where this text overwrites your stack.
Your stack trace is actually very easy to understand:
You got SIGSEGV somewhere,
Your signal handler did whatever it does, then called abort()
Which issued raise(2) system call, by calling __unified_syscall()
The reason you get no stack trace in GDB is that
__unified_syscall is implemented in assembly, and
does not use frame pointer, and
does not have proper cfi directives to describe how to unwind from it.
I would consider this a bug in dietlibc, quite easy to fix, actually. See if this (untested) patch fixes it for you:
--- dietlibc-0.31/i386/unified.S.orig 2011-03-13 10:16:23.000000000 -0700
+++ dietlibc-0.31/i386/unified.S 2011-03-13 10:21:32.000000000 -0700
## -31,8 +31,14 ## __unified_syscall:
movzbl %al, %eax
.L1:
push %edi
+ cfi_adjust_cfa_offset (4)
+ cfi_rel_offset (edi, 0)
push %esi
+ cfi_adjust_cfa_offset (4)
+ cfi_rel_offset (esi, 0)
push %ebx
+ cfi_adjust_cfa_offset (4)
+ cfi_rel_offset (ebx, 0)
movl %esp,%edi
/* we use movl instead of pop because otherwise a signal would
destroy the stack frame and crash the program, although it
## -61,8 +67,11 ## __unified_syscall:
#endif
.Lnoerror:
pop %ebx
+ cfi_adjust_cfa_offset (-4)
pop %esi
+ cfi_adjust_cfa_offset (-4)
pop %edi
+ cfi_adjust_cfa_offset (-4)
/* here we go and "reuse" the return for weak-void functions */
#include "dietuglyweaks.h"
If you can't rebuild dietlibc, or if the patch is incorrect, you may still be able to analyze the stack trace better. As far as I can tell, __unified_syscall does not touch %ebp. So you might be able to get a reasonable stack trace by doing this:
define xbt
set $xbp = (void **)$arg0
while 1
x/2a $xbp
set $xbp = (void **)$xbp[0]
end
end
xbt $ebp
Note: if the xbt works, it is likely to go into the weeds around the SIGSEGV signal frame (that frame does not use frame pointer either). This may result in complete garbage, or in a skipped frame or two (which would be exactly the frames where SIGSEGV happened).
So you really are much better off getting proper unwind descriptors into dietlibc.