Hello,
I'm about fixing this old BUG exiting VDR on every 1st recording start:
# gdb attach <pid of vdr>
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x9c801b40 (LWP 8182)] 0x08136f6a in cFrameDetector::Analyze(unsigned char const*, int) () (gdb) bt #0 0x08136f6a in cFrameDetector::Analyze(unsigned char const*, int) () #1 0x081295b2 in cRecorder::Action() () #2 0x08165e13 in cThread::StartThread(cThread*) () #3 0xb7693d97 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #4 0xb73addfe in clone () from /lib/i386-linux-gnu/libc.so.6 (gdb) bt full #0 0x08136f6a in cFrameDetector::Analyze(unsigned char const*, int) () No symbol table info available. #1 0x081295b2 in cRecorder::Action() () No symbol table info available. #2 0x08165e13 in cThread::StartThread(cThread*) () No symbol table info available. #3 0xb7693d97 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 No symbol table info available. #4 0xb73addfe in clone () from /lib/i386-linux-gnu/libc.so.6 No symbol table info available.
I've installed the vdr-dbg debian package to provide debugging symbols to vdr gdb bt full but there's no README included how to use it.
# dpkg -L vdr-dbg /. /etc /etc/init /etc/init/vdr-dbg.conf ?* /etc/init/vdr-exit-other.override ?* /usr /usr/lib /usr/lib/debug /usr/lib/debug/.build-id /usr/lib/debug/.build-id/10 /usr/lib/debug/.build-id/10/e8b576883246ca77ad6f40e2c26053ba2d357c.debug /usr/lib/debug/.build-id/86 /usr/lib/debug/.build-id/86/d9bba0c546ad5d7429259292b259103aabba03.debug /usr/lib/debug/.build-id/6d /usr/lib/debug/.build-id/6d/6631fca1b8d4962b2725add0c729fdeba6aa40.debug /usr/share /usr/share/doc /usr/share/doc/vdr-dbg /usr/share/doc/vdr-dbg/copyright /usr/share/doc/vdr-dbg/changelog.Debian.gz /usr/share/doc/vdr-dbg/changelog.gz /usr/bin /usr/bin/vdr-dbg
*Does this package interfere with my production vdr installation?
Can I just replace /usr/bin/vdr with /usr/bin/vdr-dbg in runvdr script?
There's only a gdb beginners guide in the wiki:
http://www.vdr-wiki.de/wiki/index.php/Gdb http://www.vdr-wiki.de/wiki/index.php?title=Spezial%3ASuche&search=vdr-d...
?
Y tom
Thu, Nov 14, 2024 at 01:37:42PM +0100, schorpp wrote:
Hello,
I'm about fixing this old BUG exiting VDR on every 1st recording start:
# gdb attach <pid of vdr>
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x9c801b40 (LWP 8182)] 0x08136f6a in cFrameDetector::Analyze(unsigned char const*, int) () (gdb) bt #0 0x08136f6a in cFrameDetector::Analyze(unsigned char const*, int) ()
On Debian and many other GNU/Linux distributions, executables are without debug symbols by default. The debug symbols are separately available in another repository, which you can add to a file in /etc/apt/sources.list.d:
deb http://deb.debian.org/debian-debug/ bookworm-debug main
(Replace bookworm with your Debian version of choice.)
After an apt-update, you should be able to execute
sudo apt install vdr-dbgsym
to get some files under /usr/lib/debug/.build-id/ that should match the BuildID that should be reported by the following command:
file /usr/bin/vdr
That said, sometimes it is possible to find the bug by executing simply the following commands in GDB:
disassemble 0x08136f6a info registers
If GDB complains that it does not know the function boundaries, you can try to start disassembly from a few bytes earlier:
x/32i 0x08136f50
Hopefully this will show the problem, and this is easy enough to match with the source code. If not, the debugging symbols for your vdr executable should help you to produce a fully resolved stack trace including the values of local variables (backtrace full).
I've installed the vdr-dbg debian package to provide debugging symbols
I can't find a package with that name at https://packages.debian.org.
Best regards,
Marko
Am 15.11.24 um 19:25 schrieb Marko Mäkelä:
Thu, Nov 14, 2024 at 01:37:42PM +0100, schorpp wrote:
Hello,
Hi,
I'm about fixing this old BUG exiting VDR on every 1st recording start:
# gdb attach <pid of vdr>
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x9c801b40 (LWP 8182)] 0x08136f6a in cFrameDetector::Analyze(unsigned char const*, int) () (gdb) bt #0 0x08136f6a in cFrameDetector::Analyze(unsigned char const*, int) ()
On Debian and many other GNU/Linux distributions, executables are without debug symbols by default. The debug symbols are separately available in another repository, which you can add to a file in /etc/apt/sources.list.d:
deb http://deb.debian.org/debian-debug/ bookworm-debug main
(Replace bookworm with your Debian version of choice.)
After an apt-update, you should be able to execute
sudo apt install vdr-dbgsym
to get some files under /usr/lib/debug/.build-id/ that should match the BuildID that should be reported by the following command:
file /usr/bin/vdr
That said, sometimes it is possible to find the bug by executing simply the following commands in GDB:
disassemble 0x08136f6a info registers
If GDB complains that it does not know the function boundaries, you can try to start disassembly from a few bytes earlier:
x/32i 0x08136f50
cool, thanks, i forgot so many things :-)
Hopefully this will show the problem, and this is easy enough to match with the source code. If not, the debugging symbols for your vdr executable should help you to produce a fully resolved stack trace including the values of local variables (backtrace full).
I've installed the vdr-dbg debian package to provide debugging symbols
I can't find a package with that name at https://packages.debian.org.
$ apt-cache policy vdr-dbg vdr-dbg: Installiert: 2.0.6-6yavdr1~woprr Installationskandidat: 2.0.6-6yavdr1 Versionstabelle: 2.0.6-6yavdr1 0 995 http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu/ precise/main i386 Packages *** 2.0.6-6yavdr1~woprr 0 100 /var/lib/dpkg/status 2.0.3-3 0 500 http://archive.debian.org/debian/ jessie/main i386 Packages 1.7.28-1 0 500 http://archive.debian.org/debian/ wheezy/main i386 Packages
$ diff -U3 /usr/sbin/runvdr.precise /usr/sbin/runvdr --- /usr/sbin/runvdr.precise 2014-07-20 02:47:00.000000000 +0200 +++ /usr/sbin/runvdr 2024-11-15 10:08:21.700827294 +0100 @@ -7,7 +7,7 @@ VDR_ENV="$VDR_ENV VDR_CHARSET_OVERRIDE=$VDR_CHARSET_OVERRIDE" fi
-VDRCMD="$VDR_ENV /usr/bin/vdr $*" +VDRCMD="$VDR_ENV /usr/bin/vdr-dbg $*"
did the trick
Attaching to process 29155 Reading symbols from /usr/bin/vdr...Reading symbols from /usr/lib/debug/.build-id/10/e8b576883246ca77ad6f40e2c26053ba2d357c.debug...done. done.
bt full / thread apply all bt #2 0x081330f4 in cRemote::Get (WaitMs=10, UnknownCode=0x0) at remote.c:194 MutexLock = {mutex = 0x822feb0, locked = true} #3 0x080f225b in cInterface::GetKey (this=0x9ee02c8, Wait=<optimized out>) at interface.c:41 No locals. #4 0x080aeda3 in main (argc=0, argv=<optimized out>) at vdr.c:1066 Now = 1731696012 Interact = <optimized out> key = <optimized out> PreviousChannelIndex = 0 LastChannelChanged = 1731695003 IsInfoMenu = false Menu = 0x0 LastChannel = 18 LastTimerChannel = 54 PreviousChannel = {18, 2} CurrentSkin = <optimized out> LastInteract = 1731696012 MaxLatencyTime = 6 InhibitEpgScan = false VideoDirectory = 0x38 <Address 0x38 out of bounds> ResourceDirectory = 0x8194440 "/usr/share/vdr" EpgDataFileName = <optimized out> AudioCommand = 0x0 CacheDirectory = 0x8194431 "/var/cache/vdr"
...
Strange is the the bug does no more occur using the vdr-dbg exe? Maybe some left over debug break point or C++ assertion...
Best regards,
Marko
y tom
Fri, Nov 15, 2024 at 07:43:35PM +0100, schorpp wrote:
bt full / thread apply all bt #2 0x081330f4 in cRemote::Get (WaitMs=10, UnknownCode=0x0) at remote.c:194 MutexLock = {mutex = 0x822feb0, locked = true} #3 0x080f225b in cInterface::GetKey (this=0x9ee02c8, Wait=<optimized out>) at interface.c:41 No locals. #4 0x080aeda3 in main (argc=0, argv=<optimized out>) at vdr.c:1066
Is this really the only thread? "thread apply all backtrace" should show the stack traces of all threads. There is also "info threads". This seems to be the main thread, waiting for input from the remote control.
Strange is the the bug does no more occur using the vdr-dbg exe?
Maybe the vdr-dbg has been built with different options, such as without some optimizations. It could affect the timing enough, if this is related to some race condition.
I think that you should ask the maintainer of that repository if the debug information for your normal "vdr" package are available somewhere. Alternatively, try to compile vdr yourself, slightly changing the build script so that the debug information will be included.
It is not that hard to compile VDR. Even my Raspberry Pi 2 can do it in a few minutes.
Marko
Am 19.11.24 um 08:21 schrieb Marko Mäkelä:
Fri, Nov 15, 2024 at 07:43:35PM +0100, schorpp wrote:
bt full / thread apply all bt #2 0x081330f4 in cRemote::Get (WaitMs=10, UnknownCode=0x0) at remote.c:194 MutexLock = {mutex = 0x822feb0, locked = true} #3 0x080f225b in cInterface::GetKey (this=0x9ee02c8, Wait=<optimized out>) at interface.c:41 No locals. #4 0x080aeda3 in main (argc=0, argv=<optimized out>) at vdr.c:1066
Is this really the only thread?
No, some break in to show that debug symbols are available now.
"thread apply all backtrace" should show the stack traces of all threads. There is also "info threads". This seems to be the main thread, waiting for input from the remote control.
I know, thanks.
Strange is the the bug does no more occur using the vdr-dbg exe?
Maybe the vdr-dbg has been built with different options, such as without some optimizations. It could affect the timing enough, if this is related to some race condition.
Maybe.
If gdb is attached to the vdr process the bug does not occur, if it is not attached the SIGFPE occours intermittently on first recording start, it does not occour on subsequent recording starts.
I'll set ulimit -c unlimit in runvdr script to get a core dump for gdb if available for SIGFPE.
I think that you should ask the maintainer of that repository if the debug information for your normal "vdr" package are available somewhere. Alternatively, try to compile vdr yourself, slightly changing the build script so that the debug information will be included.
It is not that hard to compile VDR. Even my Raspberry Pi 2 can do it in a few minutes.
*** 2.0.6-6yavdr1~woprr 0 100 /var/lib/dpkg/status
These are my installed self compiled vdr debug and release debian packages from source packages of
2.0.6-6yavdr1 0 995 http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu/ precise/main i386 Packages
Marko
y tom
Am 19.11.24 um 08:21 schrieb Marko Mäkelä:
Fri, Nov 15, 2024 at 07:43:35PM +0100, schorpp wrote:
bt full / thread apply all bt #2 0x081330f4 in cRemote::Get (WaitMs=10, UnknownCode=0x0) at remote.c:194 MutexLock = {mutex = 0x822feb0, locked = true} #3 0x080f225b in cInterface::GetKey (this=0x9ee02c8, Wait=<optimized out>) at interface.c:41 No locals. #4 0x080aeda3 in main (argc=0, argv=<optimized out>) at vdr.c:1066
Is this really the only thread?
No, some break in to show that debug symbols are available now.
"thread apply all backtrace" should show the stack traces of all threads. There is alsoagain "info threads". This seems to be the main thread, waiting for input from the remote control.
I know, thanks.
Strange is the the bug does no more occur using the vdr-dbg exe?
Maybe the vdr-dbg has been built with different options, such as without some optimizations. It could affect the timing enough, if this is related to some race condition.
Maybe.
If gdb is attached to the vdr process the bug does not occur, if it is not attached the SIGFPE occours intermittently on first recording start, it does not occour on subsequent recording starts.
I'll set ulimit -c unlimit in runvdr script to get a core dump for gdb if available for SIGFPE.
I've upgraded the kernel to latest longterm stable 4.19.324 kernel which catches the bug:
$ grep trap /var/log/syslog Nov 22 16:25:17 vdr2 kernel: [ 272.072890] traps: recording[5468] trap divide error ip:8136f6a sp:9f9da200 error:0 in vdr[8048000+186000]
Now I've attached gdb and wait if it occours again and to get ab full bt.
y tom
I think that you should ask the maintainer of that repository if the debug information for your normal "vdr" package are available somewhere. Alternatively, try to compile vdr yourself, slightly changing the build script so that the debug information will be included.
It is not that hard to compile VDR. Even my Raspberry Pi 2 can do it in a few minutes.
*** 2.0.6-6yavdr1~woprr 0 100 /var/lib/dpkg/status
These are my installed self compiled vdr debug and release debian packages from source packages of
2.0.6-6yavdr1 0 995 http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu/ precise/main i386 PackagesMarkoy tom
Am 19.11.24 um 08:21 schrieb Marko Mäkelä:
Fri, Nov 15, 2024 at 07:43:35PM +0100, schorpp wrote:
bt full / thread apply all bt #2 0x081330f4 in cRemote::Get (WaitMs=10, UnknownCode=0x0) at remote.c:194 MutexLock = {mutex = 0x822feb0, locked = true} #3 0x080f225b in cInterface::GetKey (this=0x9ee02c8, Wait=<optimized out>) at interface.c:41 No locals. #4 0x080aeda3 in main (argc=0, argv=<optimized out>) at vdr.c:1066
Is this really the only thread?
No, some break in to show that debug symbols are available now.
"thread apply all backtrace" should show the stack traces of all threads. There is alsoagain "info threads". This seems to be the main thread, waiting for input from the remote control.
I know, thanks.
Strange is the the bug does no more occur using the vdr-dbg exe?
Maybe the vdr-dbg has been built with different options, such as without some optimizations. It could affect the timing enough, if this is related to some race condition.
Maybe.
If gdb is attached to the vdr process the bug does not occur, if it is not attached the SIGFPE occours intermittently on first recording start, it does not occour on subsequent recording starts.
I'll set ulimit -c unlimit in runvdr script to get a core dump for gdb if available for SIGFPE.
I've upgraded the kernel to latest longterm stable 4.19.324 kernel which catches the bug:
$ grep trap /var/log/syslog Nov 22 16:25:17 vdr2 kernel: [ 272.072890] traps: recording[5468] trap divide error ip:8136f6a sp:9f9da200 error:0 in vdr[8048000+186000]
Now I've attached gdb and wait if it occours again and to get ab full bt.
HA! I've got this bitch of intermittent bug finally:
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0xad0ffb40 (LWP 27522)] 0x08136f6a in cFrameDetector::Analyze (this=0x9ade480, Data=<optimized out>, Length=296852) at remux.c:1567 1567 uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset()); (gdb) bt #0 0x08136f6a in cFrameDetector::Analyze (this=0x9ade480, Data=<optimized out>, Length=296852) at remux.c:1567 #1 0x081295b2 in cRecorder::Action (this=0x9c41290) at recorder.c:127 #2 0x08165e13 in cThread::StartThread (Thread=0x9c413b4) at thread.c:262 #3 0xb7f1fd97 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #4 0xb7c39dfe in clone () from /lib/i386-linux-gnu/libc.so.6 (gdb) (gdb) bt full #0 0x08136f6a in cFrameDetector::Analyze (this=0x9ade480, Data=<optimized out>, Length=296852) at remux.c:1567 Delta = <optimized out> Pid = <optimized out> Handled = <optimized out> Processed = <optimized out> #1 0x081295b2 in cRecorder::Action (this=0x9c41290) at recorder.c:127 Count = <optimized out> r = 296852 b = 0x8fd38368 "G^\025\064\ap\177G\025\341~\274" t = {begin = 102034543} InfoWritten = <optimized out> FirstIframeSeen = <optimized out> #2 0x08165e13 in cThread::StartThread (Thread=0x9c413b4) at thread.c:262 No locals. #3 0xb7f1fd97 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 No symbol table info available. #4 0xb7c39dfe in clone () from /lib/i386-linux-gnu/libc.so.6 No symbol table info available.
But there's no data available for gdb about (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset())
Aussume it is a divide by zero exception?
But in which case can this be zero?
y tom
Sun, Dec 01, 2024 at 02:18:02PM +0100, schorpp wrote:
HA! I've got this bitch of intermittent bug finally:
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0xad0ffb40 (LWP 27522)] 0x08136f6a in cFrameDetector::Analyze (this=0x9ade480, Data=<optimized out>, Length=296852) at remux.c:1567 1567 uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
It would have been useful to include the disassembly of the function. Maybe alos the output fo the following, if the values are known to the debugger:
print ptsValues[0] print framesPerPayloadUnit print parser->iFrameTemporalReferenceOffset
I was curious about this. I am able to reproduce SIGFPE on both x86-64 and i386 when compiling the following C program without optimization:
#include <stdint.h> #include <stdio.h> #include <inttypes.h> int main() { int a = 0, b = -1; uint32_t pts = 1U << 31; int32_t delta = ((int32_t)pts) / (a + b); printf("%" PRIi32 "\n", delta); return 0; }
Initially I had "uint32_t delta" and no type cast, and PRIu32, to exactly match the data types that are involved in VDR. That variant would produce the incorrect result 0. This of course is a bad approximation for the code in VDR, because above it is possible to perform all the arithmetics at compilation time. In VDR, the values would be determined at runtime.
Curiously, if I compile the above program with GCC 14.2.0 -O2, then it will return the incorrect result -2147483648 instead of an approximation like 2147483647 (which would be one less than the correct result, which cannot be represented in int32_t). If I look at the disassembly, the compiler would have performed an incorrect constant folding for "delta".
If I compile the program with -fsanitize=undefined, it will flag an error:
runtime error: division of -2147483648 by -1 cannot be represented in type 'int'
For the non-optimized case, for both i386 and x86-64, I see that the SIGFPE is being raised by an idiv instruction that is preceded by ctld a.k.a. cdq: https://www.felixcloutier.com/x86/cwd:cdq:cqo
Aussume it is a divide by zero exception?
I don't know if your case involves the idiv instruction, but https://www.felixcloutier.com/x86/idiv mentions that #DE may be raised both on a division by zero and on overflow.
Can you post the output of "disassemble" and "info registers" for the innermost stack frame?
Marko
Am 01.12.24 um 16:56 schrieb Marko Mäkelä:
Sun, Dec 01, 2024 at 02:18:02PM +0100, schorpp wrote:
HA! I've got this bitch of intermittent bug finally:
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0xad0ffb40 (LWP 27522)] 0x08136f6a in cFrameDetector::Analyze (this=0x9ade480, Data=<optimized out>, Length=296852) at remux.c:1567 1567 uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
It would have been useful to include the disassembly of the function. Maybe alos the output fo the following, if the values are known to the debugger:
print ptsValues[0] print framesPerPayloadUnit print parser->iFrameTemporalReferenceOffset
AAAh sorry I forgot so many things, the last time I used assembler was tracing a kernel driver bug years ago.
Now we must wait for days again for the still not identified use case the exception is risen for again :/
I was curious about this. I am able to reproduce SIGFPE on both x86-64 and i386 when compiling the following C program without optimization:
#include <stdint.h> #include <stdio.h> #include <inttypes.h> int main() { int a = 0, b = -1; uint32_t pts = 1U << 31; int32_t delta = ((int32_t)pts) / (a + b); printf("%" PRIi32 "\n", delta); return 0; }
Initially I had "uint32_t delta" and no type cast, and PRIu32, to exactly match the data types that are involved in VDR. That variant would produce the incorrect result 0. This of course is a bad approximation for the code in VDR, because above it is possible to perform all the arithmetics at compilation time. In VDR, the values would be determined at runtime.
yes.
Can we just catch and handle this C++ exception somehow?
Curiously, if I compile the above program with GCC 14.2.0 -O2, then it will return the incorrect result -2147483648 instead of an approximation like 2147483647 (which would be one less than the correct result, which cannot be represented in int32_t). If I look at the disassembly, the compiler would have performed an incorrect constant folding for "delta".
If I compile the program with -fsanitize=undefined, it will flag an error:
runtime error: division of -2147483648 by -1 cannot be represented in type 'int'
For the non-optimized case, for both i386 and x86-64, I see that the SIGFPE is being raised by an idiv instruction that is preceded by ctld a.k.a. cdq: https://www.felixcloutier.com/x86/cwd:cdq:cqo
Interesting :)
Is this a case for the gcc-dev mailinglist? Then CC them if on list.
Aussume it is a divide by zero exception?
I don't know if your case involves the idiv instruction, but https:// www.felixcloutier.com/x86/idiv mentions that #DE may be raised both on a division by zero and on overflow.
Can you post the output of "disassemble" and "info registers" for the innermost stack frame?
yes, if it occours again
Marko
y tom
Sun, Dec 01, 2024 at 02:18:02PM +0100, schorpp wrote:>HA! I've got this bitch of intermittent bug finally:
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0xad0ffb40 (LWP 27522)] 0x08136f6a in cFrameDetector::Analyze (this=0x9ade480, Data=<optimized out>, Length=296852) at remux.c:1567 1567 uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
It would have been useful to include the disassembly of the function. Maybe alos the output fo the following, if the values are known to the debugger:
print ptsValues[0] print framesPerPayloadUnit print parser->iFrameTemporalReferenceOffset
(gdb) print ptsValues[0] $1 = 3600 (gdb) print framesPerPayloadUnit $2 = 1 (gdb) print parser->iFrameTemporalReferenceOffset $3 = -1
I was curious about this. I am able to reproduce SIGFPE on both x86-64 and i386 when compiling the following C program without optimization:
#include <stdint.h> #include <stdio.h> #include <inttypes.h> int main() { int a = 0, b = -1; uint32_t pts = 1U << 31; int32_t delta = ((int32_t)pts) / (a + b); printf("%" PRIi32 "\n", delta); return 0; }
Initially I had "uint32_t delta" and no type cast, and PRIu32, to exactly match the data types that are involved in VDR. That variant would produce the incorrect result 0. This of course is a bad approximation for the code in VDR, because above it is possible to perform all the arithmetics at compilation time. In VDR, the values would be determined at runtime.
Curiously, if I compile the above program with GCC 14.2.0 -O2, then it will return the incorrect result -2147483648 instead of an approximation like 2147483647 (which would be one less than the correct result, which cannot be represented in int32_t). If I look at the disassembly, the compiler would have performed an incorrect constant folding for "delta".
If I compile the program with -fsanitize=undefined, it will flag an error:
runtime error: division of -2147483648 by -1 cannot be represented in type 'int'
For the non-optimized case, for both i386 and x86-64, I see that the SIGFPE is being raised by an idiv instruction that is preceded by ctld a.k.a. cdq: https://www.felixcloutier.com/x86/cwd:cdq:cqo
Aussume it is a divide by zero exception?
I don't know if your case involves the idiv instruction, but https://www.felixcloutier.com/x86/idiv mentions that #DE may be raised both on a division by zero and on overflow.
Can you post the output of "disassemble" and "info registers" for the innermost stack frame?
(gdb) info registers eax 0xe10 3600 ecx 0x0 0 edx 0x0 0 ebx 0x81d6ff4 136146932 esp 0x966ff200 0x966ff200 ebp 0x178 0x178 esi 0x981bff0 159498224 edi 0x94391164 -1808199324 eip 0x8136f6a 0x8136f6a <cFrameDetector::Analyze(unsigned char const*, int)+1050> eflags 0x210257 [ CF PF AF ZF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51
(gdb) disassemble Dump of assembler code for function cFrameDetector::Analyze(unsigned char const*, int): 0x08136b50 <+0>: push %ebp 0x08136b51 <+1>: push %edi 0x08136b52 <+2>: push %esi 0x08136b53 <+3>: push %ebx 0x08136b54 <+4>: sub $0x6c,%esp 0x08136b57 <+7>: mov 0x80(%esp),%ecx 0x08136b5e <+14>: call 0x80b14b0 <__x86.get_pc_thunk.bx> 0x08136b63 <+19>: add $0xa0491,%ebx 0x08136b69 <+25>: mov 0x84(%esp),%edi 0x08136b70 <+32>: mov 0x288(%ecx),%eax 0x08136b76 <+38>: test %eax,%eax 0x08136b78 <+40>: je 0x8136de0 <cFrameDetector::Analyze(unsigned char const*, int)+656> 0x08136b7e <+46>: cmpl $0x496f,0x88(%esp) 0x08136b89 <+57>: movb $0x0,0xa(%ecx) 0x08136b8d <+61>: movb $0x0,0x9(%ecx) 0x08136b91 <+65>: jle 0x8136de0 <cFrameDetector::Analyze(unsigned char const*, int)+656> 0x08136b97 <+71>: cmpb $0x47,(%edi) 0x08136b9a <+74>: movl $0x0,0x3c(%esp) 0x08136ba2 <+82>: jne 0x8136c24 <cFrameDetector::Analyze(unsigned char const*, int)+212> 0x08136ba8 <+88>: movzbl 0x3(%edi),%eax 0x08136bac <+92>: test $0x10,%al 0x08136bae <+94>: je 0x8136bf0 <cFrameDetector::Analyze(unsigned char const*, int)+160> 0x08136bb0 <+96>: test $0xc0,%al 0x08136bb2 <+98>: jne 0x8136bf0 <cFrameDetector::Analyze(unsigned char const*, int)+160> 0x08136bb4 <+100>: movzbl 0x1(%edi),%edx 0x08136bb8 <+104>: movzbl 0x2(%edi),%ecx 0x08136bbc <+108>: mov 0x80(%esp),%esi 0x08136bc3 <+115>: mov %edx,%eax 0x08136bc5 <+117>: and $0x1f,%eax 0x08136bc8 <+120>: shl $0x8,%eax 0x08136bcb <+123>: add %ecx,%eax 0x08136bcd <+125>: mov (%esi),%ecx 0x08136bcf <+127>: cmp %eax,%ecx 0x08136bd1 <+129>: je 0x8136c80 <cFrameDetector::Analyze(unsigned char const*, int)+304> 0x08136bd7 <+135>: test %eax,%eax 0x08136bd9 <+137>: jne 0x8136bf0 <cFrameDetector::Analyze(unsigned char const*, int)+160> 0x08136bdb <+139>: mov 0x80(%esp),%esi 0x08136be2 <+146>: cmpb $0x0,0x8(%esi) 0x08136be6 <+150>: jne 0x8136cc0 <cFrameDetector::Analyze(unsigned char const*, int)+368> 0x08136bec <+156>: lea 0x0(%esi,%eiz,1),%esi ---Type <return> to continue, or q <return> to quit--- 0x08136bf0 <+160>: xor %eax,%eax 0x08136bf2 <+162>: movl $0xbc,0x54(%esp) 0x08136bfa <+170>: mov $0xbc,%ebp 0x08136bff <+175>: add 0x54(%esp),%edi 0x08136c03 <+179>: sub %ebp,0x88(%esp) 0x08136c0a <+186>: add %ebp,0x3c(%esp) 0x08136c0e <+190>: test %al,%al 0x08136c10 <+192>: jne 0x8136c70 <cFrameDetector::Analyze(unsigned char const*, int)+288> 0x08136c12 <+194>: cmpl $0x496f,0x88(%esp) 0x08136c1d <+205>: jle 0x8136c70 <cFrameDetector::Analyze(unsigned char const*, int)+288> 0x08136c1f <+207>: cmpb $0x47,(%edi) 0x08136c22 <+210>: je 0x8136ba8 <cFrameDetector::Analyze(unsigned char const*, int)+88> 0x08136c24 <+212>: mov 0x88(%esp),%eax 0x08136c2b <+219>: mov $0x1,%esi 0x08136c30 <+224>: cmpb $0x47,(%edi,%esi,1) 0x08136c34 <+228>: je 0x8136db8 <cFrameDetector::Analyze(unsigned char const*, int)+616> 0x08136c3a <+234>: add $0x1,%esi 0x08136c3d <+237>: cmp %esi,%eax 0x08136c3f <+239>: jg 0x8136c30 <cFrameDetector::Analyze(unsigned char const*, int)+224> 0x08136c41 <+241>: mov -0x5ec(%ebx),%eax 0x08136c47 <+247>: mov (%eax),%ebp 0x08136c49 <+249>: test %ebp,%ebp 0x08136c4b <+251>: jle 0x8136c67 <cFrameDetector::Analyze(unsigned char const*, int)+279> 0x08136c4d <+253>: lea -0x5165c(%ebx),%eax 0x08136c53 <+259>: mov %esi,0x8(%esp) 0x08136c57 <+263>: mov %eax,0x4(%esp) 0x08136c5b <+267>: movl $0x3,(%esp) 0x08136c62 <+274>: call 0x816a580 <syslog_with_tid(int, char const*, ...)> 0x08136c67 <+279>: add %esi,0x3c(%esp) 0x08136c6b <+283>: nop 0x08136c6c <+284>: lea 0x0(%esi,%eiz,1),%esi 0x08136c70 <+288>: mov 0x3c(%esp),%eax 0x08136c74 <+292>: add $0x6c,%esp 0x08136c77 <+295>: pop %ebx 0x08136c78 <+296>: pop %esi 0x08136c79 <+297>: pop %edi 0x08136c7a <+298>: pop %ebp 0x08136c7b <+299>: ret 0x08136c7c <+300>: lea 0x0(%esi,%eiz,1),%esi 0x08136c80 <+304>: mov 0x3c(%esp),%eax 0x08136c84 <+308>: test %eax,%eax ---Type <return> to continue, or q <return> to quit--- ---Type <return> to continue, or q <return> to quit--- 0x08136c86 <+310>: jne 0x8136c70 <cFrameDetector::Analyze(unsigned char const*, int)+288> 0x08136c88 <+312>: and $0x40,%edx 0x08136c8b <+315>: mov 0x80(%esp),%esi 0x08136c92 <+322>: jne 0x8136cd0 <cFrameDetector::Analyze(unsigned char const*, int)+384> 0x08136c94 <+324>: cmpb $0x0,0x284(%esi) 0x08136c9b <+331>: jne 0x8136ce4 <cFrameDetector::Analyze(unsigned char const*, int)+404> 0x08136c9d <+333>: movl $0xbc,0x54(%esp) 0x08136ca5 <+341>: mov $0xbc,%ebp 0x08136caa <+346>: mov 0x80(%esp),%ecx 0x08136cb1 <+353>: movzbl 0x9(%ecx),%eax 0x08136cb5 <+357>: jmp 0x8136bff <cFrameDetector::Analyze(unsigned char const*, int)+175> 0x08136cba <+362>: lea 0x0(%esi),%esi 0x08136cc0 <+368>: mov 0x3c(%esp),%edx 0x08136cc4 <+372>: test %edx,%edx 0x08136cc6 <+374>: je 0x8136bf2 <cFrameDetector::Analyze(unsigned char const*, int)+162> 0x08136ccc <+380>: jmp 0x8136c70 <cFrameDetector::Analyze(unsigned char const*, int)+288> 0x08136cce <+382>: xchg %ax,%ax 0x08136cd0 <+384>: movb $0x1,0x284(%esi) 0x08136cd7 <+391>: testb $0x40,0x1(%edi) 0x08136cdb <+395>: jne 0x8136d58 <cFrameDetector::Analyze(unsigned char const*, int)+520> 0x08136cdd <+397>: mov 0x80(%esp),%esi 0x08136ce4 <+404>: mov 0x288(%esi),%eax 0x08136cea <+410>: mov (%eax),%edx 0x08136cec <+412>: mov %ecx,0xc(%esp) 0x08136cf0 <+416>: mov 0x88(%esp),%ecx 0x08136cf7 <+423>: mov %edi,0x4(%esp) 0x08136cfb <+427>: mov %eax,(%esp) 0x08136cfe <+430>: mov %ecx,0x8(%esp) 0x08136d02 <+434>: call *0x8(%edx) 0x08136d05 <+437>: test %eax,%eax 0x08136d07 <+439>: jle 0x8136df8 <cFrameDetector::Analyze(unsigned char const*, int)+680> 0x08136d0d <+445>: mov 0x80(%esp),%esi 0x08136d14 <+452>: mov 0x288(%esi),%edx 0x08136d1a <+458>: cmpb $0x0,0x5(%edx) 0x08136d1e <+462>: jne 0x8136d78 <cFrameDetector::Analyze(unsigned char const*, int)+552> 0x08136d20 <+464>: movzbl 0x1(%edi),%edx 0x08136d24 <+468>: mov %eax,%ebp 0x08136d26 <+470>: mov %eax,0x54(%esp) 0x08136d2a <+474>: and $0x40,%edx 0x08136d2d <+477>: test %dl,%dl 0x08136d2f <+479>: je 0x8136caa <cFrameDetector::Analyze(unsigned char const*, int)+346> ---Type <return> to continue, or q <return> to quit--- ---Type <return> to continue, or q <return> to quit--- 0x08136d35 <+485>: mov 0x80(%esp),%esi 0x08136d3c <+492>: fldl 0x274(%esi) 0x08136d42 <+498>: fldz 0x08136d44 <+500>: fucompp 0x08136d46 <+502>: fnstsw %ax 0x08136d48 <+504>: sahf 0x08136d49 <+505>: jae 0x8136e18 <cFrameDetector::Analyze(unsigned char const*, int)+712> 0x08136d4f <+511>: movzbl 0x9(%esi),%eax 0x08136d53 <+515>: jmp 0x8136bff <cFrameDetector::Analyze(unsigned char const*, int)+175> 0x08136d58 <+520>: mov 0x280(%esi),%ebp 0x08136d5e <+526>: test %ebp,%ebp 0x08136d60 <+528>: jne 0x8136ce4 <cFrameDetector::Analyze(unsigned char const*, int)+404> 0x08136d62 <+530>: mov 0x27c(%esi),%eax 0x08136d68 <+536>: mov %eax,0x280(%esi) 0x08136d6e <+542>: jmp 0x8136cdd <cFrameDetector::Analyze(unsigned char const*, int)+397> 0x08136d73 <+547>: nop 0x08136d74 <+548>: lea 0x0(%esi,%eiz,1),%esi 0x08136d78 <+552>: movzbl 0x6(%edx),%edx 0x08136d7c <+556>: cmpb $0x0,0x8(%esi) 0x08136d80 <+560>: movb $0x1,0x9(%esi) 0x08136d84 <+564>: mov %dl,0xa(%esi) 0x08136d87 <+567>: je 0x8136fe0 <cFrameDetector::Analyze(unsigned char const*, int)+1168> 0x08136d8d <+573>: cmpl $0x1,0x280(%esi) 0x08136d94 <+580>: jg 0x8136d20 <cFrameDetector::Analyze(unsigned char const*, int)+464> 0x08136d96 <+582>: mov 0x80(%esp),%esi 0x08136d9d <+589>: mov %eax,%ebp 0x08136d9f <+591>: mov %eax,0x54(%esp) 0x08136da3 <+595>: movb $0x0,0x284(%esi) 0x08136daa <+602>: movzbl 0x1(%edi),%edx 0x08136dae <+606>: and $0x40,%edx 0x08136db1 <+609>: jmp 0x8136d2d <cFrameDetector::Analyze(unsigned char const*, int)+477> 0x08136db6 <+614>: xchg %ax,%ax 0x08136db8 <+616>: mov %eax,%edx 0x08136dba <+618>: sub %esi,%edx 0x08136dbc <+620>: cmp $0xbc,%edx 0x08136dc2 <+626>: jle 0x8136c41 <cFrameDetector::Analyze(unsigned char const*, int)+241> 0x08136dc8 <+632>: cmpb $0x47,0xbc(%edi,%esi,1) 0x08136dd0 <+640>: jne 0x8136c3a <cFrameDetector::Analyze(unsigned char const*, int)+234> 0x08136dd6 <+646>: jmp 0x8136c41 <cFrameDetector::Analyze(unsigned char const*, int)+241> 0x08136ddb <+651>: nop 0x08136ddc <+652>: lea 0x0(%esi,%eiz,1),%esi ---Type <return> to continue, or q <return> to quit--- 0x08136de0 <+656>: movl $0x0,0x3c(%esp) 0x08136de8 <+664>: mov 0x3c(%esp),%eax 0x08136dec <+668>: add $0x6c,%esp 0x08136def <+671>: pop %ebx 0x08136df0 <+672>: pop %esi 0x08136df1 <+673>: pop %edi 0x08136df2 <+674>: pop %ebp 0x08136df3 <+675>: ret 0x08136df4 <+676>: lea 0x0(%esi,%eiz,1),%esi 0x08136df8 <+680>: movzbl 0x1(%edi),%edx 0x08136dfc <+684>: mov $0xbc,%ebp 0x08136e01 <+689>: movl $0xbc,0x54(%esp) 0x08136e09 <+697>: and $0x40,%edx 0x08136e0c <+700>: jmp 0x8136d2d <cFrameDetector::Analyze(unsigned char const*, int)+477> 0x08136e11 <+705>: lea 0x0(%esi,%eiz,1),%esi 0x08136e18 <+712>: mov 0x264(%esi),%ecx 0x08136e1e <+718>: cmp $0x1,%ecx 0x08136e21 <+721>: mov %ecx,0x50(%esp) 0x08136e25 <+725>: jle 0x8137016 <cFrameDetector::Analyze(unsigned char const*, int)+1222> 0x08136e2b <+731>: cmp $0x95,%ecx 0x08136e31 <+737>: mov 0x80(%esp),%esi 0x08136e38 <+744>: jg 0x8136ffb <cFrameDetector::Analyze(unsigned char const*, int)+1195> 0x08136e3e <+750>: cmpl $0x1,0x26c(%esi) 0x08136e45 <+757>: jle 0x8137016 <cFrameDetector::Analyze(unsigned char const*, int)+1222> 0x08136e4b <+763>: mov 0x80(%esp),%ecx 0x08136e52 <+770>: lea -0xa3534(%ebx),%esi 0x08136e58 <+776>: mov 0x50(%esp),%eax 0x08136e5c <+780>: mov %esi,0xc(%esp) 0x08136e60 <+784>: movl $0x4,0x8(%esp) 0x08136e68 <+792>: add $0xc,%ecx 0x08136e6b <+795>: mov %eax,0x4(%esp) 0x08136e6f <+799>: mov %ecx,(%esp) 0x08136e72 <+802>: mov %ecx,0x44(%esp) 0x08136e76 <+806>: mov %esi,0x4c(%esp) 0x08136e7a <+810>: call 0x80a9400 qsort@plt 0x08136e7f <+815>: mov 0x80(%esp),%ecx 0x08136e86 <+822>: mov 0x264(%ecx),%eax 0x08136e8c <+828>: lea -0x1(%eax),%esi 0x08136e8f <+831>: test %esi,%esi 0x08136e91 <+833>: mov %esi,0x40(%esp) 0x08136e95 <+837>: mov %esi,0x264(%ecx) ---Type <return> to continue, or q <return> to quit--- 0x08136e9b <+843>: jle 0x8136f29 <cFrameDetector::Analyze(unsigned char const*, int)+985> 0x08136ea1 <+849>: cmp $0x3,%eax 0x08136ea4 <+852>: jle 0x8137139 <cFrameDetector::Analyze(unsigned char const*, int)+1513> 0x08136eaa <+858>: mov 0x80(%esp),%esi 0x08136eb1 <+865>: sub $0x4,%eax 0x08136eb4 <+868>: shr %eax 0x08136eb6 <+870>: mov %ebp,0x50(%esp) 0x08136eba <+874>: mov %edi,0x48(%esp) 0x08136ebe <+878>: mov %esi,%edx 0x08136ec0 <+880>: mov 0xc(%esi),%ecx 0x08136ec3 <+883>: lea 0x2(%eax,%eax,1),%esi 0x08136ec7 <+887>: add $0x10,%edx 0x08136eca <+890>: xor %eax,%eax 0x08136ecc <+892>: mov %esi,%ebp 0x08136ece <+894>: xchg %ax,%ax 0x08136ed0 <+896>: mov (%edx),%esi 0x08136ed2 <+898>: add $0x2,%eax 0x08136ed5 <+901>: mov %esi,%edi 0x08136ed7 <+903>: sub %ecx,%edi 0x08136ed9 <+905>: mov 0x4(%edx),%ecx 0x08136edc <+908>: mov %edi,-0x4(%edx) 0x08136edf <+911>: mov %ecx,%edi 0x08136ee1 <+913>: sub %esi,%edi 0x08136ee3 <+915>: mov %edi,(%edx) 0x08136ee5 <+917>: add $0x8,%edx 0x08136ee8 <+920>: cmp %ebp,%eax 0x08136eea <+922>: jne 0x8136ed0 <cFrameDetector::Analyze(unsigned char const*, int)+896> 0x08136eec <+924>: mov 0x50(%esp),%ebp 0x08136ef0 <+928>: mov 0x48(%esp),%edi 0x08136ef4 <+932>: mov 0x80(%esp),%ecx 0x08136efb <+939>: mov %ebp,0x48(%esp) 0x08136eff <+943>: mov 0x54(%esp),%esi 0x08136f03 <+947>: mov 0x40(%esp),%ebp 0x08136f07 <+951>: lea 0xc(%ecx,%eax,4),%edx 0x08136f0b <+955>: nop 0x08136f0c <+956>: lea 0x0(%esi,%eiz,1),%esi 0x08136f10 <+960>: mov 0x4(%edx),%ecx 0x08136f13 <+963>: add $0x1,%eax 0x08136f16 <+966>: sub (%edx),%ecx 0x08136f18 <+968>: mov %ecx,(%edx) 0x08136f1a <+970>: add $0x4,%edx ---Type <return> to continue, or q <return> to quit--- 0x08136f1d <+973>: cmp %eax,%ebp 0x08136f1f <+975>: jg 0x8136f10 <cFrameDetector::Analyze(unsigned char const*, int)+960> 0x08136f21 <+977>: mov 0x48(%esp),%ebp 0x08136f25 <+981>: mov %esi,0x54(%esp) 0x08136f29 <+985>: mov 0x4c(%esp),%eax 0x08136f2d <+989>: mov 0x40(%esp),%edx 0x08136f31 <+993>: mov 0x44(%esp),%ecx 0x08136f35 <+997>: movl $0x4,0x8(%esp) 0x08136f3d <+1005>: mov %eax,0xc(%esp) 0x08136f41 <+1009>: mov %edx,0x4(%esp) 0x08136f45 <+1013>: mov %ecx,(%esp) 0x08136f48 <+1016>: call 0x80a9400 qsort@plt 0x08136f4d <+1021>: mov 0x80(%esp),%ecx 0x08136f54 <+1028>: xor %edx,%edx 0x08136f56 <+1030>: mov 0x288(%ecx),%esi 0x08136f5c <+1036>: mov %ecx,%eax 0x08136f5e <+1038>: mov 0xc(%eax),%eax 0x08136f61 <+1041>: mov 0x280(%ecx),%ecx 0x08136f67 <+1047>: add 0x8(%esi),%ecx
=> 0x08136f6a <+1050>: div %ecx <---------------------------------------------------------------
0x08136f6c <+1052>: mov %eax,%ecx 0x08136f6e <+1054>: mov 0x80(%esp),%eax 0x08136f75 <+1061>: cmpb $0x0,0x270(%eax) 0x08136f7c <+1068>: je 0x813707b <cFrameDetector::Analyze(unsigned char const*, int)+1323> 0x08136f82 <+1074>: lea -0xe10(%ecx),%eax 0x08136f88 <+1080>: cmp $0xffffffff,%eax 0x08136f8b <+1083>: jl 0x8136f96 <cFrameDetector::Analyze(unsigned char const*, int)+1094> 0x08136f8d <+1085>: cmp $0x1,%eax 0x08136f90 <+1088>: jle 0x8137121 <cFrameDetector::Analyze(unsigned char const*, int)+1489> 0x08136f96 <+1094>: mov $0x574b4629,%edx 0x08136f9b <+1099>: mov %ecx,%eax 0x08136f9d <+1101>: mul %edx 0x08136f9f <+1103>: shr $0xa,%edx 0x08136fa2 <+1106>: imul $0xbbb,%edx,%edx 0x08136fa8 <+1112>: cmp %edx,%ecx 0x08136faa <+1114>: jne 0x81370a1 <cFrameDetector::Analyze(unsigned char const*, int)+1361> 0x08136fb0 <+1120>: mov 0x80(%esp),%ecx 0x08136fb7 <+1127>: fldl -0x4a05c(%ebx) 0x08136fbd <+1133>: fstpl 0x274(%ecx) 0x08136fc3 <+1139>: jmp 0x8136fc7 <cFrameDetector::Analyze(unsigned char const*, int)+1143> 0x08136fc5 <+1141>: fstp %st(0) ---Type <return> to continue, or q <return> to quit--- 0x08136fc7 <+1143>: mov 0x80(%esp),%ecx 0x08136fce <+1150>: movb $0x1,0x8(%ecx) 0x08136fd2 <+1154>: movb $0x0,0x4(%esi) 0x08136fd6 <+1158>: movzbl 0x9(%ecx),%eax 0x08136fda <+1162>: jmp 0x8136bff <cFrameDetector::Analyze(unsigned char const*, int)+175> 0x08136fdf <+1167>: nop 0x08136fe0 <+1168>: addl $0x1,0x27c(%esi) 0x08136fe7 <+1175>: test %dl,%dl 0x08136fe9 <+1177>: je 0x8136d20 <cFrameDetector::Analyze(unsigned char const*, int)+464> 0x08136fef <+1183>: addl $0x1,0x26c(%esi) 0x08136ff6 <+1190>: jmp 0x8136d20 <cFrameDetector::Analyze(unsigned char const*, int)+464> 0x08136ffb <+1195>: mov 0x26c(%esi),%eax 0x08137001 <+1201>: cmp $0x1,%eax 0x08137004 <+1204>: jg 0x8136e4b <cFrameDetector::Analyze(unsigned char const*, int)+763> 0x0813700a <+1210>: mov 0x80(%esp),%esi 0x08137011 <+1217>: jmp 0x8136d4f <cFrameDetector::Analyze(unsigned char const*, int)+511> 0x08137016 <+1222>: mov 0x80(%esp),%ecx 0x0813701d <+1229>: movzbl 0x9(%ecx),%eax 0x08137021 <+1233>: test %al,%al 0x08137023 <+1235>: je 0x8137061 <cFrameDetector::Analyze(unsigned char const*, int)+1297> 0x08137025 <+1237>: testb $0x20,0x3(%edi) 0x08137029 <+1241>: mov $0x4,%ecx 0x0813702e <+1246>: je 0x8137044 <cFrameDetector::Analyze(unsigned char const*, int)+1268> 0x08137030 <+1248>: movzbl 0x4(%edi),%edx 0x08137034 <+1252>: lea 0x5(%edx),%ecx 0x08137037 <+1255>: cmp $0xbc,%ecx 0x0813703d <+1261>: jle 0x8137044 <cFrameDetector::Analyze(unsigned char const*, int)+1268> 0x0813703f <+1263>: mov $0xbc,%ecx 0x08137044 <+1268>: mov 0x80(%esp),%esi 0x0813704b <+1275>: mov 0x26c(%esi),%esi 0x08137051 <+1281>: test %esi,%esi 0x08137053 <+1283>: je 0x8137061 <cFrameDetector::Analyze(unsigned char const*, int)+1297> 0x08137055 <+1285>: add %edi,%ecx 0x08137057 <+1287>: cmpb $0x0,0x7(%ecx) 0x0813705b <+1291>: js 0x8137140 <cFrameDetector::Analyze(unsigned char const*, int)+1520> 0x08137061 <+1297>: cmpl $0x1,0x50(%esp) 0x08137066 <+1302>: jle 0x8136bff <cFrameDetector::Analyze(unsigned char const*, int)+175> 0x0813706c <+1308>: mov 0x80(%esp),%ecx 0x08137073 <+1315>: mov 0x26c(%ecx),%eax 0x08137079 <+1321>: jmp 0x8137001 <cFrameDetector::Analyze(unsigned char const*, int)+1201> 0x0813707b <+1323>: xor %edx,%edx ---Type <return> to continue, or q <return> to quit--- 0x0813707d <+1325>: mov %ecx,0x58(%esp) 0x08137081 <+1329>: mov 0x80(%esp),%ecx 0x08137088 <+1336>: mov %edx,0x5c(%esp) 0x0813708c <+1340>: fildll 0x58(%esp) 0x08137090 <+1344>: fdivrs -0x51728(%ebx) 0x08137096 <+1350>: fstpl 0x274(%ecx) 0x0813709c <+1356>: jmp 0x8136fc7 <cFrameDetector::Analyze(unsigned char const*, int)+1143> 0x081370a1 <+1361>: lea -0x708(%ecx),%eax 0x081370a7 <+1367>: cmp $0xffffffff,%eax 0x081370aa <+1370>: jl 0x81370b5 <cFrameDetector::Analyze(unsigned char const*, int)+1381> 0x081370ac <+1372>: cmp $0x1,%eax 0x081370af <+1375>: jle 0x81371e5 <cFrameDetector::Analyze(unsigned char const*, int)+1685> 0x081370b5 <+1381>: cmp $0x5dd,%ecx 0x081370bb <+1387>: je 0x81371fd <cFrameDetector::Analyze(unsigned char const*, int)+1709> 0x081370c1 <+1393>: mov 0x80(%esp),%eax 0x081370c8 <+1400>: mov -0x5ec(%ebx),%edx 0x081370ce <+1406>: flds -0x4af9c(%ebx) 0x081370d4 <+1412>: fstl 0x274(%eax) 0x081370da <+1418>: mov (%edx),%eax 0x081370dc <+1420>: cmp $0x2,%eax 0x081370df <+1423>: jle 0x8136fc5 <cFrameDetector::Analyze(unsigned char const*, int)+1141> 0x081370e5 <+1429>: cmp $0x3,%eax 0x081370e8 <+1432>: sete %al 0x081370eb <+1435>: movzbl %al,%eax 0x081370ee <+1438>: fstpl 0xc(%esp) 0x081370f2 <+1442>: lea 0x3(,%eax,4),%eax 0x081370f9 <+1449>: lea -0x4a16c(%ebx),%edx 0x081370ff <+1455>: mov %ecx,0x8(%esp) 0x08137103 <+1459>: mov %edx,0x4(%esp) 0x08137107 <+1463>: mov %eax,(%esp) 0x0813710a <+1466>: call 0x816a580 <syslog_with_tid(int, char const*, ...)> 0x0813710f <+1471>: mov 0x80(%esp),%ecx 0x08137116 <+1478>: mov 0x288(%ecx),%esi 0x0813711c <+1484>: jmp 0x8136fc7 <cFrameDetector::Analyze(unsigned char const*, int)+1143> 0x08137121 <+1489>: mov 0x80(%esp),%ecx 0x08137128 <+1496>: flds -0x4af9c(%ebx) 0x0813712e <+1502>: fstpl 0x274(%ecx) 0x08137134 <+1508>: jmp 0x8136fc7 <cFrameDetector::Analyze(unsigned char const*, int)+1143> 0x08137139 <+1513>: xor %eax,%eax 0x0813713b <+1515>: jmp 0x8136ef4 <cFrameDetector::Analyze(unsigned char const*, int)+932> 0x08137140 <+1520>: cmpb $0x4,0x8(%ecx) ---Type <return> to continue, or q <return> to quit--- 0x08137144 <+1524>: jbe 0x8137061 <cFrameDetector::Analyze(unsigned char const*, int)+1297> 0x0813714a <+1530>: movzbl 0xc(%ecx),%edx 0x0813714e <+1534>: movzbl 0xa(%ecx),%esi 0x08137152 <+1538>: shl $0x7,%edx 0x08137155 <+1541>: shl $0x16,%esi 0x08137158 <+1544>: or %edx,%esi 0x0813715a <+1546>: movzbl 0xd(%ecx),%edx 0x0813715e <+1550>: shr %dl 0x08137160 <+1552>: movzbl %dl,%edx 0x08137163 <+1555>: or %edx,%esi 0x08137165 <+1557>: movzbl 0x9(%ecx),%edx 0x08137169 <+1561>: movzbl 0xb(%ecx),%ecx 0x0813716d <+1565>: and $0xe,%edx 0x08137170 <+1568>: shl $0x1d,%edx 0x08137173 <+1571>: or %esi,%edx 0x08137175 <+1573>: mov %ecx,%esi 0x08137177 <+1575>: mov 0x80(%esp),%ecx 0x0813717e <+1582>: and $0xfe,%esi 0x08137184 <+1588>: shl $0xe,%esi 0x08137187 <+1591>: or %edx,%esi 0x08137189 <+1593>: mov 0x50(%esp),%edx 0x0813718d <+1597>: mov %esi,0x40(%esp) 0x08137191 <+1601>: test %edx,%edx 0x08137193 <+1603>: mov %esi,0xc(%ecx,%edx,4) 0x08137197 <+1607>: je 0x81371ca <cFrameDetector::Analyze(unsigned char const*, int)+1658> 0x08137199 <+1609>: cmpl $0xf0000000,0x8(%ecx,%edx,4) 0x081371a1 <+1617>: jbe 0x81371ca <cFrameDetector::Analyze(unsigned char const*, int)+1658> 0x081371a3 <+1619>: cmpl $0xfffffff,0x40(%esp) 0x081371ab <+1627>: ja 0x81371ca <cFrameDetector::Analyze(unsigned char const*, int)+1658> 0x081371ad <+1629>: movl $0x0,0x264(%ecx) 0x081371b7 <+1639>: movl $0x0,0x26c(%ecx) 0x081371c1 <+1649>: mov %ebp,0x3c(%esp) 0x081371c5 <+1653>: jmp 0x8136c70 <cFrameDetector::Analyze(unsigned char const*, int)+288> 0x081371ca <+1658>: addl $0x1,0x50(%esp) 0x081371cf <+1663>: mov 0x50(%esp),%edx 0x081371d3 <+1667>: mov 0x80(%esp),%esi 0x081371da <+1674>: mov %edx,0x264(%esi) 0x081371e0 <+1680>: jmp 0x8137061 <cFrameDetector::Analyze(unsigned char const*, int)+1297> 0x081371e5 <+1685>: mov 0x80(%esp),%ecx 0x081371ec <+1692>: flds -0x4a064(%ebx) 0x081371f2 <+1698>: fstpl 0x274(%ecx) ---Type <return> to continue, or q <return> to quit--- 0x081371f8 <+1704>: jmp 0x8136fc7 <cFrameDetector::Analyze(unsigned char const*, int)+1143> 0x081371fd <+1709>: mov 0x80(%esp),%ecx 0x08137204 <+1716>: fldl -0x4a054(%ebx) 0x0813720a <+1722>: fstpl 0x274(%ecx) 0x08137210 <+1728>: jmp 0x8136fc7 <cFrameDetector::Analyze(unsigned char const*, int)+1143> End of assembler dump.
It looks like a div (for FP, idiv is integer div) by the ecx register which contains 0, as I assumed a divsion by zero exception.
Can You see why the ecx gets 0 before?
Marko
y tom
Sun, Dec 01, 2024 at 08:55:45PM +0100, schorpp wrote:
(gdb) print ptsValues[0] $1 = 3600 (gdb) print framesPerPayloadUnit $2 = 1 (gdb) print parser->iFrameTemporalReferenceOffset $3 = -1
Okay, this looks like a straightforward division by zero, which in fact should have been fixed more than 10 years ago in VDR 2.1.7. Which version of VDR are you using again?
commit 57222002b2b48baa9f5c8d0f253184801ba7200a Author: Klaus Schmidinger vdr@tvdr.de Date: Sun Apr 13 13:50:04 2014 +0200
Fixed a possible division by zero in frame rate detection
As far as I can tell, this fix is also preventing a division by a negative number, which would have been another thinkable source of SIGFPE.
In your register output, we have a zero divisor in ecx:
(gdb) info registers
...
ecx 0x0 0
...
(gdb) disassemble
...
0x08136f4d <+1021>: mov 0x80(%esp),%ecx 0x08136f54 <+1028>: xor %edx,%edx 0x08136f56 <+1030>: mov 0x288(%ecx),%esi 0x08136f5c <+1036>: mov %ecx,%eax 0x08136f5e <+1038>: mov 0xc(%eax),%eax 0x08136f61 <+1041>: mov 0x280(%ecx),%ecx 0x08136f67 <+1047>: add 0x8(%esi),%ecx
=> 0x08136f6a <+1050>: div %ecx
There is some loading of registers from the stack, as well as zeroing out the more significant 32 bits of the dividend (edx). The dividend was calculated right before the division.
Marko
Am 06.12.24 um 20:51 schrieb Marko Mäkelä:
Sun, Dec 01, 2024 at 08:55:45PM +0100, schorpp wrote:
(gdb) print ptsValues[0] $1 = 3600 (gdb) print framesPerPayloadUnit $2 = 1 (gdb) print parser->iFrameTemporalReferenceOffset $3 = -1
Okay, this looks like a straightforward division by zero, which in fact should have been fixed more than 10 years ago in VDR 2.1.7. Which version of VDR are you using again?
2.0.6 ^^
commit 57222002b2b48baa9f5c8d0f253184801ba7200a Author: Klaus Schmidinger vdr@tvdr.de Date: Sun Apr 13 13:50:04 2014 +0200
Fixed a possible division by zero in frame rate detection
which repository is this? I did not know Klaus is working with github?
I'll see if I can apply this patch manually.
As far as I can tell, this fix is also preventing a division by a negative number, which would have been another thinkable source of SIGFPE.
In your register output, we have a zero divisor in ecx:
(gdb) info registers
...
ecx 0x0 0
...
(gdb) disassemble
...
0x08136f4d <+1021>: mov 0x80(%esp),%ecx 0x08136f54 <+1028>: xor %edx,%edx 0x08136f56 <+1030>: mov 0x288(%ecx),%esi 0x08136f5c <+1036>: mov %ecx,%eax 0x08136f5e <+1038>: mov 0xc(%eax),%eax 0x08136f61 <+1041>: mov 0x280(%ecx),%ecx 0x08136f67 <+1047>: add 0x8(%esi),%ecx
=> 0x08136f6a <+1050>: div %ecx
There is some loading of registers from the stack, as well as zeroing out the more significant 32 bits of the dividend (edx). The dividend was calculated right before the division.
Understood, thanks.
Marko
y tom
Am 06.12.24 um 21:05 schrieb Marko Mäkelä:
Fri, Dec 06, 2024 at 08:59:48PM +0100, schorpp kirjoitti:
which repository is this? I did not know Klaus is working with github?
git://git.tvdr.de/vdr.git has been around for a few years, read-only.
The only match in google for the commit UUID is here: https://git.koehlerweb.org/frodovdr/vdr/commit/57222002b2b48baa9f5c8d0f25318...
I'll apply it, should work. Thanks :)
Marko
y tom
-
Marko Mäkelä -
schorpp